Контекст

Когда QA-инженер переходит с web-проектов на мобильные, первое, что бросается в глаза — иллюзия сходства. Приложение на экране, форма, кнопки, переходы по страницам. Но под этой поверхностью — принципиально другая среда выполнения. Браузер изолирует web-приложение от операционной системы, предоставляя унифицированный слой. Мобильное приложение живёт прямо внутри ОС: оно конкурирует за оперативную память, реагирует на входящие звонки, теряет фокус при уведомлениях, работает с гироскопом и камерой. Тестировщик обязан учитывать это на каждом шаге.

Web работает в sandbox браузера; mobile — непосредственно в ОС, с прямым доступом к hardware.
Пользователь может прервать сессию звонком, уведомлением или нажатием кнопки Home в любую секунду.
Мобильный трафик дорогой и нестабильный: переключение 4G → 3G → Wi-Fi происходит на ходу.
Экранная клавиатура меняет layout страницы, закрывая активные поля ввода.
Жесты (свайп, пинч, тап по двойному касанию) не имеют точных аналогов у мыши.
Размер батареи и тепловыделение — реальные ограничения, которых нет у web в браузере.

Рабочий алгоритм

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

Определите, какие hardware-ресурсы использует фича: камера, GPS, Bluetooth, NFC, гироскоп.
Пропишите сценарии прерывания: входящий звонок, SMS, push-уведомление другого приложения, кнопка Home, переключение многозадачности.
Проверьте поведение при изменении сети: потеря сети, переключение между Wi-Fi и мобильным интернетом, режим полёта.
Проверьте ориентацию экрана: portrait → landscape и обратно в середине сценария.
Убедитесь, что клавиатура не перекрывает ключевые элементы управления (особенно кнопку «Сохранить» или «Отправить»).
Добавьте сценарий с низким зарядом батареи или при включённом режиме энергосбережения.
Убедитесь, что статус-бар (время, уведомления) не перекрывает контент приложения.

Пример из практики

В финтех-приложении для Android нужно было протестировать форму перевода денег. QA написал полный set позитивных и негативных тест-кейсов — как для web. Но релиз принёс баг P1: если пользователь вводил сумму, в этот момент приходил push с промо-акцией, пользователь тапал по уведомлению, потом возвращался в приложение через Recent Apps — введённая сумма обнулялась, а иконка загрузки зависала. Причина: активити не сохраняла состояние при переходе в background, а переинициализация компонента не восстанавливала viewmodel. Такой баг невозможно поймать web-подходом — нужен явный тест-кейс «прерывание в середине заполнения формы».

Частые ошибки

Новички в mobile QA регулярно воспроизводят одни и те же промахи, перенося web-привычки без адаптации.

Тестируют только на одном устройстве с постоянным Wi-Fi — не воспроизводят реальную мобильную среду.
Забывают про прерывания: не добавляют тест-кейсы на звонок, SMS и уведомление в середине сценария.
Проверяют UI только в portrait — упускают критические переполнения при landscape.
Не проверяют поведение после принудительного закрытия процесса (kill через Recent Apps) — приложение может не восстанавливать сессию.
Игнорируют разрешения: не проверяют отказ пользователя в доступе к камере/геолокации на уровне системного диалога.

✅ Самопроверка

1Почему нельзя напрямую переносить web-тест-кейсы в мобильное тестирование?

Потому что мобильное приложение работает непосредственно в ОС без браузерного sandbox, подвержено прерываниям (звонки, уведомления), зависит от hardware (GPS, камера) и сети, которая нестабильна. Эти факторы отсутствуют в типичной web-среде.

2Назовите три мобильных прерывания, которые обязательно нужно тестировать.

Входящий звонок, push-уведомление от другого приложения, нажатие кнопки Home с последующим возвратом через Recent Apps.

3Как экранная клавиатура влияет на тестирование форм на мобильном?

Клавиатура перекрывает нижнюю часть экрана и может скрыть кнопку отправки или поля ввода. Нужно проверять, что после появления клавиатуры все ключевые элементы управления остаются доступны или экран корректно прокручивается.

4Что такое тепловой троттлинг и почему он важен для мобильного QA?

Тепловой троттлинг — автоматическое снижение частоты процессора, когда устройство перегревается. Это вызывает лаги и зависания в UI. QA должен проверять поведение приложения при длительной нагрузке (видео, игры, фоновая синхронизация), когда устройство разогрето.

5Почему тестирование только на одном устройстве с постоянным Wi-Fi недостаточно для мобильного приложения?

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