На сайте баг можно закрыть за час: исправление выкатывается на сервер, и через несколько минут его видят все посетители. С мобильным приложением так не получится — новая сборка сначала проходит модерацию магазина (от нескольких часов до нескольких дней, причины отказов разобраны в статье о публикации в RuStore, App Store и Google Play), а после публикации далеко не все пользователи обновляются сразу — часть будет пользоваться версией с известной ошибкой ещё неделями.
Поэтому тестирование мобильного приложения — не финальная галочка перед сдачей, а процесс, который идёт параллельно разработке с первой рабочей сборки. Ниже — какие виды проверок нужны, что проверяют только в мобильных приложениях, как выбрать устройства для тестов, когда окупаются автотесты, как устроено бета-тестирование в разных магазинах и как принимать готовую работу у подрядчика.
Виды тестирования мобильного приложения
Ни один вид проверки не заменяет остальные — они закрывают разные риски. Таблица ниже — ориентир, что именно проверяет каждый вид, кто обычно его выполняет и на каком этапе он нужен.
| Вид | Что проверяет | Кто обычно делает | Когда |
|---|---|---|---|
| Функциональное | Сценарии работают так, как описаны в ТЗ: форма отправляется, оплата проходит, данные сохраняются | Тестировщик или сам разработчик | Каждая итерация, каждая новая функция |
| Регрессионное | Изменения не сломали то, что уже работало раньше | Тестировщик, частично можно автоматизировать | Перед каждым релизом |
| UI / вёрстка | Соответствие макетам: отступы, шрифты, обрезанный или наезжающий текст на разных экранах | Тестировщик или дизайнер | После вёрстки каждого экрана и перед релизом |
| Юзабилити | Понятно ли пользоваться приложением без подсказок и инструкции | Тестировщик или реальные пользователи | На прототипе и перед публичным релизом |
| Совместимость (устройства/ОС) | Работа на разных моделях, версиях ОС, размерах экрана | Тестировщик на матрице устройств (см. ниже) | Перед значимыми релизами |
| Производительность и батарея | Время запуска, плавность интерфейса, расход памяти и заряда | Тестировщик с профилировщиком из среды разработки | Перед релизом и после заметных изменений в коде |
| Сеть | Поведение при слабом сигнале, полном отсутствии сети, переключении Wi-Fi ↔ мобильный интернет | Тестировщик, с эмуляцией плохой сети | Обязательно перед каждым релизом |
| Прерывания | Входящий звонок, push-уведомление, сворачивание приложения, блокировка экрана | Тестировщик вручную на реальном устройстве | Перед релизом |
| Безопасность | Хранение токенов на устройстве, передача данных только по HTTPS, права доступа на сервере | Разработчик или отдельный аудит | Перед первым релизом и после изменений в авторизации |
| Локализация | Переводы, форматы дат, чисел и валют, длина текста в интерфейсе | Тестировщик, владеющий целевым языком | Если приложение выходит на нескольких языках |
| Обновление поверх старой версии | Данные и настройки пользователя сохраняются после апдейта, а не сбрасываются | Тестировщик на «состаренной» установке предыдущей версии | Перед каждым релизом, где меняется структура данных |
Последняя строка — тест обновления — на практике пропускают чаще всего, а именно он ловит одни из самых неприятных багов: потерю данных или аварийное закрытие сразу после апдейта у всей активной аудитории.
Что проверяют только в мобильных приложениях
Часть проверок не имеет аналога в вебе — они связаны с тем, что приложение живёт в операционной системе телефона, а не в браузорной вкладке.
- Разрешения и отказ в них. Камера, геолокация, уведомления, доступ к контактам — приложение должно понятно объяснять, зачем нужен доступ, и корректно работать (или явно объяснять ограничение), если пользователь его не дал. Сценарий «отказал в разрешении, а дальше белый экран» — частая находка на тестировании.
- Жизненный цикл приложения. Переход между активным состоянием, фоном и полной выгрузкой из памяти не должен приводить к потере введённых данных — например, незаполненной формы после свёрнутого приложения.
- Фоновые ограничения. И Android, и iOS ограничивают работу приложения в фоне ради экономии батареи. Фоновую синхронизацию или геолокацию нужно проверять именно в этих условиях, а не только пока экран открыт.
- Разные размеры экранов и вырезы камеры. Важные элементы интерфейса — кнопки, текст, поля ввода — не должны попадать под вырез камеры, скруглённые углы или системные жесты по краям экрана.
- Тёмная тема. Если приложение её поддерживает, нужно отдельно проверить контраст текста и иконок — то, что хорошо читается на светлом фоне, может стать нечитаемым на тёмном.
- Крупный шрифт и системные настройки доступности. Пользователь может увеличить масштаб шрифта в настройках телефона — текст не должен обрезаться или наезжать на соседние элементы.
- Жесты. Свайпы, системный жест «назад», работа одной рукой на большом экране — стоит проверить, что жесты приложения не конфликтуют с системными жестами ОС.
Как выбрать устройства для тестирования
Тестировать на «одном айфоне разработчика» — самая частая причина, почему приложение падает у части пользователей сразу после релиза. Матрицу устройств строят на двух источниках:
- Собственная аналитика. Если приложение уже запущено или есть сайт с похожей аудиторией, счётчики показывают, какие модели и версии ОС реально используют ваши пользователи, — это надёжнее любой общей статистики.
- Официальные данные магазинов и производителей ОС. Актуальное распределение версий Android доступно прямо в Android Studio; распределение версий iOS Apple публикует на developer.apple.com/support/app-store. Цифры там обновляются регулярно — смотрите их перед планированием теста, а не берите из старой статьи.
Для нового продукта без собственной аналитики разумный стартовый набор — по 1–2 модели с наименьшим и наибольшим экраном на каждой платформе, одна модель со старой, но ещё распространённой версией ОС, и один бюджетный Android-телефон: слабое железо и нестандартные прошивки чаще всего показывают проблемы, не видные на флагманах.
| Способ | Плюсы | Ограничения |
|---|---|---|
| Реальные устройства | Точное поведение камеры, GPS, датчиков, реальной сети и батареи | Нужно закупать и обновлять парк; покрыть все модели физически невозможно |
| Эмуляторы и симуляторы | Быстро запустить любую версию ОС и размер экрана без покупки железа; удобны на этапе разработки | Не всегда точно повторяют производительность, датчики и особенности прошивок конкретных производителей |
| Облачные фермы устройств | Доступ к сотням реальных моделей без их покупки, часто с поддержкой автотестов | Платная услуга; для регулярного использования выбор конкретного провайдера стоит делать по своим требованиям — сравнение сервисов выходит за рамки этой статьи |
На практике работает комбинация: разработка и первые проверки — на эмуляторах, приёмка перед релизом — на нескольких реальных устройствах из матрицы, а расширенное покрытие моделей — через облачную ферму, если это оправдывают бюджет и частота релизов.
Ручное и автоматизированное тестирование
Автотесты не заменяют ручное тестирование полностью — они закрывают повторяющиеся проверки и освобождают время тестировщика для новых функций и юзабилити, которые сложно формализовать в скрипт.
- Unit-тесты. Проверяют отдельные функции и модули кода без запуска интерфейса — самые быстрые и дешёвые в поддержке, пишет их разработчик по ходу работы.
- UI-тесты. Автоматически кликают по интерфейсу и проверяют, что элементы на месте и реагируют правильно. На iOS для этого используют XCTest, на Android — Espresso; это официальные инструменты Apple и Google, а не сторонние продукты.
- End-to-end тесты. Проверяют целый пользовательский сценарий от начала до конца, часто включая обращения к серверу — самые дорогие в написании и поддержке, но и самые близкие к реальному поведению пользователя.
Автотесты окупаются, когда одинаковые проверки приходится повторять часто: регресс перед каждым релизом, частые итерации, сценарии с деньгами или безопасностью, где цена пропущенной ошибки высока. Для небольшого приложения с редкими релизами полный набор на старте обычно не нужен — стоит начать с unit-тестов для критичной логики и добавлять UI- и e2e-тесты по мере роста продукта.
Автотесты, запускаемые автоматически при каждом изменении кода (в CI — системе непрерывной интеграции), ловят регресс раньше, чем до него дойдёт очередь у тестировщика, и снижают риск, что сборка с очевидной ошибкой вообще попадёт на ручную проверку.
Бета-тестирование в магазинах приложений
Перед публичным релизом полезно показать сборку ограниченной группе реальных пользователей — это ловит проблемы, которые не видны в тестовой среде: незнакомые модели устройств, непривычные сценарии использования, неожиданные вопросы к интерфейсу. У каждого магазина свой формат.
iOS: TestFlight
Официальный инструмент Apple. Внутреннее тестирование — до 100 участников команды в App Store Connect, доступно почти сразу после загрузки сборки. Внешнее — до 10 000 тестировщиков, но первая сборка каждой версии для внешних тестов проходит отдельную проверку Apple. Тестовая сборка доступна 90 дней с момента загрузки, дальше её нужно обновить.
Android: закрытое тестирование Google Play
Для новых личных (не организационных) аккаунтов разработчика закрытое тестирование по списку тестировщиков обязательно перед доступом к публикации — минимум 12 тестировщиков непрерывно в течение 14 дней подряд. Подробнее условия и дата, с которой действует требование, разобраны в статье о запуске MVP к первым пользователям.
RuStore
Альфа-тестирование — сборка скрыта от общего каталога и доступна только приглашённым тестировщикам по идентификатору или ссылке. Отдельно в RuStore доступно публичное бета-тестирование для более широкой аудитории. Условия могут уточняться — перед запуском стоит свериться с текущей документацией RuStore для разработчиков.
Обратную связь от бета-тестировщиков удобнее собирать через короткую форму с прямыми вопросами (что не получилось, что было непонятно, упало ли приложение) плюс отчёты о крашах из самого магазина — впечатления «вроде нормально» без конкретных сценариев мало помогают находить проблемы.
Приёмка работы у подрядчика
Приёмка — не один финальный созвон, а сверка результата с тем, что было зафиксировано в договоре и техническом задании ещё на старте проекта. Формулировки сценариев и критериев приёмки, по которым удобно принимать функции, разобраны в статье о техническом задании на мобильное приложение; как прописать этапы и критерии приёмки в самом договоре — в статье о выборе подрядчика.
Тестовая документация, которую разумно запросить у подрядчика вместе со сборкой: чек-листы проверки (по каким сценариям и на каких устройствах прогонялась сборка), тест-кейсы на ключевые сценарии из ТЗ и баг-репорты — список найденных и исправленных ошибок, а не только финальная «чистая» сборка без истории.
Найденные дефекты стоит сразу классифицировать по серьёзности, а не считать их равнозначными:
| Уровень | Пример | Блокирует релиз |
|---|---|---|
| Блокер | Приложение падает при запуске или на ключевом сценарии, данные пользователя теряются | Да, всегда |
| Критичный | Ключевая функция работает неправильно, но есть обходной путь или она не на главном экране | Обычно да |
| Существенный | Второстепенная функция работает некорректно, заметная ошибка в интерфейсе | По договорённости, часто переносится в план после релиза |
| Незначительный | Опечатка, небольшое расхождение с макетом, которое не мешает пользоваться приложением | Нет |
Что считать блокером релиза, стоит определить заранее и зафиксировать в договоре или чек-листе приёмки — иначе спор о готовности сборки каждый раз решается заново на эмоциях, а не по согласованному критерию.
- Запросить тестовую документацию. Чек-листы, тест-кейсы, список известных ограничений сборки.
- Прогнать сценарии из ТЗ самостоятельно или силами независимого тестировщика. Не полагаться только на отчёт подрядчика о собственной работе.
- Проверить сборку на устройствах из своей матрицы, а не только на том телефоне, с которого удобно смотреть демо.
- Завести найденные дефекты с классификацией по серьёзности и зафиксировать срок их исправления.
- Повторно проверить блокеры и критичные дефекты после исправления — устранение одного бага иногда создаёт новый по соседству.
- Подписать акт приёмки этапа только после закрытия блокеров, а не «с открытыми замечаниями на будущее».
После релиза: что отслеживать
Тестирование не заканчивается публикацией — часть проблем видна только на реальном трафике устройств, которые невозможно было полностью покрыть тестами. Ключевые сигналы — доля пользователей без сбоев (crash-free) и частота зависаний ANR на Android; что это значит и как за этим следить в консолях магазинов, разобрано в статье о метриках мобильного приложения. Как организовать регулярный мониторинг и на кого возложить реакцию на проблемы после релиза — в статье о поддержке приложения после релиза.
Частые ошибки тестирования
- Тестируют только на телефоне разработчика. Один флагман с быстрым интернетом не показывает проблемы, с которыми столкнётся пользователь бюджетного Android с медленной сетью.
- Не проверяют обновление поверх предыдущей версии. Свежая установка на чистое устройство и обновление уже стоящего приложения — разные сценарии, и именно второй чаще ловит потерю данных.
- Не тестируют плохую сеть и офлайн. В офисе с хорошим Wi-Fi проблема с обработкой обрыва соединения просто не проявляется.
- Тестируют «в конце» вместо каждой итерации. Чем позже находится ошибка, тем дороже её исправлять — особенно если она встроена в архитектуру, а не в один экран.
- Не готовят тестовые аккаунты для модерации магазина. Если приложение требует входа, а демо-доступа для модератора нет, это одна из частых причин отказа при публикации — подробнее в статье о частых причинах отказа.
Частые вопросы
Сколько устройств нужно для тестирования?
Для небольшого проекта без собственной аналитики достаточно стартового набора: по одной модели с самым маленьким и самым большим экраном на каждой платформе, одна модель со старой, но ещё распространённой версией ОС, и один бюджетный Android-телефон. Если у продукта уже есть аудитория, матрицу строят по её реальному распределению устройств, а не по общим догадкам.
Можно ли обойтись без отдельного тестировщика?
Для очень простого приложения на старте функциональные проверки может выполнять и сам разработчик или менеджер проекта по чек-листу. Но по мере роста числа сценариев и устройств риск пропустить регресс растёт, и отдельная роль (штатная, у подрядчика или на аутсорсе) обычно окупается уже на втором-третьем релизе.
Сколько времени закладывать на тестирование?
Ориентировочно 10–20% от общего времени проекта — такая же доля, что и в разбивке этапов разработки в статье «Этапы разработки мобильного приложения». Долю стоит закладывать в план сразу, а не искать время на тестирование за счёт сокращения сроков перед самым релизом.
Нужны ли автотесты для MVP?
Обычно нет смысла писать полный набор UI- и e2e-тестов для первой версии, которая ещё может кардинально измениться после проверки гипотезы. Разумный минимум — unit-тесты для критичной логики (расчёты, оплата, авторизация); остальное добавляется по мере того, как продукт и частота релизов растут.
Кто отвечает за баги, найденные после релиза?
Это должно быть прописано в договоре: обычно ошибки, допущенные при разработке, подрядчик исправляет бесплатно в течение гарантийного периода, а дальнейшая поддержка и исправление новых проблем — отдельная платная услуга. Подробнее — в статье о поддержке приложения после релиза.
Что такое регрессионное тестирование (регресс)?
Проверка того, что изменения в коде — новая функция или исправление одного бага — не сломали то, что уже работало раньше. Регрессионное тестирование делают перед каждым релизом, и именно его чаще всего есть смысл автоматизировать в первую очередь, поскольку набор проверяемых сценариев со временем растёт, а повторять их вручную с каждым релизом становится всё дольше.
Чек-лист перед отправкой в магазины
- Пройдены все ключевые сценарии из ТЗ на актуальной сборке
- Проверено обновление поверх предыдущей версии, а не только чистая установка
- Приложение проверено минимум на нескольких устройствах из матрицы, включая бюджетный Android
- Проверена работа при слабой сети, полном отсутствии интернета и переключении сетей
- Проверены прерывания: входящий звонок, push, сворачивание, блокировка экрана
- Проверена реакция на отказ в разрешениях (камера, геолокация, уведомления)
- Проверены крупный размер шрифта и, если поддерживается, тёмная тема
- Все найденные дефекты классифицированы по серьёзности, блокеры и критичные — закрыты
- Подготовлен демо-доступ для модератора магазина, если приложение требует авторизации
- Настроен сбор отчётов о крашах и ANR на первую неделю после релиза
- Если применимо — пройдено закрытое или альфа-тестирование в нужном магазине до подачи на публикацию
Итог
Тестирование мобильного приложения — не один этап перед сдачей, а набор проверок разного типа, часть из которых специфична именно для мобильных устройств: разрешения, жизненный цикл, фоновые ограничения, разные экраны и сети. Матрицу устройств стоит строить по собственной аналитике или актуальным официальным данным, а не по одному телефону разработчика, а тест обновления поверх старой версии — включать в план обязательно, даже если он кажется формальностью.
При приёмке главное — заранее договориться, что считается блокером релиза, и требовать не «чистую» сборку без единого замечания, а тестовую документацию и классификацию дефектов, по которой видно, что и как проверялось.