Мобильное приложение работает в среде, которую команда контролирует лишь частично. Пользователь меняет сеть, блокирует экран, запрещает камеру, увеличивает шрифт и возвращается в приложение через уведомление. ОС может ограничить фоновую работу или завершить процесс. Для mobile QA эти события — обычные условия эксплуатации.
Главная особенность мобильного тестирования — необходимость проверять бизнес-сценарий вместе с устройством, системой и переходами между состояниями. Экран, который корректно работает после чистого запуска, может потерять данные после короткого переключения в другое приложение.
Какие слои участвуют в сценарии
Полезная модель включает интерфейс, локальные данные, сетевой обмен, backend и системные интеграции. Нажатие «отправить» может сначала изменить локальную запись, поставить операцию в очередь и только позже подтвердить её на сервере.
Поэтому видимый успех не всегда означает завершение операции. QA уточняет источник истины: что уже сохранено, что ожидает синхронизации и что должно увидеть другое устройство. Без этой модели легко назвать потерей данных корректную задержку или, наоборот, принять локальную иллюзию успеха за рабочую функцию.
Жизненный цикл и восстановление
Различайте активное приложение, переход в фон, возвращение, новый запуск и восстановление после завершения процесса. Эти состояния похожи внешне, но могут использовать разные механизмы хранения данных.
Проверьте, что происходит с формой, навигацией, загрузкой и сессией. На Android экран может пересоздаваться при изменении конфигурации; сохранение состояния нужно проверять явно. Принудительное закрытие пользователем, системное завершение и обычное сворачивание — разные сценарии, их не следует описывать одним шагом «перезапустить приложение».
Сеть как меняющееся условие
Проверяйте хорошую, медленную и недоступную сеть, переключение Wi-Fi и мобильной связи, разрыв во время передачи. Важны таймауты, завершение индикатора и результат повторного действия.
Offline не равен пустому экрану и не всегда означает полную автономную работу. Продукт должен явно определять, что доступно из кэша, что можно редактировать и когда изменения отправляются. Повторная синхронизация не должна создавать дубли или молча перезаписывать более новые данные без согласованного правила.
Разрешения и системные интеграции
Камера, геолокация, уведомления и доступ к выбранным данным имеют собственные разрешения и ограничения. Проверяйте первое обращение, согласие, отказ и отзыв права через настройки. Конкретные варианты зависят от ОС и версии.
Разрешение должно запрашиваться в понятном контексте. Если пользователь отказал камере, приложение должно предложить предусмотренный запасной путь либо объяснить недоступность функции. Отказ от необязательного права не должен блокировать несвязанные действия. Отдельно проверяйте возврат после системного окна, выбора файла, оплаты или внешнего входа.
Устройство, интерфейс и доступность
Маленький экран, крупный системный текст, вырезы, клавиатура и разные способы навигации меняют взаимодействие. Учитывайте ориентацию, тему, локаль и длинные данные. Для складных устройств и планшетов могут быть важны смена размеров и многооконный режим.
- →Можно ли увидеть и нажать подтверждение при открытой клавиатуре?
- →Сохраняется ли смысл подписей при увеличенном тексте?
- →Понятны ли названия и порядок элементов в VoiceOver или TalkBack?
- →Не конфликтует ли жест приложения с системной навигацией?
Проверки выбираются по поддерживаемым устройствам и функциям, а не по максимальному числу экранов ради отчёта.
Установка и обновления
Установленный клиент может жить у пользователя месяцами и работать с обновляемым backend. Поэтому проверяйте не только чистую установку, но и обновление с поддерживаемой предыдущей версии, сохранение локальных данных, сессии и настроек.
Особый риск — миграция локального хранилища. Подготовьте старую версию с реалистичными данными, обновите приложение и сравните состояние. Удаление приложения перед каждым прогоном убирает накопленный контекст и скрывает именно те дефекты, с которыми сталкиваются постоянные пользователи.
Как выбирать устройства
Матрица опирается на аудиторию, минимальную поддержку ОС, характеристики памяти и экрана, производителей и риск функций. Одна новая флагманская модель не представляет весь парк.
Эмуляторы и симуляторы удобны для воспроизводимости, разных конфигураций и автоматизации. Реальные устройства нужны для подтверждения работы конкретного железа, энергопотребления, производительности и системных интеграций. Их используют совместно: сначала быстро локализуют проблему, затем подтверждают в нужном пользовательском окружении.
Практический пример: отправка фотоотчёта
Пусть сотрудник делает фото, добавляет комментарий и отправляет отчёт. При отсутствии сети продукт обещает сохранить черновик и явно показать ожидание отправки.
- 1.Создайте отчёт с разрешённой камерой. Ожидается доступное фото и сохранённый комментарий.
- 2.Начните передачу и переключите сеть. Ожидается определённый статус, а не бесконечный loading и ложное подтверждение.
- 3.Сверните приложение, заблокируйте экран и вернитесь. Ожидается сохранение черновика и корректное восстановление процесса по требованиям.
- 4.Восстановите сеть и повторите действие. Ожидается одна серверная запись с полным вложением, доступная после нового чтения.
- 5.Повторите создание после отзыва разрешения камеры. Ожидается объяснение и предусмотренный альтернативный путь без падения.
Диагностика и качество баг-репорта
Записывайте модель, ОС и её сборку, версию приложения, способ установки, состояние сети, разрешения и предыдущие действия. «Не отправляется на Android» недостаточно: ошибка может зависеть от обновления, фонового перехода и конкретных данных.
Приложите время события, видео, доступные системные логи и идентификатор тестовой операции. Сравните UI, локальное состояние и ответ сервера. Удалите из материалов токены, персональные фотографии и другую чувствительную информацию.
Типичные ошибки и выводы
Ошибки — постоянно тестировать после переустановки, считать сворачивание эквивалентом завершения процесса и доверять только эмулятору. Ещё одна — проверять сеть отдельным пунктом, не связывая её с реальной бизнес-операцией.
Сильный mobile QA проверяет переходы: онлайн → офлайн, активное → фон, старая версия → новая, разрешено → запрещено. Именно на границах чаще всего расходятся экран, локальные данные и серверный результат.