Як провести бета-тестування вашого застосунку

Щоб провести бета-тест, визначте, що саме вам потрібно дізнатися, запросіть невелику групу людей, які відповідають вашим реальним користувачам, дайте їм чітке перше завдання і збирайте відгук в одному місці за фіксованим графіком. Виправляйте те, що їх блокує, розширюйте групу раундами і завершуйте бету, коли виконано набір критеріїв завершення, які ви написали заздалегідь, — а не тоді, коли закінчиться терпіння.

Бета — це не м'який запуск. Це структурований експеримент із початком, кінцем і питанням, на яке треба відповісти.

Де місце бети

Валідація питає, чи варта проблема того, щоб її вирішувати. Бета ставить вужче питання: чи вирішує ця версія продукту проблему для реальних людей у реальних умовах? Запуск іде потім, коли відповідь переважно «так».

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

Крок 1: Запишіть, на що має відповісти бета

Оберіть два-три питання. Усе інше в плані випливає з них.

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

Крок 2: Оберіть тип бети

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

Крок 3: Знайдіть правильних тестувальників

Найкращі тестувальники мають проблему зараз, відповідають вашій цільовій аудиторії і мають час спробувати застосунок протягом вікна бети. Де їх знайти:

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

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

Шаблон запрошення

Привіт, [ім'я] — ви згадували [проблему], коли реєструвалися. Я відкриваю невелику приватну бету [продукту], який [результат]. Вона триває з [початок] по [кінець]. Я прошу тестувальників користуватися ним для [реального завдання] принаймні раз на тиждень і відповідати на коротке опитування щопʼятниці. Натомість: безкоштовний доступ під час бети і [засновницька ціна / продовжений безкоштовний період]. Цікаво?

Чесно вкажіть часові витрати. Люди, які знають, на що підписуються, дають кращий відгук.

Крок 4: Підготуйте набір для бети

Перш ніж надсилати перше запрошення, підготуйте це:

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

Крок 5: Проводьте раундами

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

У раунді 1 попросіть двох-трьох тестувальників поділитися екраном, поки вони вперше пробують застосунок. Мовчіть і спостерігайте, де вони вагаються. Це часто найкорисніша година всієї бети.

Крок 6: Збирайте відгук у певному ритмі

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

Щотижневе опитування (вигадані приклади запитань)

1. Для чого ви використовували [продукт] цього тижня?
2. Що було незручно або незрозуміло?
3. Чи чогось бракувало, що завадило завершити завдання?
4. Що б ви відчули, якби більше не могли ним користуватися? (Дуже засмутився / трохи / зовсім ні)
5. Щось ще?

Поєднуйте те, що люди кажуть, з тим, що вони роблять. Людина, яка каже, що це чудово, але ніколи не заходить, теж щось вам повідомляє.

Крок 7: Сортуйте те, що надходить

Збирайте кожен відгук в одному списку і сортуйте щотижня.

Уникайте додавання великих функцій посеред бети. Кожна нова функція ускладнює розуміння того, чи працює основний продукт.

Крок 8: Замкніть цикл

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

• Надсилайте коротку зміну після кожного раунду: «Ви повідомили про X; це виправлено».
• Дякуйте людям на ім'я, особисто, коли їхній звіт призвів до виправлення.
• Повідомте тестувальників, коли бета завершиться, що станеться з їхніми даними та акаунтом і яка буде їхня засновницька пропозиція.

Крок 9: Вирішіть, чи ви готові

Запишіть критерії завершення до початку бети, а потім чесно перевірте їх наприкінці. Шаблон:

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

Якщо більшість пунктів позначено, переходьте до доопрацювання онбордингу і публічного запуску. Якщо повернень мало, це питання продукту, а не список помилок — поверніться до інтерв'ю перед запуском.

Бета з Mythex

Якщо ви створюєте з Mythex, кілька функцій добре лягають на бету:

• Посилання попереднього перегляду для першого раунду. Кнопка Share створює посилання на ваш живий попередній перегляд, яке працює для людей без акаунта Mythex, тож ранній тестувальник може спробувати незавершену роботу до публікації. Створюйте одне посилання на групу і видаляйте його, коли закінчите, — документація з попереднього перегляду пояснює, як посилання пробуджують проєкт і використовують кредити.
• Публікація для довших раундів. Опублікований застосунок працює за власною адресою, що підходить тестувальникам, які користуються ним кілька тижнів.
• Тестування застосунку перед кожним раундом. Введіть /test у чаті, і агент пройде ваш попередній перегляд і повідомить про зламані сценарії — корисна перевірка перед запрошенням будь-кого (документація App Testing).
• Контрольні точки. Якщо виправлення щось зламало посеред бети, поверніться до попередньої контрольної точки.

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

Запитання