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