Что учитывать при тестировании пуш-уведомлений относительно состояния экранов и использования устройства?
Что проверяют
Умеете ли вы мыслить матрицей состояний вместо проверки «пришло или не пришло». Доставка и вид уведомления зависят от состояния приложения, экрана, системных режимов и пользовательских настроек, и хороший ответ это перечисление осей, а не список кликов.
Как отвечать
Стройте матрицу по четырём осям.
Состояние приложения: открыто на переднем плане, свёрнуто, выгружено системой из памяти, закрыто пользователем, принудительно остановлено в настройках (после этого на Android пуши не приходят до ручного запуска), переустановлено со сменой токена.
Состояние экрана и системы: экран погашен, экран блокировки с настройкой скрытия содержимого, режимы не беспокоить и фокусирования, энергосбережение и глубокий сон устройства, авиарежим, слабая сеть и возврат связи.
Доставка и оформление: разрешение на уведомления, отключение отдельного канала пользователем, группировка, схлопывание по ключу, срок жизни сообщения, звук и вибрация, счётчик на иконке, длинный текст и вложение.
Реакция на тап: холодный старт против уже запущенного приложения, переход по глубокой ссылке на нужный экран, поведение при смене аккаунта и выходе.
Сверяйте два источника: отчёт отправителя и факт на устройстве.
Где спотыкаются
Проверяют на одном телефоне с открытым приложением. На переднем плане уведомление показывает сам клиент, и именно этот случай почти всегда рабочий, а ломается всё после выгрузки из памяти и в энергосберегающих режимах.
Считают доставку гарантированной. Транспорт негарантированный, сообщения схлопываются и протухают, поэтому критичное состояние приложение обязано подтягивать запросом при открытии, а не хранить только то, что пришло пушем.
Не проверяют тап с погашенного и заблокированного экрана. Приложение открывается на главной вместо нужного экрана, счётчик не сбрасывается, а содержимое чувствительного уведомления видно на блокировке постороннему.