Тестирование мобильного приложения: виды и этапы

Всё упирается в число переменных, которых в вебе просто нет. Главные из них и делают мобильное QA сложнее — заодно они объясняют, зачем вообще нужны отдельные виды тестов.

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

Прерывания. Телефон — это в первую очередь телефон. Во время работы приложения приходит звонок, СМС, push, срабатывает будильник, пользователь сворачивает приложение и возвращается через час. Приложение обязано пережить каждое такое прерывание, не потеряв данные и не упав. В вебе аналога нет.

Нестабильная сеть. Мобильное приложение живёт в мире, где связь то есть, то нет: метро, лифт, роуминг, переключение Wi-Fi на мобильный интернет посреди операции. Поведение при потере и восстановлении сети — отдельный пласт проверок.

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

Жесты, датчики, разрешения. Свайпы, поворот экрана, камера, геолокация, отпечаток пальца, запросы разрешений — всё это точки отказа, которых нет у сайта.

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

Полный набор проверок распределяют по видам — каждый отвечает за свой аспект качества.

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

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

Практический вопрос номер один: на чём вообще тестировать. Три варианта, и правильный ответ — их сочетание.

Эмуляторы (Android) и симуляторы (iOS) — виртуальные устройства на компьютере разработчика. Быстро, бесплатно, удобно на ранних этапах и для проверки разных размеров экрана. Но они не воспроизводят реальное железо: чипсет, датчики, реальную сеть, расход батареи, поведение при звонке. Баг, связанный с производительностью или спецификой устройства, эмулятор пропустит.

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

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

В вебе страница живёт на экране, пока пользователь её не закрыл. На телефоне приложение постоянно прерывают, и каждое прерывание — отдельный тест.

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

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

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

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

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

Приложение просит доступ к камере, геолокации, уведомлениям, контактам, файлам. Тестируют не только сценарий, где человек согласился.

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

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

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

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

Обязательный набор: обновление с предыдущей версии, обновление через одну-две версии (не все обновляются вовремя), запуск после обновления без сети, поведение при неполной миграции. Проверяют и обратную ситуацию: старая версия приложения продолжает работать у части пользователей, и сервер обязан отвечать обеим.

Здесь проходит пласт, которого нет в переводных гайдах, а для российского приложения он определяет часть тест-плана.

Магазины приложений. Помимо App Store и Google Play, приложение публикуют в RuStore, а иногда и в других российских каталогах. Каждый стор — свои требования к сборке, подписи и обновлению, и проверять установку с обновлением нужно для каждого канала, куда вы выкладываетесь.

Устройства без сервисов Google. На части новых Android-смартфонов, продающихся в России, нет предустановленных Google Mobile Services. Всё, что на них завязано, — push-уведомления через Firebase, карты Google, часть механик авторизации — на таком устройстве просто не работает.

Это нужно либо закладывать в архитектуру (push через RuStore, отечественные карты), либо явно тестировать на устройстве без GMS. Пропущенная проверка оборачивается тем, что у части аудитории не приходят уведомления, а команда об этом не знает.

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

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

Перед публикацией продукт показывают ограниченному кругу людей на их собственных устройствах — это ловит то, чего не видно на тестовом парке.

На iOS для этого есть TestFlight: сборка раздаётся по приглашениям или ссылке, тестировщики оставляют отзывы прямо из приложения. В RuStore работают два режима — закрытое тестирование для конкретного списка пользователей и публичная бета, доступная всем желающим через карточку приложения. Отзывы бета-тестировщиков в карточку не попадают и на рейтинг не влияют, поэтому бояться раннего негатива не стоит.

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

Логичный вопрос, раз кроссплатформа — одна кодовая база на iOS и Android. Разница есть, но не там, где её обычно ждут.

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

Но всё, что касается платформы, проверяется на обеих: приложение по-разному интегрируется с iOS и Android на уровне разрешений, уведомлений, работы с камерой и файлами. Экономия кроссплатформы приходится на логику, а тестирование устройств остаётся прежним; подробнее — в разборе нативной, гибридной и кроссплатформенной разработки.

Про деньги, чтобы было предметно: разработка мобильного приложения у нас начинается от 1,8 млн ₽ — QA, тестирование на парке устройств и публикация в сторах входят в работу, отдельной строкой их считать не нужно. Если приложение уже готово и нужно проверить его состояние, это аудит кода и архитектуры — 200–600 тыс. ₽ по объёму. Опишите задачу — оценим бесплатно.

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

Автоматизация в мобильном QA окупается не везде, и правильный ответ обычно смешанный.

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

Как устроены повторные прогоны, разобрано в материале про регрессионное тестирование, а про сквозные сценарии — в материале про E2E-тестирование.

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

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

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

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

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

3. Регресс на изменениях. При каждой доработке проверяют, что уже работавшее не сломалось. Устойчивые повторяемые сценарии автоматизируют и гоняют в CI/CD на каждую сборку — это регрессионное тестирование, без которого на живом мобильном продукте не обойтись.

4. Приёмка перед релизом. Полный прогон на реальном парке устройств, проверка установки и обновления во всех сторах, финальная оценка производительности и стабильности.

5. Мониторинг после релиза. Крашлитика и аналитика в проде: реальные устройства пользователей показывают то, что не поймал ни один тест-план. Данные из прода возвращаются в тест-план следующей версии.

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

Тестирование не заканчивается публикацией — просто источником данных становятся пользователи.

Первое, что настраивают до релиза, — сбор падений. Он показывает долю сессий без сбоев, конкретные места в коде и модели устройств, на которых проблема воспроизводится. Норма для живого продукта — выше 99 % сессий без падений; заметное проседание после релиза означает, что версию нужно откатывать или срочно чинить.

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

Третий — аналитика поведения. Экран, с которого массово уходят, обычно означает не потерю интереса, а сломанный или непонятный шаг, который не поймали на тестировании.

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

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

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

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

Code Pilots — студия заказной разработки полного цикла с мобильной экспертизой в ядре: приложения для VK Fest, Erarta, GigAnt, PetShop и других, отмеченные на профильных премиях. Кроссплатформу делаем на Flutter, под особые задачи — нативно; QA сопровождает разработку с первых спринтов и не подключается перед самой сдачей.

Внутри — сильная in-house команда: аналитики, продуктовые дизайнеры, мобильные разработчики, QA-инженеры и DevOps. Мы тестируем приложения так, как ими будут пользоваться: на реальном парке устройств, в российских условиях (RuStore, устройства без Google-сервисов, слабая сеть), с автоматизированным регрессом в CI/CD на каждую сборку.

За счёт отлаженных процессов и глубоко внедрённого в разработку AI мы запускаем продукты значительно быстрее рынка — обычно за 2–3 месяца — не жертвуя стабильностью.

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