Предположу, что многие коллеги ловили себя на мысли о том, что тестирование пуш-уведомлений — одна из самых простых задач: отправил, получил, кликнул. Если текст отображается корректно, и ссылка открывается, задачу можно считать выполненной.

А если это пуши в финтехе? Там цена ошибки измеряется не только временем, но и реальными деньгами. Для нас, как для команды обеспечения качества, пуш-уведомления — это обещание пользователю. 

У нас нет цели нагрузить человека лишним текстом — с помощью пушей дается обещание того, что клик приведет пользователя к решению задачи быстро, безопасно и без потери контекста. Сломанный диплинк в уведомлении о волатильности актива может привести к тому, что трейдер не успеет закрыть позицию и потеряет часть депозита. Если навигация ломается, пользовательский сценарий прерывается, и клиент остается один на один с проблемой.

В Centicore Group мы подходим к проверке диплинков и пушей именно как к части пользовательского опыта, а не просто как к сухой технической задаче. 

В статье я хочу разобрать, где скрыты основные риски, и как выстраивать мышление качества в этом направлении.

А еще мы с командой решили провести небольшой конкурс. Мы подготовили для QA-инженеров квиз с вопросами - отличная возможность проверить свои знания и просто интересно провести время за чашкой кофе (или в перерыве между прогоном регрессии). Взамен - приятный бонус в виде подарков для тех, кто успешно пройдет тест. 

Об условиях конкурса и подарках можно узнать по ссылке - Квиз QA

А теперь к контексту

Диплинк, как контракт между бизнесом и пользователем

Диплинк в инвестиционном приложении можно сравнить с навигатором. Он сразу ведет пользователя по нужному, удобному и быстрому маршруту. То есть, если человек видит уведомление о статусе перевода денежных средств – при клике он должен попасть на экран подтверждения перевода, а не на главную страницу с ненужной информацией. 

Логика простая - клиент, видя определенное уведомление, рассчитывает на то, что тап откроет экран для принятия решения. Так и должно быть.

Проблема может возникнуть, если рассматривать диплинк только как технический URL. Поэтому тут надо понимать, что мы имеем дело со сложным объектом, который содержит в себе целевой адрес, источник перехода, ID пользователя, параметры сессии. Соответственно нужно проверить не только то, что ссылка работает, но и то, чтобы она соответствовала тому, чего ждет пользователь.

Важно проверять пограничные состояния. Например, ситуация — актив уже делистингован, а чат поддержки «временно недоступен». Что должен увидеть клиент? Техническую ошибку заменяем на мягкую заглушку. Вместо грустного котика около надписи «Error 404» — понятное сообщение «Актив больше не торгуется» или «Раздел временно недоступен» с предложением вернуться позднее. 

Задача качественного тестирования навигации - минимизировать риски тупиковых сценариев. Если целевой экран недоступен, система должна аккуратно перенаправить клиента, объяснив причину и сохранив рабочий контекст. Это прямое уважение к времени пользователя.

Как поведение устройства влияет на переход по пушу

Одна из самых сложных задач при тестировании пушей - учет состояния приложения в момент клика. Каждый пользователь взаимодействует с устройством по-разному, следовательно навигация должна адаптироваться. 

Выделяется несколько ключевых сценариев:

1. Холодный старт. Приложение полностью закрыто – тогда система должна запуститься, загрузить программу и сразу открыть нужный экран.

2. Фоновый режим. Приложение свернуто – тогда переход должен происходить мгновенно, без перезагрузки. Здесь важно проверить срок действия сессии: если она активна, то не нужно требовать от пользователя повторного ввода пин-кода.

3. Заблокированный экран. Пользователь видит уведомление на заблокированном устройстве – тут необходимо проверить, сохранится ли маршрут перехода после разблокировки (FaceID или ввод пин-кода).

4. Активная сессия. Пользователь уже работает в приложении – в таком случае пуш не должен перезагружать систему, а должен органично вписаться в текущий поток.

Логику каждого состояния необходимо выверять. Например, если после разблокировки телефона система сбрасывает пользователя на главный экран вместо целевой сделки, это выглядит как баг. Однако с точки зрения безопасности такое поведение может быть оправдано.

Задача тестировщика – в любом случае обратить на это внимание, и зафиксировать этот момент. Дальше уже идет обсуждение с менеджером продукта о том, чтобы команда приняла взвешенное решение, что важнее – защита данных или комфорт и удобство клиента.

Почему ссылки из разных мест должны работать одинаково

Диплинки применяются не только в пушах. Их размещают в рекламных объявлениях и баннерах, в email- и смс-рассылках, в QR-кодах, в социальных сетях и мессенджерах. И тут тоже нужно быть начеку. 

Представьте, если один и тот же диплинк, который корректно ведет пользователя из уведомления к нужному контенту, поведет этого же пользователя на другой экран из рекламного баннера. Это не вызовет понимания, мол у «всех бывают ошибки», тут скорее появится недоверие к продукту и желание закрыть приложение.

Поэтому нужно выстраивать единую точку входа для всех кликов. Для этого необходимо, чтобы команда тоже работала как слаженный и бесперебойный механизм. 

• Реклама у отдела маркетинга? Нужно пройти валидацию ссылок у продуктовых инженеров. 

• Обновление логики пушей? Надо согласовать с аналитиками. 

Отсюда возникает потребность в едином реестре диплинков. Жестких технических норм для этого нет, но для компаний это становится хорошей практикой. С таким реестром не нужно искать определенную ссылку у разных менеджеров - вся команда сразу видит тип диплинка, его цель, ответственного и активность. Также легко отследить, какие ссылки уже не работают, и вовремя их заменить.

Необязательно проектировать сложную систему, можно просто завести Эксель таблицу или использовать встроенные инструменты в том сервисе, где вы создаете диплинки. Так как правил для реестра нет, я бы советовал указать такие данные:

• Название или ID диплинка

• Поставленная цель

• Тип диплинка

• Параметры 

• Статус

• Ответственный

• Дата создания

• Дата последней проверки

Ну и стоит напомнить, что навигация ломается не обязательно при клике. Проблема может возникнуть по причине плохого интернета или включенного на девайсе защищенного интернет-соединения. Поэтому в тестировании и должны заранее предусматриваться все потенциальные риски. Не стоит думать, что, если все работало раньше, значит сработает и сейчас. В таком случае даже идеальная ссылка может остаться недоставленной.

Безопасность против удобства: вечный конфликт финтеха

В инвестиционных приложениях частенько сталкиваются две вещи: безопасность денежных сбережений и удобство для клиента. 

То есть логично — если пользователь продолжительное время (например, 2 часа) не заходит в программу, его сессия автоматически закрывается - это базовая защита от мошенников. Но из-за этого возникает неудобство. 

Допустим, человек получил пуш-уведомление о резком росте цены на акцию, открыл его спустя час,  ввел заново пароль, а его выкинуло на главный экран. И тут приходится опять искать нужную вкладку с той самой акцией. Это плохой сценарий, который не стоит допускать.

В случае хорошего исхода картина выглядит так — система запоминает, куда именно хотел попасть клиент, и после ввода пароля она сразу открывает тот самый экран, на который вело уведомление.

Да, второй вариант технически сложнее, потому что нужно, чтобы и приложение, и сервер правильно передавали друг другу информацию о намерении пользователя. Для тестировщика здесь двойная задача: проверить, что логика работает, и убедиться, что в этом механизме нет уязвимостей. Например, можно пытаться перехватить или изменить параметры перехода с помощью отладочных прокси, а также проверить, что после выхода из аккаунта или удаления приложения никаких следов этого маршрута не остается.

Что в итоге

Моя мысль такова - говоря о тестировании пушей и навигации, мы на самом деле говорим о доверии. Пользователь не видит, сколько усилий мы вложили в проверку различных сценариев, он видит только результат. Поэтому если переход происходит мгновенно и точно, это воспринимается как данность и норма, а если случается ошибка или задержка - это вызывает раздражение.

В финансовых приложениях это напрямую сказывается на бизнесе. И стабильная работа диплинков увеличивает удержание клиентов и частоту их операций.