Как тестировать in-app уведомления?
Что проверяют
Отличаете ли вы in-app уведомления от push и понимаете ли, что главное в них не текст, а правила показа: кому, когда, сколько раз и что будет после нажатия. Следом обычно спрашивают, как проверить кампанию с редким показом, не дожидаясь суток.
Как отвечать
Сначала разведите понятия. Push-уведомление приходит через APNs или FCM и видно, даже когда приложение закрыто. In-app показывается внутри запущенного приложения: баннер, модальное окно, подсказка, сообщение во входящих. Дальше каркас проверок:
- правила показа: триггер (событие, экран, запуск), сегмент аудитории, лимит частоты, срок кампании, приоритет при нескольких сообщениях сразу;
- содержимое: длинный текст, локализации, картинка, которая не загрузилась, тёмная тема, маленький экран и поворот;
- действия: кнопка ведёт по нужному deep link, крестик и системная кнопка «Назад» закрывают, закрытое сообщение не всплывает снова;
- жизненный цикл: уход в фон во время показа, входящий звонок, системный диалог разрешений поверх, выход из аккаунта;
- состояние и аналитика: прочитанное во входящих синхронизируется между устройствами, уходят события показа и клика, отключение в настройках работает.
Для стабильных тестов нужен контроль над сервером. В Firebase In-App Messaging кампании по умолчанию подтягиваются редко, примерно раз в сутки, поэтому устройство регистрируют как тестовое по Installation ID и получают сообщение сразу. Если сервис свой, ответ с кампанией подменяют через Charles или Proxyman либо включают флагом на стенде. Тогда автотест на Appium проверяет показ и переходы, а не ждёт удачи.
Где спотыкаются
Путают in-app с push и начинают рассказывать про разрешение на уведомления и сертификаты APNs.
Проверяют один показ и забывают про частоту и таргетинг. Самые неприятные баги здесь: сообщение выскакивает на каждом запуске или приходит не тому сегменту.
Не проверяют прерывания. Сообщение, открытое в момент ухода в фон, после возврата может потерять кнопку или перекрыть экран так, что его уже не закрыть.