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

Короткий ответ: перед релизом заказчик ставит тестовую сборку на свой телефон — через TestFlight на iPhone, внутреннее тестирование Google Play или закрытую версию RuStore на Android — и проходит по чек-листу основные сценарии: вход, главный экран, оплату, push-уведомления, работу без связи. Проверять нужно минимум на одном iPhone и одном Android, а каждое замечание записывать по шаблону: что случилось, на каком устройстве, как повторить, что ожидали. Ниже — подробный порядок, 12 сценариев и шаблон замечания.

Как получить тестовую сборку на свой телефон?

Через официальные каналы тестирования магазинов. На iPhone сборка приходит в приложение TestFlight, на Android — по ссылке-приглашению из внутреннего теста Google Play или закрытой версии RuStore. Ставить приложение «файлом из чата» не нужно: так вы проверяете не ту сборку, что уйдёт в магазин.

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

Что сделать на телефоне:

1. Установить из App Store бесплатное приложение TestFlight.
2. Открыть письмо-приглашение или публичную ссылку на этом же телефоне.
3. Нажать «Установить» в TestFlight. Иконка тестового приложения появится на экране с оранжевой точкой у названия.
4. Обновления приходят туда же: разработчик загружает новую сборку, вы жмёте «Обновить».

Android через Google Play. Во внутреннем тестировании до 100 тестировщиков. Разработчик вносит адреса аккаунтов Google в список и присылает ссылку; вы открываете её на телефоне под тем же аккаунтом, соглашаетесь участвовать и ставите приложение из Google Play. Новая сборка становится доступна в течение минут, но после первой публикации самой ссылке может понадобиться несколько часов.

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

Android через RuStore. В RuStore есть закрытое тестирование версии до публикации: тестировщиков добавляют по VK ID, до 2000 человек, версия проходит модерацию, после неё формируется ссылка. Тестировщику нужно свежее приложение RuStore и вход под тем же VK ID. Закрытая версия доступна только для бесплатных приложений, одновременно тестируется одна такая версия. Подробнее о публикации — в статье о RuStore.

Если приложение сделано как PWA, всё проще: тестовый адрес открывается в браузере, а «Добавить на экран домой» ставит его иконкой. Магазины в этой схеме не участвуют.

Платформа	Как попасть в тест	Ограничения	Что нужно тестировщику
iPhone и iPad: TestFlight, внутренние тестировщики	Разработчик добавляет вас пользователем App Store Connect, сборка появляется в приложении TestFlight	До 100 пользователей App Store Connect с доступом к приложению; сборки добавляют в группу тестировщиков	Apple ID, приложение TestFlight из App Store
iPhone и iPad: TestFlight, внешние тестировщики	Приглашение на почту или публичная ссылка	До 10 000 человек; первая сборка проходит проверку Apple; сборка живёт 90 дней	Apple ID, приложение TestFlight
Android: внутреннее тестирование Google Play	Адрес почты в списке тестировщиков и ссылка-приглашение	До 100 человек; новая сборка доступна в течение минут	Аккаунт Google на телефоне, Google Play
Android: закрытая версия в RuStore	VK ID в списке тестировщиков и ссылка на версию	До 2000 человек; версия проходит модерацию; только бесплатные приложения	Свежая версия приложения RuStore, вход по тому же VK ID

На каких устройствах и версиях ОС проверять?

Минимум — на одном iPhone и одном Android, которые есть у вас и у сотрудников. Плюс одно устройство «похуже»: недорогой Android с небольшим экраном или iPhone на версии iOS двух-трёхлетней давности. На флагмане всё летает, а ваши клиенты пользуются разными телефонами.

Как собрать набор устройств без лаборатории:

• Спросите аналитику. Если у вас уже есть сайт с Яндекс Метрикой, посмотрите отчёт по устройствам и операционным системам: это и есть телефоны ваших клиентов.
• Возьмите крайние экраны. Самый маленький iPhone, который поддерживает приложение, и самый большой. На маленьком обрезаются кнопки и длинные названия, на большом растягиваются картинки.
• Проверьте нижнюю версию системы. В ТЗ указывают минимальные версии iOS и Android. Хотя бы один телефон должен быть на минимальной версии из ТЗ или близкой к ней.
• Не забудьте Android без сервисов Google. Если среди ваших клиентов есть владельцы телефонов без Google Play, проверьте вход и push-уведомления на таком устройстве. Почему это отдельная тема, мы разбирали в статье о push-уведомлениях.
• Планшет — только если он в ТЗ. Если приложение заявлено только для телефонов, планшет можно не проверять.

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

Что проверить в первую очередь: 12 сценариев

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

1. Первый запуск. Установите приложение с нуля, а не поверх старой сборки. Пройдите заставку и онбординг: всё читается, кнопку «Пропустить» видно, разрешения запрашиваются в момент, когда понятно зачем.
2. Регистрация и вход. Зарегистрируйтесь новым номером или почтой, выйдите, войдите снова. Проверьте восстановление пароля и неверный код: сообщение об ошибке должно быть человеческим.
3. Главный сценарий. Пройдите целевое действие три раза подряд разными путями: из поиска, из каталога, из push-уведомления. Результат должен появиться там, где его ждут сотрудники: в CRM, 1С, на почте.
4. Оплата. Тестовый платёж, отказ банка, отмена на экране оплаты. После каждого варианта заказ должен оказаться в правильном статусе, а деньги — не списаться дважды.
5. Push-уведомления. Разрешите уведомления, закройте приложение, вызовите событие (смена статуса, сообщение). Push должен прийти и по нажатию открыть нужный экран, а не главную.
6. Отказ в разрешениях. Запретите уведомления, камеру, геолокацию. Приложение не должно падать или зависать: только объяснять, что функция недоступна, и подсказывать, как включить.
7. Профиль и данные. Поменяйте имя, телефон, аватар. Выйдите и войдите на другом телефоне — изменения на месте.
8. Удаление аккаунта. Если в приложении можно создать аккаунт, Apple требует, чтобы его можно было и удалить изнутри приложения. Найдите эту функцию и проверьте, что она работает.
9. Пустые состояния. Новый пользователь без заказов, пустой поиск, пустая корзина. Вместо белого экрана должен быть понятный текст и следующий шаг.
10. Длинные данные. Длинное имя, длинный адрес, название товара в три строки. Текст переносится, кнопки не уезжают за экран.
11. Сворачивание и возврат. Начните оформление, сверните приложение, ответьте на звонок, вернитесь через 10 минут. Введённое не должно пропасть, а сессия — оборваться без предупреждения.
12. Обновление поверх прошлой версии. Когда придёт следующая сборка, обновитесь без удаления. Вход, настройки и черновики должны сохраниться: так приложение будет обновляться у реальных клиентов.

Каждый сценарий отметьте в таблице: iPhone — ок или номер замечания, Android — ок или номер замечания. Такая таблица и есть ваш протокол приёмки.

Плохая сеть, офлайн, поворот, крупный шрифт

Это проверки, которые почти никогда не делают в офисе с хорошим Wi-Fi, а клиенты сталкиваются с ними каждый день. На них уходит полчаса, а находят они самые неприятные ошибки: зависшие экраны и потерянные заказы.

• Плохая связь. Выключите Wi-Fi и пройдите главный сценарий на мобильном интернете в лифте, на парковке, в метро. Должен быть индикатор загрузки, а не пустой экран, и повторная попытка, а не двойной заказ.
• Нет сети. Включите авиарежим посреди действия. Приложение должно сказать, что связи нет, и не терять введённое. Если по ТЗ часть функций работает офлайн (например, у выездных сотрудников), проверьте, что данные отправятся сами, когда связь вернётся.
• Поворот экрана. Если приложение поддерживает горизонтальную ориентацию, поверните телефон на каждом основном экране. Если не поддерживает, убедитесь, что экран не поворачивается частично.
• Крупный шрифт. В настройках телефона увеличьте размер текста до максимума. Подписи не должны обрезаться, кнопки — налезать друг на друга. Это важно для людей старшего возраста и для всех, кто читает на ходу.
• Тёмная тема. Переключите систему в тёмный режим. В нашем тарифе светлая и тёмная тема входят в базовый объём, поэтому проверьте, что нет чёрного текста на тёмном фоне и белых «дыр».
• Экономия заряда. Включите режим энергосбережения: в нём телефоны ограничивают фоновую работу, и уведомления или синхронизация могут вести себя иначе.

Как записать замечание, чтобы его быстро исправили?

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

Номер сборки виден в TestFlight на странице приложения, а на Android — в настройках телефона, в сведениях о приложении. Запись экрана есть в «Пункте управления» на iPhone и в шторке быстрых настроек на большинстве Android. Двадцать секунд видео часто заменяют абзац текста.

Ещё несколько правил, которые экономят время обеим сторонам:

• Пишите в одно место. Общая таблица, трекер или задачи в личном кабинете — не голосовые в мессенджере и не пересланные скриншоты от разных людей.
• Отделяйте ошибки от пожеланий. «Кнопка не нажимается» — ошибка. «Давайте сделаем кнопку зелёной» — пожелание. Ошибки против ТЗ исправляются в рамках работы; новое — отдельной задачей.
• Ставьте важность. Блокирует релиз (не проходит оплата, падает вход), мешает (неверный текст статуса), косметика (отступ). Так разработчик начнёт с главного.
• Собирайте замечания пачкой. Пройдите весь чек-лист, потом отправьте список. Правки по одной каждый час рвут работу и растягивают срок.
• Перепроверяйте в новой сборке. Когда замечание исправлено, отметьте, в какой сборке вы это проверили, и закройте запись.

Поле	Плохо	Хорошо
Что случилось	«Корзина глючит»	«После удаления последнего товара корзина показывает сумму прошлого заказа»
Где и на чём	«У меня на телефоне»	«Android 13, Samsung A52, сборка 1.0.0 (14), вошёл как покупатель»
Как повторить	Нет шагов	«1. Добавить два товара. 2. Удалить оба. 3. Открыть корзину»
Что ожидали	Не сказано	«Пустая корзина и кнопка „В каталог“»
Доказательство	Нет	Запись экрана 20 секунд или скриншот

Что входит в приёмку по договору?

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

Поэтому чек-лист и протокол из этой статьи полезно пройти до того, как придёт акт, — на тестовых сборках. Тогда 5 дней уйдут на финальную проверку, а не на первое знакомство с приложением. С сайтом логика та же: о том, как принять сайт у разработчика до подписания акта, мы писали отдельно. Что ещё стоит знать:

• Правки. По тарифу мобильного приложения — до 2 раундов на прототипе и до 2 раундов на готовой сборке. Правки — это исправления в рамках согласованного ТЗ; новые экраны и функции оформляются отдельно.
• Опора — ТЗ. Мотивированный отказ ссылается на конкретные пункты ТЗ: «экран оплаты не показывает ошибку отказа банка, п. 4.3». Замечание «мне не нравится» к ТЗ не привязано, и это повод для отдельной договорённости.
• Публикация до полной оплаты. По договору до окончательного расчёта заказчик вправе использовать переданный результат для проверки, приёмки, запуска, в том числе для публикации в магазинах приложений.
• Оплата. 50 % предоплаты, 50 % — в течение 3 рабочих дней после подписания акта или после того, как работы считаются принятыми.
• После акта. 14 дней бесплатной поддержки после публикации и гарантия 30 календарных дней с даты акта: ошибки по вине исполнителя исправляются бесплатно. Дальше — поддержка от 7 900 ₽ в месяц или почасово; что в неё входит, разбираем в статье о поддержке приложения.

Что проверить из файлов и доступов, прежде чем подписывать акт: исходный код приложения и сервера в вашем репозитории, приложение в App Store и Google Play под вашими аккаунтами, доступы ко всем подключённым сервисам и инструкция по выпуску новых версий. Это перечень того, что заказчик получает по тарифу; формулировки — в типовых договорах.

Мобильное приложение по прайсу стоит от 200 000 ₽ и делается от 2 недель; в этот срок уже заложен этап «тестирование на реальных устройствах, сборка релизов». Как время распределяется между этапами, мы показывали в статье о сроках разработки приложения.

Когда полный чек-лист не нужен и какие ошибки встречаются чаще всего?

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

Ошибки заказчиков, которые растягивают выпуск:

• Проверка только на своём флагмане. На новом iPhone всё в порядке, а у клиентов на бюджетных Android обрезается кнопка оплаты.
• Тест под аккаунтом разработчика. Войдите как обычный клиент, с пустой историей: у тестового администратора видно то, чего клиент не увидит.
• Нет тестовых данных. Чтобы проверить заказ, нужен товар, цены, остатки. Подготовьте их заранее, иначе приёмка встанет.
• Закрытый тест Google Play не запланирован. Для нового личного аккаунта это 14 дней с 12 тестировщиками: соберите их заранее среди сотрудников и знакомых.
• Не подготовлены материалы для проверки Apple. Если в приложение нужно войти, Apple попросит тестовый логин. Заведите отдельный демо-аккаунт с данными, а не давайте личный.
• Замечания приходят в последний день. Пять рабочих дней проходят быстро. Начните на тестовых сборках, пока идёт разработка.

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

Короткие ответы на частые вопросы

Как установить TestFlight и тестовую сборку iOS?

Скачайте бесплатное приложение TestFlight из App Store, откройте приглашение из письма или публичную ссылку и нажмите «Установить». Внешним тестировщикам сборка становится доступна после проверки Apple, которую проходит первая сборка версии.

Как присоединиться к внутреннему тестированию Google Play?

Разработчик добавляет адрес вашего аккаунта Google в список тестировщиков и присылает ссылку-приглашение. Откройте её на телефоне под тем же аккаунтом, согласитесь участвовать и установите приложение из Google Play.

Сколько устройств нужно для проверки приложения?

Минимум два: один iPhone и один Android. Если есть возможность, добавьте недорогой Android с маленьким экраном и устройство на версии системы двух-трёхлетней давности — там чаще всплывают ошибки вёрстки и скорости.

Можно ли проверить приложение без телефона, в эмуляторе?

Для первого знакомства — да, но приёмку стоит проводить на настоящем телефоне. Эмулятор не показывает реальную скорость, поведение камеры, push-уведомлений, оплаты и слабой связи.

Что будет, если не прислать замечания за 5 рабочих дней?

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

Услуги и кейсы по теме: мобильные приложения · цены и сроки