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

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

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

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

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

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

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

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

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

Важнее проверить пограничные состояния, например, что увидит клиент, если актив уже делистингован, а чат поддержки временно недоступен? В нашей практике мы заменяем технические ошибки на понятные заглушки: вместо белого экрана или кода 404 пользователь видит сообщение «Актив больше не торгуется» или «Раздел временно недоступен» с предложением вернуться в портфель или написать позднее.

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

Матрица состояний: уважение к контексту

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

Когда я говорю, что перешёл с React на Angular, на меня смотрят примерно так же, как если бы я сказал, что добровольно переехал из Амстердама куда-нибудь в Челябинск. С непониманием и вопросом «а зачем».

Если открыть типичный канал про разработку, там будет React, Next.js, React Native, снова React. Джуны учат его как первый фреймворк, мидлы обычно выносят в резюме жирным шрифтом. Angular воспринимается как что-то невероятно сложное, для мега-приложений масштаба «строим город на Луне» и бэкендеров, которым не повезло. Я тоже так думал. У меня за плечами был React, я понимал компонентный подход, умел работать с хуками, знал экосистему. И тут Angular.

Готовых инструкций, как перейти с React на Angular, в сети практически нет. Зато есть тысячи статей про обратный путь. Пришлось разбираться самому, и вот что из этого вышло.

Может показаться, что достаточно хорошо работать, и вас оценят.

Это не так.

Команды, которые «просто кодят», но не могут объяснить внутреннему заказчику, что они сделали, часто расформировывают после проекта.

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

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

Раньше, когда я был молодым Product Owner«ом, я думал: „Ну зайди ты в трекер, там же всё видно!“ Оказалось, что для бизнеса это чёрный ящик. А умные люди очень не любят чёрные ящики, очень не любят красивые отчёты с суммаризациями и очень не любят ощущение, что им пытаются продать что‑то без понимания смысла. Если вы не рассказали о результате правильно, то для многих результата часто просто не существует.»

Давайте разберём задачу выступления и оптимальную стратегию.

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

По большей части на ручные тесты уезжают сверка логики процесса (end-to-end-сценарии) и тесты UI.

Я работаю в команде Centicore, но мы сидим на стороне клиента — крупного банка — и занимаемся разработкой в его закрытой среде. То есть мы наёмная команда на продукте заказчика.

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

То, что мы называем робособакой, — это, по сути, мобильная аппаратная платформа. У неё есть четыре ноги с приводами, аккумулятор, бортовой компьютер и полезная нагрузка.

Ещё есть роверы — колёсные платформы. Роверы проще, дешевле и надёжнее на ровном асфальте, но собака — это вездеход.

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

Зачем вообще собаки, если есть дроны? БПЛА — штука отличная, но у них есть конкретные недостатки для охраны периметра 24/7. Дрон висит в воздухе 30–40 минут, а потом летит на базу. Ну и, конечно, он жужжит и виден всем. Он не взлетает в метель, почти не умеет двигаться по помещениям и, самое главное, не умеет открывать двери. А собака с рукой на спине отлично умеет.

Робопёс работает в полях часами, может спрятаться в траве, пройти под трубопроводом и не боится ветра.

В отличие от дронов робособаки уже работают координированными флотами с обменом информацией друг с другом через p2p-сети и mesh. Они строят p2p-сети, собака с радиодоступом к центру может работать мостом к совсем далёкой собаке за горизонтом и так далее.

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

Представьте, что вы спрашиваете банковского ассистента про банкоматы в Москве, а он присылает карту Саратова. Или ещё интереснее: официальный бот внезапно начинает отвечать русскоязычным клиентам на латинице.

Это весёлые будни ИТ в банке, где каждый релиз похож на русскую рулетку. Потому что есть один нюанс — у нас нет предпродовой среды. Вообще.

И пока эта проблема не решена, мы живём в очень интересном, мягко говоря, режиме.

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

Мы выносили эту историю на общебанковские управляющие комитеты, стучались к руководству. Но руководство долгое время считало, что предпрод — это какая-то наша прихоть. Их логика проста: «А что? Всё же вроде нормально, ничего не падает... Ну вы же как-то справляетесь! На фига вам ещё какая-то среда?»

А правда — в том, что мы не особо справляемся. Точнее, мы вывозим, но исключительно на морально-волевых. Мы держим системы на плаву героическими усилиями команды, компенсируя отсутствие инфраструктуры своими нервами и овертаймами.

Расскажу, почему все так не любят линейных HR, и что делать, чтобы наём работал с головой. Я как раз эйчар, директор департамента. Мы нанимаем много ИТ-специалистов.

Год назад в ИТ набирали вообще всех подряд: люди были очень нужны. Сейчас ситуация переигралась: многие компании оптимизируют процессы, перестраивают штат по принципу «Лучше меньше, да лучше».

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

Самая частая проблема — рассинхронность приоритетов. Техлиду срочно нужен спец, который выведет компанию на международный рынок. HR цепляется за пару стандартных навыков и приводит толпу формально подходящих кандидатов. Все бракуются, куча времени и денег — в топку. Чтобы хоть как-то закрывать задачи, берут «самого нормального из ненормальных». Он, естественно, не решает проблем, и его увольняют. И всё начинается заново.

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

Например, в управлении транспортом статичные данные (например, сет за «типичный вторник») не дают протестировать систему в условиях праздника, крупной аварии, сессии у студентов, скидки 99% на Лабубу в крупном супермаркете и так далее. 

Что мы сделали:

• Стали брать реальные данные с прода, которые выбиваются за стандартные представления.

• Обезличивать их.

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

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

Цель — не просто нагрузить систему, а протестировать жизнеспособность архитектуры в похожих на реальные условиях. 

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

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

Я руководитель проектов, работаю с крупными корпоратами и банками первой пятёрки.

Самый ад — это когда проект на стыке двух таких банков. У меня есть живой пример )

На этом проекте:

На этом проекте:

— Юристы и безопасники из двух банков 4 месяца гоняли договор по кругу. Надо было как-то их договорить и всё-таки начать работать.

— Договор был рассчитан до 2026 года, а бюджет в системе был заложен только на 2025-й. Бухгалтерия возвращала ошибку Not defined и предлагала запланировать бюджет на 2026 год прямо сейчас.

— Уволился ключевой подписант.

— Это был ИТ-директор!

Так что у нас есть все виды бюрократии: комплаенс, Департамент кибербезопасности (ДКБ), риск-чемпионы и, конечно, юристы.

Как я уже говорила, это ад.

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

Что бывает, когда такое не выполняется, мы отлично знаем по взломам доставки еды, например, когда стандарт был, но его не применили.

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