С чего начать тестирование мобильных приложений

Привет! Эта статья рассчитана на тех, кто уже имеет опыт работы тестировщиком — вы тестируете веб-приложения или API, знаете основы клиент-серверной архитектуры, понимаете, как работает HTTP и умеете работать с инструментами вроде Postman, Swagger или DevTools.

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

Чем мобильное тестирование отличается от веба и API

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

1. Устройства и платформы

Фрагментация: на рынке десятки моделей смартфонов и планшетов: разные диагонали экранов, версии Android и iOS. Различаются форм-факторы и конфигурации экранов — от моноблоков до складных устройств (Flip/Fold), от вырезов под камеру («чёлка») до Dynamic Island. Всё это влияет на отображение элементов интерфейса и адаптивность верстки.
Особенности платформ: Android и iOS по-разному реализуют UI-компоненты, систему разрешений, работу с уведомлениями.

2. Пользовательский интерфейс (UI/UX)

На вебе вы работаете с браузером, который стандартизирует отображение.
В мобилке — у каждого устройства своя плотность пикселей (dpi), своя навигация (жесты, кнопки, свайпы).

3. Интеграция с системой

Приложение использует камеру, микрофон, геолокацию, push-уведомления, доступ к памяти.
Нужно проверять права доступа и корректность работы в разных состояниях.

4. Сеть и ресурсы

Пользователь может быть в метро без сети, на 3G или Wi-Fi.
Мобильные приложения должны корректно обрабатывать обрывы соединения и ограниченные ресурсы батареи/памяти.

5. Обновления и установка

Веб-приложение обновляется на сервере, и пользователь видит новые изменения сразу.
В мобильном мире приходится ставить апдейты через App Store или Google Play, а часть пользователей остаётся на старых версиях. Кроме того, каждое обновление проходит ревью в сторах — проверку на соответствие правилам и политикам платформ. Это влияет на релизный цикл: баг или несоответствие требованиям стора (например, отсутствующее разрешение на сбор данных) может задержать публикацию или привести к отклонению сборки, а также влияет на стоимость бага в целом.

Инструменты

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

Эмуляторы (Android Studio AVD) и симуляторы (Xcode Simulator) удобны для быстрых проверок, но всегда нужно помнить, что реальное устройство надёжнее — только на нём можно проверить производительность, работу с железом без моков (камера, GPS, датчики).

Следующий шаг — установка инструментов. Даже если вы не планируете писать код, полезно поставить Android Studio или Xcode. Эти IDE позволяют работать со сборками и логами, подключать эмуляторы и удобно управлять приложением.

Для Android поставьте ADB (Android Debug Bridge). С его помощью можно ставить и удалять apk-файлы, снимать логи, делать скриншоты и управлять устройством через консоль.

На iOS аналогичную роль частично выполняет Xcode и его утилиты, например simctl для работы с симуляторами.

Ещё один важный слой инструментов — это снифферы трафика, такие как Charles Proxy, Fiddler или Proxyman. С их помощью можно перехватывать и анализировать сетевые запросы между приложением и сервером, проверять корректность передаваемых данных, заголовков и параметров, а также отлавливать лишние или повторяющиеся обращения к API. Это незаменимые помощники для локализации багов.

Тестирование

Когда окружение готово, можно переходить непосредственно к тестированию. Начните с установки приложения. Обычно у вас есть два варианта: тестовая сборка, которую вы получаете от разработчиков или через систему дистрибуции (например, Firebase App Distribution, TestFlight или просто apk/ipa-файл), и релизная версия из App Store или Google Play. Сравнение поведения этих версий полезно: тестовая может содержать отладочные логи или новые фичи (которых ещё нет у пользователей), а релизная — максимально приближена к тому, что видят пользователи.

Параллельно с ручным тестированием всегда смотрите логи. На Android для этого используется Logcat, на iOS — системная Console. Это поможет увидеть дублирующиеся вызовы, ошибки при обработке ответов или повторные попытки при нестабильной сети.

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

Android — Logcat: фильтруйте по тегу или компоненту сетевого слоя — adb logcat | grep -i YourNetworkTag
iOS — Xcode или Console.app: подключите устройство к Mac и просматривайте системные и app-логи.

Отдельно проверяйте работу приложения в разных сетевых условиях. Пользователи редко находятся в идеальных условиях, поэтому важно симулировать отключение интернета, переключение с Wi-Fi на мобильные данные или работу на слабом соединении (3G). Это можно делать в реальных условиях (например, выйти из зоны покрытия) и с помощью встроенных инструментов — Network Link Conditioner на iOS или эмуляции сети в Android Studio. Также многие снифферы (Charles, Proxyman и др.) умеют ограничивать скорость, добавлять задержку и потерю пакетов.

Типичные ошибки

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

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

Нередко новички не обращают внимания на версионность платформ и устройств. В мобилке же один и тот же экран может выглядеть нормально на Android 14, но ломаться на Android 11, или отлично работать на iPhone 14, но зависать на iPhone SE с меньшим экраном и другим железом. Игнорирование этой фрагментации приводит к тому, что часть багов обнаруживают только пользователи в отзывах стора.

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

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

И наконец, начинающие тестировщики редко системно работают с логами. Многие ограничиваются визуальной проверкой и не заглядывают в Logcat или Console. В результате баги, которые можно было бы поймать на раннем этапе (ошибки авторизации, проблемы с кэшем, утечки памяти), остаются незамеченными. Привычка всегда снимать логи параллельно с тестированием сильно повышает шанс найти скрытые дефекты.

Статьи, которые помогут углубиться в мир мобильного тестирования

Android

iOS

Общее

Обсудить статью, узнать больше можно в телеграм канале «Тестировщики нужны».