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

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

Из каких этапов состоит тестирование мобильного приложения?

Тестирование — это не один прогон в конце, а последовательность шагов, которая начинается задолго до релиза.

Анализ требований и тест-план

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

Разработка тест-кейсов

Каждый сценарий из тест-плана расписывается в конкретные шаги: что сделать, что должно произойти. Тест-кейс на регистрацию — это не «зарегистрироваться», а десяток отдельных проверок: корректный email, некорректный email, слабый пароль, повторная регистрация на тот же номер, обрыв сети посреди отправки формы.

Настройка тестового окружения

Параллельно готовится набор устройств и эмуляторов, тестовый backend с контролируемыми данными (чтобы не портить продовую базу) и доступы — тестовые аккаунты, песочницы платёжных систем, стенды для push-уведомлений.

Функциональное тестирование: что именно проверяют

Это ядро QA — проверка того, что приложение делает то, что должно. Сюда входят: регистрация и вход (включая восстановление пароля и вход через соцсети), все ключевые пользовательские сценарии от начала до результата, а не только «счастливый путь», и обработка ошибок ввода — что произойдёт, если пользователь введёт не то, оставит поле пустым или дважды нажмёт кнопку оплаты. Именно на границах — пустых полях, дублирующихся нажатиях, неожиданных символах — живёт большинство продовых багов.

UI/UX и usability-тестирование

Здесь проверяют не «работает ли», а «удобно ли». Соответствует ли то, что получилось, макетам дизайнера (отступы, шрифты, состояния кнопок), понятна ли навигация человеку, который видит приложение впервые, и не приходится ли ему гадать, куда нажать дальше. Хорошая практика — показать сборку 3–5 людям вне команды и просто посмотреть, где они спотыкаются: разработчик, который две недели смотрит на интерфейс, перестаёт замечать очевидные неудобства.

Тестирование производительности

Проверяется время отклика экранов и запросов к серверу, потребление памяти (нет ли утечек при долгой работе), расход батареи и поведение приложения под нагрузкой — например, при большом списке данных или слабом канале связи. Приложение, которое «тормозит» на бюджетном устройстве через полгода использования, теряет пользователей быстрее, чем приложение с одним заметным, но редким багом.

Тестирование безопасности

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

Совместимость: устройства, версии ОС, размеры экранов

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

Тестирование в реальных сетевых условиях

Офис разработчика — это, как правило, быстрый Wi-Fi. Пользователь открывает приложение в метро, в лифте или на даче со слабым 3G. Поэтому отдельно проверяют поведение на медленной сети, при потере соединения посреди действия и в офлайн-режиме — если приложение вообще предполагает работу без сети. Хуже всего, когда при обрыве связи приложение просто зависает без объяснения: пользователь решает, что оно сломано, и удаляет его.

Локализация и доступность (accessibility)

Если приложение выходит на нескольких языках, проверяют не только перевод, но и то, что интерфейс не «ломается» от более длинных фраз — немецкий или финский текст часто в полтора раза длиннее русского. Базовые требования доступности — это адекватный размер шрифта и его масштабируемость, достаточный контраст текста и корректная работа с экранными читалками (VoiceOver, TalkBack) хотя бы на ключевых экранах. Это не только про инклюзивность — Apple и Google всё активнее учитывают такие сигналы при модерации и ранжировании в сторах.

Установка, обновление и миграция данных

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

Что тестируют реже, но зря?

Есть категория сценариев, которую легко забыть, потому что она не входит в «основной путь» приложения, но именно в ней часто прячутся неприятные баги: корректная доставка и обработка push-уведомлений (в том числе когда приложение закрыто), диплинки — открытие конкретного экрана по ссылке из письма или соцсети, и поведение приложения при прерывании: входящий звонок, уведомление другого приложения, сворачивание в фон посреди заполнения формы. Пользователь не прощает приложению, которое «забывает» введённые данные после десятисекундного звонка.

Ручное или автоматизированное тестирование — что выбрать для MVP

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

Чек-лист перед отправкой в App Store и Google Play

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

Сколько стоит и сколько занимает тестирование

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

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

Сколько времени занимает тестирование перед релизом?

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

Можно ли выпустить MVP без полноценного QA?

Полностью без тестирования — нет: минимальная проверка ключевого сценария нужна в любом случае, иначе гипотезу будет проверять не продукт, а поток жалоб. А вот объём QA для MVP действительно можно сократить — сфокусироваться на главном сценарии и критичных для безопасности местах, отложив глубокое покрытие редких кейсов.

Что делать, если баг нашли уже после публикации в сторе?

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

Нужно ли тестировать на реальных устройствах или достаточно эмуляторов?

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

Чем тестирование iOS-приложения отличается от Android?

Главное отличие — фрагментация: у iOS небольшое число актуальных устройств и версий ОС, у Android — сотни комбинаций производителей, экранов и прошивок, поэтому Android-тестирование требует более широкого набора устройств. У платформ также разные стандартные жесты и требования модерации в сторах — их тоже нужно проверять отдельно.

Кто должен проводить тестирование — разработчик или отдельный QA-специалист?

Разработчик обязательно проверяет свой код сам (это часть работы, а не замена QA), но независимый взгляд отдельного тестировщика находит больше — автор кода склонен неосознанно избегать сценариев, которые он считал «очевидными» при написании. Для MVP роль QA иногда берёт на себя проектный менеджер или второй разработчик в команде; для более сложных продуктов оправдан отдельный QA-специалист.

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