Как провести бета-тест вашего приложения

Чтобы провести бета-тест, решите, что вам нужно узнать, пригласите небольшую группу людей, которые соответствуют вашим реальным пользователям, дайте им понятную первую задачу и собирайте обратную связь в одном месте по фиксированному графику. Устраняйте то, что мешает им работать, расширяйте группу раундами и завершайте бету, когда выполнены заранее написанные критерии выхода, а не когда кончилось терпение.

Бета — не мягкий запуск. Это структурированный эксперимент с началом, концом и вопросом, на который нужно ответить.

Где место беты

Валидация спрашивает, стоит ли решать эту проблему. Бета задаёт более узкий вопрос: решает ли эта версия продукта проблему для реальных людей в реальных условиях? Запуск идёт после, когда ответ в основном «да».

Перед приглашением кого-либо проведите собственное тестирование — как протестировать приложение перед запуском описывает это. Тестировщики не должны первыми обнаруживать, что регистрация не работает.

Шаг 1: запишите, на какой вопрос должна ответить бета

Выберите два-три вопроса. Всё остальное в плане следует из них.

Выдуманный пример: приложение для составления графиков смен в небольших кафе ставит две цели: «Может ли менеджер опубликовать график на неделю в первом сеансе без помощи?» и «Открывают ли сотрудники приложение сами на второй неделе?»

Шаг 2: выберите тип беты

Для первого продукта обычно правильна закрытая бета с несколькими раундами.

Шаг 3: наберите подходящих тестировщиков

Лучшие тестировщики сейчас испытывают эту проблему, соответствуют вашей целевой аудитории и имеют время попробовать приложение в период беты. Где их искать:

• Ваш лист ожидания или список email — см. как собрать аудиторию до запуска.
• Люди, с которыми вы беседовали во время валидации.
• Нишевые сообщества, где собираются ваши пользователи, соблюдая их правила о продвижении.
• Прямые приглашения людям из вашего окружения, которые подходят под профиль.

Задайте несколько отборочных вопросов, чтобы составить смешанную группу: их роль, как они решают эту задачу сейчас, какое устройство будут использовать и как часто возникает эта проблема. Приглашайте тех, чьи ответы совпадают с целевым пользователем, и не заполняйте бету другими основателями, если они сами не являются целевым пользователем.

Шаблон приглашения

Привет, [имя]! Вы упоминали [проблему], когда регистрировались. Я открываю небольшую закрытую бету [продукт], который [результат]. Она идёт с [начало] по [конец]. Прошу тестировщиков использовать её для [реальная задача] хотя бы раз в неделю и отвечать на короткий опрос каждую пятницу. Взамен: бесплатный доступ на время беты и [основательская цена / продлённый бесплатный период]. Интересно?

Честно назовите нужное время. Люди, которые понимают, на что подписались, дают лучшую обратную связь.

Шаг 4: подготовьте набор для беты

До отправки первого приглашения приготовьте:

• Приветственное сообщение со ссылкой, инструкцией по входу, первой задачей для пробы и способом сообщить о проблемах.
• Список известных проблем, чтобы тестировщики не сообщали об одном и том же десять раз.
• Один канал обратной связи. Форма, общий чат или адрес email — одно место, а не пять.
• Шаблон баг-репорта. Попросите описать, что они сделали, что ожидали, что произошло, устройство и браузер, а также скриншот. Как написать хороший баг-репорт содержит версию, которой можно поделиться.
• Базовую аналитику или логи, чтобы видеть, что произошло, без опоры на память.
• Понятные ожидания по данным. Скажите тестировщикам, если данные могут сбрасываться во время беты, и не просите вносить чувствительную информацию в незаконченное приложение.
• Основы условий и конфиденциальности. Короткое соглашение о бете и заметка о конфиденциальности; проверьте местные правила или проконсультируйтесь, если работаете с персональными данными.

Шаг 5: проводите бету раундами

Раунды позволяют исправить проблемы до того, как их встретят ещё больше людей.

В первом раунде попросите двух-трёх тестировщиков поделиться экраном, пока они впервые пробуют приложение. Молчите и смотрите, где они колеблются. Это часто самый полезный час всей беты.

Шаг 6: собирайте обратную связь по ритму

Неструктурированные сообщения «есть ли отзывы?» дают расплывчатые ответы. Вместо этого используйте короткий регулярный опрос:

Еженедельный опрос (примеры вопросов)

1. Для чего вы использовали [продукт] на этой неделе?
2. Что было неудобным или непонятным?
3. Не хватало ли чего-то, что помешало вам завершить задачу?
4. Что бы вы почувствовали, если бы больше не могли им пользоваться? (Очень расстроился / немного / совсем нет)
5. Что-нибудь ещё?

Сопоставляйте то, что люди говорят, с тем, что они делают. Тот, кто говорит, что всё отлично, но никогда не заходит, тоже вам что-то сообщает.

Шаг 7: сортируйте поступающее

Собирайте всю обратную связь в один список и сортируйте раз в неделю.

Сопротивляйтесь добавлению крупных функций в середине беты. Каждая новая функция мешает понять, работает ли основной продукт.

Шаг 8: замкните цикл

Тестировщики продолжают давать обратную связь, когда видят, что её используют.

• Отправляйте короткий журнал изменений после каждого раунда: «Вы сообщили о X — это исправлено».
• Лично благодарите людей по имени, когда их отчёт привёл к исправлению.
• Сообщите тестировщикам, когда бета закончится, что будет с их данными и аккаунтом и каково их основательское предложение.

Шаг 9: решите, готовы ли вы

Запишите критерии выхода до начала беты, а в конце честно проверьте их. Шаблон:

• Нет известных блокеров и багов с потерей данных
• Большинство новых тестировщиков выполняют основное действие без помощи
• Заметная доля тестировщиков возвращается сама в последующие недели
• Главные точки путаницы исправлены и перепроверены
• Регистрация, сброс пароля и любой платёжный сценарий работают от начала до конца
• У вас есть ясное описание того, для кого продукт, в словах тестировщиков

Если большинство пунктов отмечено, переходите к доработке онбординга и публичному запуску. Если повторное использование низкое, это вопрос продукта, а не список багов — вернитесь к интервью перед запуском.

Проведение беты с Mythex

Если вы создаёте приложение в Mythex, несколько функций хорошо ложатся на бету:

• Ссылки предпросмотра для первого раунда. Кнопка Share создаёт ссылку на ваш живой предпросмотр, которая работает для людей без аккаунта Mythex, так что ранний тестировщик может попробовать незаконченную работу до публикации. Делайте по одной ссылке на группу и удаляйте её, когда закончите; документация по предпросмотру объясняет, как ссылки будят проект и расходуют кредиты.
• Публикация для долгих раундов. Опубликованное приложение работает по собственному адресу, что подходит тестировщикам, которые пользуются им несколько недель.
• App Testing перед каждым раундом. Введите /test в чате, и агент пройдёт ваш предпросмотр и сообщит о сломанных сценариях — полезная проверка перед приглашением кого-либо (документация App Testing).
• Checkpoints. Если исправление ломает что-то в середине беты, откатитесь к более раннему checkpoint.

Вставьте баг-репорт тестировщика прямо в чат и попросите агента воспроизвести и исправить его, а затем сообщите тестировщику, когда исправление выйдет.

Вопросы