Как провести бета-тест мобильного приложения перед запуском

Бета-тест нужен не для того, чтобы услышать «вроде всё нормально»

Типичный тест выглядит бодро только в первые дни. Основатель отправляет ссылку друзьям, в чате появляются скриншоты и советы поменять цвет кнопки, кто-то пишет «у меня зависло». Через неделю сообщений становится меньше, но ответ на главный вопрос так и не найден: приложение готово к настоящим пользователям или люди просто перестали его открывать?

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

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

Сначала сформулируйте вопросы, потом ищите людей

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

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

Одновременно запишите причины, которые запрещают выпуск. Потеря данных, двойное списание, доступ к чужому аккаунту, невозможность войти или оформить основную операцию не могут ждать «версии 1.1». Для менее серьёзных проблем можно принять риск, но у него должны быть владелец и срок исправления.

Чем отличаются внутренний тест, закрытая и открытая бета

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

Подбирайте тестировщиков по роли и ситуации

Составьте простую таблицу. По одной оси укажите роли: клиент, исполнитель, курьер, преподаватель, администратор, сотрудник поддержки. По другой — обстоятельства, способные изменить опыт: первый запуск, старый телефон, маленький экран, слабая связь, специальные возможности, другой способ оплаты или работа в движении.

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

Коллеги подходят для начала, но они слишком многое знают. Они мысленно дополняют недостающие подсказки и прощают странные формулировки. Внешнему участнику достаточно понимать задачу, которую решает продукт; презентацию основателя он знать не должен.

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

Подготовьте сборку и обратную связь до рассылки

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

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

До старта проверьте аналитику и сбор отчётов о сбоях. Намеренно вызовите тестовую ошибку и убедитесь, что видите версию, модель устройства и систему. Не просите людей вводить настоящие медицинские, платёжные или рабочие данные ради «реалистичности»: предварительная версия всё равно обрабатывает персональную информацию.

Как распространять iOS-сборку через TestFlight

TestFlight — стандартный инструмент Apple для предварительных версий iOS. Внутренними тестировщиками становятся пользователи App Store Connect с доступом к приложению. Внешних можно приглашать по электронной почте или публичной ссылке. Сейчас Apple разрешает до 100 внутренних и 10 000 внешних участников, а одну сборку можно тестировать до 90 дней.

Первая сборка для внешней группы может проходить отдельную проверку TestFlight App Review. Заложите это время в план, а не обещайте доступ сразу после загрузки. Создавайте разные группы, если сотрудникам, клиентам и исполнителям нужны разные сценарии или учётные данные. Укажите, что изменилось в версии, на что обратить внимание и к кому обращаться.

TestFlight принимает скриншоты и комментарии, но сам по себе не превращает их в решения. Команде всё равно придётся разбирать дубли, уточнять обстоятельства и проверять исправления. И ещё одно важное различие: проверка внешней беты не означает, что финальная версия уже одобрена App Store. Карточка, сведения о конфиденциальности и доступ для ревьюера входят в отдельный план запуска приложения.

Какой тестовый канал выбрать в Google Play

В Google Play есть внутреннее, закрытое и открытое тестирование. Внутренний канал позволяет быстро раздать Android App Bundle небольшой доверенной группе. Закрытый ограничивает доступ списком адресов, группой Google или организацией. Открытый делает предварительную версию заметнее, поэтому само приложение и карточка магазина уже должны выглядеть достойно.

Участнику нужно войти под разрешённой учётной записью Google, согласиться на участие и только потом установить тестовую версию. Лучше отправить отдельно ссылку для вступления и ссылку на страницу приложения, коротко описав порядок. Также настройте почту или страницу для обратной связи. Замечания из закрытого и открытого теста остаются приватными и не влияют на публичный рейтинг.

Для личных аккаунтов разработчика, созданных после 13 ноября 2023 года, сейчас действует дополнительное условие: перед запросом доступа к публикации нужно провести закрытый тест как минимум с 12 присоединившимися участниками в течение 14 дней подряд. Перед запуском проверьте актуальную справку Play Console. Это требование к аккаунту, а не сертификат качества: двенадцать молчащих установок не заменяют содержательную проверку продукта.

Давайте задачу, а не инструкцию по кнопкам

Просьба «потестируйте всё» почти гарантирует разрозненные комментарии. Подробная инструкция на двадцать шагов, наоборот, скрывает проблемы интерфейса. Лучше дать жизненную ситуацию: «Вам нужно записаться на занятие в субботу. Найдите свободное время, подтвердите запись, а затем перенесите её на воскресенье».

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

Не заставляйте всех сидеть в одинаковых условиях. Курьеру важно попробовать приложение в пути, родителю — одной рукой, ученику — вернуться после перерыва. Слабая связь, солнце, шум и отвлечение не помехи эксперименту, а часть будущего продукта.

Сопоставляйте слова с аналитикой и сбоями

Комментарий показывает, как человек понял происходящее. Аналитика показывает, где он остановился. Отчёт о сбое объясняет техническую причину. Небольшое интервью помогает заметить сомнение, которое не выражается ни одним событием.

Связывайте эти источники номером сборки, анонимным тестовым аккаунтом, устройством и примерным временем. Проверяйте только события, относящиеся к главным вопросам: завершённая регистрация, подтверждённая запись, ошибка платежа, возобновление урока. В статье про аналитику мобильного приложения мы объясняем, как не превратить карту событий в бесконечный справочник.

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

Разбирайте обратную связь, не раздувая выпуск

Для короткой беты удобно проводить ежедневный разбор. Объединяйте одинаковые сообщения и разделяйте ошибку, непонимание, личное предпочтение и новую идею. Просьба добавить функцию иногда означает, что существующее действие просто не видно. Но иногда это действительно новый объём, который опасно встраивать в последнюю сборку.

В общем журнале фиксируйте доказательство, серьёзность, владельца, номер исправленной сборки и результат повторной проверки. Так одна проблема не возвращается под разными названиями, а решение о дате остаётся понятным.

Закончите тест решением, а не тишиной в чате

Перед выпуском соберите владельца продукта, разработку и операционную команду. Могут ли подходящие пользователи пройти главное действие без помощи? Есть ли понятный выход при потере связи, отказе в разрешении, завершении сессии и неудачном платеже? Приходят ли события и отчёты именно из финальной сборки? Готовы ли поддержка, админ-панель и оповещения? Совпадают ли версия, описание, сведения о данных и учётные записи для проверки?

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

Как мы проводим бета-тесты в Appfyl

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

Смысл не в обещании «найти все ошибки». Важно сделать оставшийся риск понятным для продукта, разработки и тех, кто будет обслуживать приложение. Основные роли, функции, платежи и условия использования можно заранее описать в интерактивном брифе Appfyl.

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

Частые вопросы