<p>Часто кажется, что тестирование пуш-уведомлений – одна из самых простых задач: отправил, получил, кликнул. Если текст отображается корректно, и ссылка открывается, задача считается выполненной.</p><p>Однако в финтехе цена ошибки измеряется не только временем, но и реальными деньгами. Для нас, как для команды обеспечения качества, пуш-уведомления – это не просто текст на экране, это обещание пользователю. Обещание того, что клик приведет его к решению задачи быстро, безопасно и без потери контекста. Сломанный диплинк в уведомлении о волатильности актива может привести к тому, что трейдер не успеет закрыть позицию и потеряет часть депозита. Если навигация ломается, пользовательский сценарий прерывается, и клиент остается один на один с проблемой.</p><p>В Centicore Group мы подходим к проверке диплинков и пушей не как к сухой технической задаче, а как к части пользовательского опыта. Разберем, где скрыты основные риски и как выстраивать мышление качества в этом направлении. </p><p>А еще мы с командой решили провести небольшой конкурс. Мы подготовили для QA-инженеров виз с вопросами - отличная возможность проверить свои знания и просто интересно провести время за чашкой кофе (или в перерыве между прогоном регрессии). Взамен - приятный бонус в виде подарков для тех, кто успешно пройдет тест. </p><p>Об условиях конкурса и подарках можно узнать по ссылке - <a href="https://centiquiz.centicore.ru/?utm_source=habr&utm_medium=blog&utm_campaign=centi_quize&utm_content=qa_gift_13_26_08">Квиз для QA</a></p><p>А теперь к контексту</p><p><strong>Диплинк, как контракт между бизнесом и пользователем</strong></p><p>Диплинк в инвестиционном приложении выполняет роль навигационного контракта. Когда клиент видит уведомление о смене цены или статусе заявки, дизайн системы предполагает, что тап по нему сразу откроет экран для принятия решения.</p><p>Проблема возникает, когда мы рассматриваем диплинк исключительно как технический URL. На деле это сложный объект с метаданными: идентификаторами инструментов, параметрами сессии, источниками триггеров. Фокус тестирования меняется: мы проверяем не только работоспособность ссылки, но и ее соответствие текущему контексту.</p><p>Важнее проверить пограничные состояния, например, что увидит клиент, если актив уже делистингован, а чат поддержки временно недоступен? В нашей практике мы заменяем технические ошибки на понятные заглушки: вместо белого экрана или кода 404 пользователь видит сообщение «Актив больше не торгуется» или «Раздел временно недоступен» с предложением вернуться в портфель или написать позднее.</p><p>Задача качественного тестирования навигации – минимизировать риски «тупиковых» сценариев. Если целевой экран недоступен, система должна мягко перенаправить пользователя, объяснив причину и сохранив рабочий контекст. Это прямое уважение к его времени.</p><p><strong>Матрица состояний: уважение к контексту</strong></p><p>Одна из самых сложных задач при тестировании пушей – учет состояния приложения в момент клика. Пользователь взаимодействует с устройством по-разному, и навигация должна адаптироваться. Мы выделяем несколько ключевых сценариев:</p> <a href="https://habr.com/ru/articles/1069262/?utm_source=habrahabr&utm_medium=rss&utm_campaign=1069262#habracut">Читать далее</a>