Как тестировать пуши и диплинки в финансовом приложении

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

Куда должен вести пуш

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

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

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

Как проверить переход при разном состоянии приложения

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

• Приложение закрыто. При холодном старте оно запускается и загружается, после чего должно продолжить переход к экрану из уведомления. Во время проверки проследите, куда пользователь попадает по завершении запуска.
• Приложение работает в фоне. Здесь проверяют возвращение из свёрнутого приложения и открытие целевого экрана. При действующей сессии пользователь должен продолжить работу в приложении; дополнительную перезагрузку при открытии пуша стоит разобрать с командой.
• Телефон заблокирован. Откройте уведомление с экрана блокировки и разблокируйте устройство с помощью Face ID или PIN-кода. После этого маршрут к нужному экрану должен сохраниться.
• Пользователь уже работает в приложении. Полученное уведомление открывают во время активной работы. Проверьте, как переход вписывается в текущую навигацию и вызывает ли он перезагрузку приложения.

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

Что происходит после повторного входа

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

Вернёмся к примеру с акцией. Человек получает уведомление о резком росте её цены, открывает его спустя час и проходит повторный вход. Если в этот момент приложение возвращает его на главную, поиск нужной акции приходится начинать заново.

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

Повторный запрос PIN-кода или возврат на главную нужно разбирать с учётом требований безопасности конкретного продукта. Если такое поведение предусмотрено, команда должна понимать, как оно влияет на переход по уведомлению. QA фиксирует результат проверки и обсуждает его с менеджером продукта.

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

Что показать, если нужный экран недоступен

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

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

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

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

Как проверить одну ссылку в разных каналах

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

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

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

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

Как организовать работу с диплинками

Когда ссылки используют разные команды, их удобно собрать в общем реестре. Он помогает найти нужный диплинк и увидеть, для чего тот создан, кто за него отвечает и когда его проверяли. Для ведения реестра подойдёт таблица в Excel или встроенный инструмент сервиса, в котором создаются ссылки.

В запись о каждом диплинке можно включить следующие поля:

• название или ID диплинка;
• цель перехода;
• тип диплинка;
• параметры;
• статус;
• ответственный;
• дата создания;
• дата последней проверки;

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

Подготовленные требования к переходам и реестр ссылок помогут сформулировать задачу для внешней команды QA. Centicore Group проводит функциональное тестирование приложений на соответствие требованиям и разрабатывает тестовые сценарии под задачи проекта.

Итого

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