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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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