Мобильное приложение работает в среде, которой управляет пользователь и операционная система. Камеру могут запретить, экран заблокировать, поверх формы открыть системный диалог, а уведомления отключить через настройки. Качество проявляется в том, насколько спокойно продукт переживает такие изменения.
Задача QA — проверить переходы между состояниями и сохранность пользовательской работы. Разрешение, прерывание и уведомление связаны, но для каждого нужны отдельные ожидания: право доступа, восстановление сценария и корректное взаимодействие с сообщением.
Разрешения — это изменяемое состояние
Не рассматривай разрешение как флажок, который один раз выдали при установке. Пользователь может отказать, позже согласиться, отозвать доступ в настройках или выдать ограниченный вариант. Доступные состояния зависят от ресурса, версии ОС и конфигурации приложения.
Для камеры, геолокации, фотографий и микрофона нужны разные проверки. Например, ограниченный выбор фотографий и приблизительное местоположение — полноценные пользовательские решения, а не случайные ошибки окружения.
Когда уместен запрос
Хороший момент запроса связан с действием: камера нужна при добавлении фотографии, геолокация — при поиске рядом. QA проверяет, что объяснение соответствует функции, отказ доступен, а запрос не появляется заново при каждом открытии экрана.
Android рекомендует запрашивать разрешения в контексте функции и сохранять работоспособность остального приложения после отказа. Конкретное поведение системного диалога зависит от ОС, поэтому текст кейса должен описывать ожидаемый смысл, а не единственную форму окна.
Матрица проверок доступа
Для каждой защищённой функции подготовь начальные состояния и ожидаемую реакцию. Состояние нужно подтверждать в системных настройках, а не по старому тексту внутри приложения.
- →Доступ ещё не запрашивали: функция корректно инициирует запрос.
- →Доступ разрешён: ресурс используется по назначению.
- →Доступ запрещён: есть понятное объяснение и доступная альтернатива.
- →Доступ отозван при свёрнутом приложении: после возврата состояние обновляется.
- →Доступ ограничен: приложение работает с реально доступными данными.
Особенно важен возврат из настроек. Экран не должен продолжать показывать камеру как доступную только потому, что это было верно до перехода.
Что считать прерыванием
Прерывания меняют активность приложения или отвлекают пользователя: входящий звонок, блокировка устройства, открытие шторки, переключение приложений, системный запрос доступа, выбор файла. Они различаются продолжительностью и последствиями для процесса.
Сворачивание, удаление карточки из списка недавних и принудительная остановка не эквивалентны. На Android и iOS правила отличаются; в тесте нужно записывать конкретное действие, а не расплывчатое «закрыть приложение».
Практический пример: фото к обращению
Представь форму обращения в поддержку с текстом и фотографией. Цель — доказать, что отказ или прерывание не уничтожает уже сделанную работу.
- 1.Введи текст обращения и нажми добавление фото при ещё не выданном доступе.
- 2.Откажи в разрешении. Ожидается сохранение текста, понятное сообщение и возможность отправить обращение без фото, если это разрешено требованиями.
- 3.Разреши доступ через настройки и вернись. Функция должна увидеть новое состояние без переустановки приложения.
- 4.Сделай снимок, затем заблокируй устройство до завершения прикрепления.
- 5.Разблокируй и вернись. Проверь целостность текста, статус вложения и отсутствие повторной отправки.
- 6.Отправь обращение и сравни результат с сервером: одно обращение, правильная фотография, сохранённый текст.
Отдельно повтори сценарий с отменой системного выбора файла. Отмена пользователем должна завершать выбор спокойно, без ложного сообщения об аварии.
Какие данные должны переживать возврат
Сформулируй ожидания по каждому виду состояния: введённый текст, выбранный товар, позиция списка, платёжная операция, незавершённая загрузка. Для чувствительных экранов повторная аутентификация может быть обязательна, но она должна согласовываться с сохранением безопасных пользовательских данных.
Если ОС уничтожила процесс, восстановление может отличаться от короткого сворачивания. Такие проверки полезно разделять: иначе ошибка восстановления процесса маскируется успешным возвратом из фона.
Уведомления: право и отображение
Разрешение на уведомления не гарантирует, что конкретное сообщение появится как баннер. Влияют системные настройки, каналы Android, режимы концентрации, состояние приложения и тип сообщения. Android 13 и новее предусматривают runtime-разрешение POST_NOTIFICATIONS для неосвобождённых уведомлений; детали зависят также от target SDK.
Проверь локальные и удалённые уведомления отдельно. Локальное создаёт приложение по заданному условию на устройстве; удалённое проходит через сервер и службу доставки. У этих цепочек разные причины сбоев.
Что проверить при взаимодействии
Нажатие на сообщение должно открывать правильный объект с учётом текущего пользователя. Если сессия истекла, после входа нужно безопасно продолжить маршрут. Если объект удалён, требуется предусмотренное пустое состояние.
Проверь закрытый экран, активное приложение, фон, несколько сообщений подряд и повторное нажатие. Конфиденциальное содержание на заблокированном экране оценивай по согласованным требованиям, учитывая системные настройки предпросмотра.
Типичные ошибки
Проверка только «разрешить всё» пропускает большое число реальных сценариев. Ещё одна ошибка — объявлять дефектом отсутствие баннера, не установив, было ли событие создано, принято службой доставки и разрешено настройками устройства.
Не нужно искусственно объединять все прерывания с каждой кнопкой. Выбирай места с риском потери данных, повторной операции и нарушения доступа. Это даёт управляемый объём проверок и ясные причины приоритета.
Что должен вынести QA
Проверяй приложение после изменения разрешений, во время прерывания и после возврата. Хороший результат — сохранённая работа, актуальное состояние доступа и безопасный маршрут из уведомления. В баг-репорте обязательно фиксируй состояние ОС, точное прерывание и момент, в который оно произошло.