«Пуш – это обещание»: продуктовый подход к тестированию навигации в финтехе

Wait 5 sec.

Часто кажется, что тестирование пуш-уведомлений – одна из самых простых задач: отправил, получил, кликнул. Если текст отображается корректно, и ссылка открывается, задача считается выполненной.Однако в финтехе цена ошибки измеряется не только временем, но и реальными деньгами. Для нас, как для команды обеспечения качества, пуш-уведомления – это не просто текст на экране, это обещание пользователю. Обещание того, что клик приведет его к решению задачи быстро, безопасно и без потери контекста. Сломанный диплинк в уведомлении о волатильности актива может привести к тому, что трейдер не успеет закрыть позицию и потеряет часть депозита. Если навигация ломается, пользовательский сценарий прерывается, и клиент остается один на один с проблемой.В Centicore Group мы подходим к проверке диплинков и пушей не как к сухой технической задаче, а как к части пользовательского опыта. Разберем, где скрыты основные риски и как выстраивать мышление качества в этом направлении. А еще мы с командой решили провести небольшой конкурс. Мы подготовили для QA-инженеров виз с вопросами - отличная возможность проверить свои знания и просто интересно провести время за чашкой кофе (или в перерыве между прогоном регрессии). Взамен - приятный бонус в виде подарков для тех, кто успешно пройдет тест. Об условиях конкурса и подарках можно узнать по ссылке - http://centiquiz.centicore.ru/А теперь к контекстуДиплинк, как контракт между бизнесом и пользователемДиплинк в инвестиционном приложении выполняет роль навигационного контракта. Когда клиент видит уведомление о смене цены или статусе заявки, дизайн системы предполагает, что тап по нему сразу откроет экран для принятия решения.Проблема возникает, когда мы рассматриваем диплинк исключительно как технический URL. На деле это сложный объект с метаданными: идентификаторами инструментов, параметрами сессии, источниками триггеров. Фокус тестирования меняется: мы проверяем не только работоспособность ссылки, но и ее соответствие текущему контексту.Важнее проверить пограничные состояния, например, что увидит клиент, если актив уже делистингован, а чат поддержки временно недоступен? В нашей практике мы заменяем технические ошибки на понятные заглушки: вместо белого экрана или кода 404 пользователь видит сообщение «Актив больше не торгуется» или «Раздел временно недоступен» с предложением вернуться в портфель или написать позднее.Задача качественного тестирования навигации – минимизировать риски «тупиковых» сценариев. Если целевой экран недоступен, система должна мягко перенаправить пользователя, объяснив причину и сохранив рабочий контекст. Это прямое уважение к его времени.Матрица состояний: уважение к контекстуОдна из самых сложных задач при тестировании пушей – учет состояния приложения в момент клика. Пользователь взаимодействует с устройством по-разному, и навигация должна адаптироваться. Мы выделяем несколько ключевых сценариев: Читать далее