Push-уведомление — результат работы нескольких систем, а не отдельный баннер. Событие возникает в продукте, backend выбирает получателя, служба доставки принимает сообщение, устройство обрабатывает его, а пользователь открывает нужный контекст. Ошибка возможна на каждом этапе.
Для QA полезно разделять отправку, доставку, отображение и открытие. Успешный ответ APNs или FCM подтверждает принятие запроса на соответствующем этапе, но не гарантирует, что пользователь уже увидел уведомление.
Из чего состоит цепочка
Нужны бизнес-событие, адресуемая установка приложения, корректная регистрация, серверные полномочия и разрешённое поведение устройства. В iOS доставкой удалённых уведомлений занимается APNs; Android-продукты часто используют FCM, если он подходит их окружению.
Локальное уведомление планирует приложение на устройстве, поэтому тест локального напоминания не заменяет проверку удалённой доставки. Background push также отличается от видимого alert: его задача может состоять в обновлении данных без баннера.
Регистрация устройства и аккаунт
Адрес доставки связан с установкой приложения и платформенной регистрацией, а не является вечным идентификатором пользователя. Он может изменяться, поэтому клиент и backend должны поддерживать актуальную связь с аккаунтом и окружением.
Apple предписывает получать актуальный APNs device token и передавать его серверу, не полагаясь на локально закэшированное значение. В FCM проверяй актуальную модель регистрации используемого SDK, обновление идентификаторов и обработку недействительных регистраций. Технические детали фиксируй для конкретной интеграции.
Разрешение не равно показу
Уведомления могут быть разрешены приложению, но скрыты настройками канала, режимом концентрации, настройками предпросмотра или выбранной политикой foreground. Для Android учитывай runtime-разрешение на соответствующих версиях ОС и настройки каналов.
Составь ожидаемое поведение для запрета, последующего включения и повторного отзыва. Отказ от уведомлений не должен ломать основные функции приложения, если уведомления не являются явно обязательной частью конкретного сценария.
Состояния приложения нужно называть точно
Проверь активное приложение, фон, отсутствие процесса, заблокированный экран и запуск нажатием на сообщение. Сворачивание, системное завершение процесса и принудительное закрытие пользователем не равнозначны.
Особенно осторожно формулируй ожидания для фоновых уведомлений: Apple прямо указывает, что их доставка не гарантируется и может ограничиваться системой. Нельзя переносить выводы из одного состояния Android на iOS или обещать выполнение фонового кода после любого способа закрытия.
Практический пример: изменение статуса заказа
Представь уведомление «Заказ готов». Нужно доказать правильность получателя, содержания и перехода, а не только появления текста.
- 1.Войди тестовым пользователем А, проверь регистрацию установки и создай заказ с известным идентификатором.
- 2.Переведи заказ в нужный статус разрешённым способом. Сохрани время события и идентификатор серверной отправки.
- 3.Проверь ответ службы доставки и фактическое появление уведомления в предусмотренном состоянии устройства.
- 4.Нажми сообщение. Ожидается открытие именно этого заказа, актуальный статус и отсутствие повторного изменения заказа от самого перехода.
- 5.Повтори с истёкшей сессией. После входа должен восстановиться безопасный маршрут с повторной проверкой доступа.
- 6.Выйди из А, войди пользователем Б и повтори событие для А. Новому пользователю не должны раскрыться детали чужого заказа.
Отдельно проверь второе устройство пользователя А: поддержка нескольких устройств должна соответствовать требованиям и не сводиться к перезаписи единственного адреса доставки.
Срок жизни и объединение сообщений
Отложенное уведомление может потерять смысл: приглашение истекло, заказ уже завершён, звонок пропущен. Продукт должен определить срок актуальности и поведение при восстановлении сети.
FCM поддерживает срок жизни и объединение определённых ожидающих сообщений, а порядок доставки не следует считать гарантированным. Поэтому состояние заказа нужно получать из авторитетного источника при открытии, а не безусловно принимать старый текст уведомления за текущую истину.
Содержимое и взаимодействие
Проверь длинный текст, локализацию, переносы, иконку, звук, badge и дополнительные действия, если они предусмотрены. Требования к конфиденциальным данным оценивай вместе с настройками заблокированного экрана.
Несколько сообщений об одном объекте не должны создавать противоречивые действия. Повторное нажатие, устаревший payload, удалённый объект и неизвестный тип события требуют управляемого результата. Deeplink из push проходит те же проверки авторизации, что и любая внешняя ссылка.
Как разбирать отсутствие уведомления
Иди по цепочке доказательств: было ли бизнес-событие, создана ли отправка, выбран ли правильный аккаунт и registration, принята ли отправка провайдером. Затем проверяй соединение устройства, разрешения, ограничения и обработку приложением.
Полезные данные — время с часовым поясом, идентификатор события, безопасно замаскированная регистрация, окружение, ответ провайдера и состояние устройства. Отсутствие баннера без этой информации не позволяет уверенно назначить причину клиенту или серверу.
Что включить в регрессию
Добавь повторную установку, обновление регистрации, выход, смену аккаунта, несколько устройств и восстановление сети после истечения срока сообщения. Проверь, что недействительные адреса доставки обрабатываются backend, а повторные попытки не превращаются в бесконечную рассылку.
Push не должен быть единственным способом узнать критически важное состояние. Если сообщение не пришло, пользователь после открытия приложения всё равно должен получить актуальные данные предусмотренным способом. Это свойство устойчивости всего продукта.
Что должен вынести QA
Проверяй push как цепочку от события до защищённого целевого экрана. Разделяй принятие, доставку, отображение и открытие; учитывай изменяемую регистрацию и ограничения ОС. Хороший отчёт показывает место разрыва и факты, а не только утверждение «уведомление не пришло».