Тестирование мобильных приложений: чек-лист перед релизом

Релиз уже собран, фичи на месте, дедлайн горит — и в этот момент страшнее всего нажать Publish. Разработчик понимает, что у мобильного приложения нет права на ошибку. Если пользователю что-то непонятно, он не будет «разбираться», а просто закроет и уйдет. Этот чеклист пригодится тем, кто принимает работу у исполнителя, считает бюджет по часам и готовит запуск.

По данным Mediascope (2025), интернетом в России пользуются 105 млн человек в месяц — это 86% населения старше 12 лет. В среднем они проводят онлайн от 3 до 5 часов день.

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

До релиза: что фиксируем в ТЗ

Хорошее ТЗ определяет две вещи: 1) что проверяем, 2) по каким критериям принимаем релиз.

Сначала описывайте сценарии и границы — это основа для проверки и приемки. В частности, какие платформы и версии ОС в фокусе. Какие критические потоки нельзя сломать: регистрация, вход, оплата, поиск, работа без сети.

Следом — критерии качества. В ТЗ приведите четкое разделение между допустимыми мелочами и тем, что сорвёт публикацию. Зафиксируйте, какие ошибки считаются критичными. Например:

• Потеря данных;
• Краш на старте;
• Невозможность войти;
• Зависание на оплате;
• Неверные суммы;
• Утечки персональных данных.

Пропишите роли: кто ведёт тестирование, подтверждает готовность к запуску, принимает решение «публикуем/стоп». Уточните требования к тем, кто исправляет баги: в каком формате отдавать сборку и что считается «исправлено» (например, ретест на тех же устройствах и сценариях).

Планирование сроков: 1) выделите окно на исправления, 2) заложите время на повторную проверку, 3) установите «день тишины» перед публикацией, когда изменения запрещены. Ситуации, когда правка перед релизом ломает приложение, бывали и случаются постоянно. Из-за спешки, сложности системы или невнимательности разработчика мелкое изменение может вызвать неожиданные проблемы в функциональности других модулей, привести к сбоям или исчезновению контента.

Мини-кейс

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

Уровень дефекта	Пример	Решение	Кто согласует
Блокер	Краш на старте, нельзя войти, оплата не проходит	Исправить до публикации, обязательный ретест	Заказчик + ответственный QA/PM
Критичный	Ошибка в расчётах, пропажа данных, зависания в ключевом сценарии	Исправить до релиза, допускается срочный хотфикс только по согласованию	Заказчик
Средний	Некорректный экран в редком сценарии, неверная валидация поля	Исправить в ближайшем спринте, релиз возможен при обходном пути	PM/заказчик
Низкий	Косметика: отступы, мелкие тексты, неидеальная анимация	В бэклог, чинить по приоритету	Исполнитель/PM

📌 Релиз мобильного приложения откладывается, если:

• приложение падает на старте или при входе;
• пользователь теряет данные или покупку;
• есть утечка персональных данных или доступ без авторизации.

Шаблон фразы для ТЗ

«Готовность к публикации подтверждается после смоук-прогона и регресса по критическим сценариям (вход, регистрация, оплата, поиск, офлайн). Блокеры не допускаются. Критичные дефекты закрываются до выкладки, после чего проводится повторная проверка на согласованной матрице устройств».

Тестирование мобильных приложений: 7 шагов

Логика такая: сначала проверяем, что приложение функционирует. Потом убеждаемся, что ничего не сломали. Дальше — перепроверяем исправления и только затем принимаем работу. Чаще всего релиз «тонет» на последней проверке обновления, пушей и редких сценариев. Их не любят тестировать, а пользователи как раз туда и попадают.

1. Зафиксируйте сборку и окружение
   Запишите номер версии, ветку, параметры сборки, стенды и тестовые аккаунты.
2. Смоук: 10–15 минут на «живое/неживое»
   Пройдите самый короткий путь пользователя: запуск → вход/регистрация → главный экран → ключевое действие (например, поиск или оформление).
3. Регресс по критическим сценариям
   Пройдите согласованные «основные потоки»: вход, профиль, поиск, корзина/оплата, офлайн-режим (если есть), уведомления. Это основной кусок проверки перед релизом.
4. Последняя миля: обновление, миграции, пуши, deeplink
   Проверьте обновление поверх предыдущей версии: перенос настроек, авторизации, кэша, черновиков. Затем — пуши (получение, открытие, переход на экран). И deeplink: ссылка должна вести в нужное место, а не на пустой экран.
5. Ретест исправлений
   Все найденные баги должны быть перепроверены на тех же устройствах и сценариях, где они проявлялись.
6. Приемка по критериям готовности
   Сверьте результат с тем, что прописали: нет блокеров, критичные дефекты закрыты, регресс пройден. Здесь же проверяйте интерфейс: явные косяки, которые бьют по доверию (обрезанные тексты, кнопки вне экрана, несоответствие состояния).
7. Соберите артефакты и принимайте решение
   Перед публикацией подготовьте список проверенных девайсов, чеклист с отметками, баг-репорты, краткий итоговый отчёт. По ним видно, что реально сделано и что осталось.

Устройства, ОС, сеть и прерывания

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

Сначала соберите простую матрицу совместимости устройств. Достаточно 6–10 моделей, которые дают максимум охвата: два «топа», два «середнячка», один бюджетный и один старый. Добавьте разные размеры экранов и хотя бы по одной версии ОС «на шаг назад». Так вы поймаете типовые ошибки интерфейса на основе поведения пользователей.

Дальше — сеть. Проверяйте не скорость, а смену условий. Обрывы, переход с Wi-Fi на LTE, кратковременные потери сигнала, режим полёта, роуминг. Ориентир — приложение не зависает, корректно показывает состояние и не теряет данные.

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

Последний риск — разрешения и ограничения ОС. Камера, геолокация, уведомления, фоновые задачи. Многие проблемы возникают, когда пользователь нажимает «Запретить», а приложение не умеет жить в таком режиме.

Мини-чек: 5 быстрых проверок на девайсе

1. Запретите уведомления и пройдите ключевой сценарий, где они важны.
2. Переключите сеть Wi-Fi ↔ LTE во время загрузки данных.
3. Сверните приложение на 30–60 секунд и вернитесь назад.
4. Примите входящий звонок и вернитесь в приложение.
5. Запретите геолокацию/камеру и посмотрите, как реагирует приложение.

Скорость, стабильность и батарея

Сначала прогоните базовые метрики на реальных устройствах. Проверьте холодный старт (после полного закрытия), время ответа на основные действия, лаги и фризы на длинных списках и тяжёлых экранах. Отдельно смотрите память: если приложение постепенно «наедает» её, через 10–15 минут начнутся вылеты.

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

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

И ещё один частый источник жалоб — офлайн. Если сеть пропала, приложение должно либо работать на кэше, либо честно показывать состояние и давать повторить запрос. После возврата в сеть важно корректно восстановиться: не терять введённые данные, не показывать «битую» ленту.

💡 Лайфхак: как проверить «плохую сеть»

Поставьте режим полёта на 3–5 секунд прямо во время загрузки данных. Затем включите сеть обратно. Повторите на Wi-Fi и на мобильной сети. Так быстро ловятся зависания, бесконечные спиннеры и неправильные повторы запросов.

Безопасность и данные пользователя

Сначала проверьте минимум, который должен выдерживать любой продукт: авторизацию, управление сессией и корректный выход. Затем — хранение и обмен данными. И отдельно — платежи.

Авторизация и сессии

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

Две проверки, которые часто забывают:

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

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

Хранение и обмен данными

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

Дальше — сеть и сертификаты. Важно, чтобы запросы шли по HTTPS и не было «обходных» вариантов, когда соединение падает на небезопасный режим. Отдельно посмотрите логи. Персональные данные и токены не должны попадать в логирование, особенно в продакшене.

Финальный чеклист перед публикацией

Это финальный прогон на 30–60 минут. Его цель — не «поймать всё на свете», а быстро убедиться, что релиз не упадёт на ровном месте. Лучше делать его по одной схеме. Тогда вы видите прогресс и меньше спорите о качестве.

Чек-лист тестирования приложения удобно проходить вдвоём: исполнитель ставит галочки и прикладывает доказательства (скрин, видео, номер сборки), а заказчик проверяет 2–3 самых критичных пункта и подтверждает выпуск. Если что-то не сходится, фиксируйте причину и решайте: правим сейчас или переносим релиз.

✓ Сборка и обновление

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

✓ Критические сценарии

• Запуск → вход/регистрация → главный экран проходит без сбоев.
• Ключевое действие продукта выполняется до конца (поиск, заказ, запись, доставка — что у вас главное).
• Отмена/ошибка на шаге оплаты или подтверждения обрабатывается корректно, без зависаний.
• Ввод данных в формы не теряется при сворачивании и возврате.

✓ Разрешения и ограничения ОС

• Отказ в геолокации/камере/уведомлениях не ломает сценарий, есть понятная реакция.
• Приложение нормально живёт после выхода из фона и после поворота экрана.
• Нет доступа к данным после выхода из аккаунта через «Назад» или кеш экранов.

✓ Аналитика и краши

• Нет повторяемых вылетов на старте и в ключевых сценариях.
• Ошибки сети не превращаются в бесконечный спиннер, есть повтор запроса.
• Логи не содержат токены и персональные данные (проверка хотя бы на одном типовом сценарии).

✓ Тексты и локализация

• Нет обрезанных строк, налезания кнопок и «прыгающей» верстки.
• Валюта, формат дат, единицы измерения отображаются корректно.
• Пустые состояния (нет данных, нет сети) выглядят понятно и честно.

✓ Метаданные для стора

• Иконка, скриншоты, описание, возрастной рейтинг и политика приватности готовы.
• Разрешения соответствуют реальным функциям (не просим лишнего).
• Ссылки внутри описания и политики открываются и ведут куда нужно.

✓ План отката

• Понятно, как откатываем релиз, если пошли массовые жалобы.
• Есть список «горячих» контактов и окно времени для быстрого фикса.
• Известно, какие метрики/сигналы считаем тревожными в первые часы после релиза.

❗ Если провалили любой пункт из блока «критические сценарии» — публикацию стоп. Даже если всё остальное выглядит нормально.

Заключение

Чёткий порядок проверок перед релизом снижает риск «внезапных» проблем уже после публикации — приемка становится прозрачной. Есть критерии готовности, список устройств и сценариев, а также понятные уровни дефектов. В итоге проще договориться об объёме правок без влияния эмоций. Когда баги оформлены одинаково, а ретест идёт по тем же шагам, проблема закрывается быстрее, возвращается очень редко. Спокойный запуск и меньше жалоб в первые дни.

Вам нужна биржа фриланса для новичков или требуются разработчики мобильных приложений?