Как тестовая инфраструктура помогает финтеху запускать банковские продукты быстрее
В условиях, когда технологические сбои могут привести к миллионным убыткам и регуляторным последствиям, подход, при котором QA подключается преимущественно перед релизом, уже не отвечает требованиям современной разработки. Контроль качества должен быть встроен во весь цикл создания продукта, от проектирования до эксплуатации. Отраслевая статистика показывает, что исправление дефекта, обнаруженного на этапе эксплуатации, обходится компаниям в 30 раз дороже, чем на этапе проектирования. По этой причине автоматизация тестирования и создание сквозных проверок стали критически важными элементами ИТ-инфраструктуры, определяющими способность бизнеса конкурировать за долю рынка.
Внедрение подобных инженерных практик требует глубокой экспертизы на стыке системной архитектуры и банковских технологий. Разработку и масштабирование платформы автоматизации, способной справляться с такими вызовами в масштабах распределенных систем, возглавил Дмитрий Шахов. При участии Дмитрия была спроектирована и внедрена единая платформа тестирования, которая встроила контроль качества в процессы разработки и сделала его одним из факторов скорости выпуска и стабильности продуктов. Опыт Дмитрия примечателен тем, что он работал не только с отдельными процессами, но и с тестовой инфраструктурой в целом. Созданные при его участии решения помогают сокращать время вывода продуктов на рынок, снижать нагрузку на команды и выявлять риски до выхода изменений в продуктивную среду.
Уникальность подхода Дмитрия Шахова заключается в отказе от парадигмы «тестирования по запросу» в пользу концепции Quality Gates, полностью интегрированных в конвейер доставки кода (CI/CD). В то время как стандартная рыночная практика предполагает выборочную ручную проверку критических обновлений перед релизом, созданная Дмитрием система автоматически блокирует любые изменения, не прошедшие верификацию на соответствие заложенным метрикам. Этот подход полезен для индустрии тем, что переносит фокус с поиска ошибок на превентивное обеспечение надежности архитектуры.
Дмитрий, сегодня много говорят о трансформации роли контроля качества в технологических компаниях. Почему в современном финтехе QA перестал быть просто этапом проверки кода перед запуском и превратился в полноценную часть продуктовой и ИТ-инфраструктуры?
В современных финансовых технологиях скорость изменений стала определяющим фактором выживания бизнеса. Когда банковский сервис состоит из сотен связанных компонентов, ручная проверка обновлений превращается в уязвимое место, которое останавливает развитие всего продукта. Мы больше не можем позволить себе тестировать систему линейно, так как это увеличивает время выхода продукта на рынок на недели или даже месяцы. Поэтому контроль качества смещается на самые ранние этапы проектирования и становится неотъемлемой частью общей архитектуры.
Финтех-продукты работают с реальными деньгами пользователей, транзакциями и строгими требованиями регуляторов, что накладывает жесткие ограничения на стабильность систем. Любая ошибка в логике начисления процентов или списания комиссий приводит не только к потере лояльности, но и к прямым финансовым санкциям. Инфраструктура обеспечения качества должна функционировать непрерывно, проверяя код при каждом его изменении инженерами. Это позволяет изолировать дефекты до того, как они затронут бизнес-логику связанных сервисов.
По сути, качественная тестовая платформа сегодня представляет собой фундамент, который позволяет продуктовым командам смело экспериментировать и внедрять новые функции. Если разработчик знает, что система безопасности и автоматические проверки подстрахуют его на этапе сборки, он действует быстрее. Без такой автоматизированной опоры ИТ-директора вынуждены искусственно замедлять темпы разработки, чтобы минимизировать риски стабильности ядра.
В итоге мы пришли к выводу, что тестовая инфраструктура является такой же производственной мощностью, как и серверы базы данных. Она требует постоянного мониторинга, оптимизации производительности и масштабирования под объемы команд разработки. Это стратегический инструмент, который напрямую определяет, сможет ли компания занять лидерские позиции в цифровом банкинге или останется позади из-за технологического долга.
Как именно автоматизация и концепция Quality Gates влияют на скорость релизных циклов и какие конкретные механизмы позволяют сохранять баланс между скоростью обновлений и безопасностью финтех-платформ?
Концепция Quality Gates, подразумевает автоматический аудит кода на каждом ключевом этапе его движения к продуктовой среде. Вместо того чтобы собирать все обновления в один большой и рискованный релиз раз в месяц, мы делим поток на мелкие составляющие. Каждый фрагмент кода проходит через сито автоматических проверок: от статического анализа структуры до динамического тестирования взаимодействия систем. Если хотя бы один критерий не выполнен, автоматика останавливает продвижение задачи.
Этот подход коренным образом меняет скорость работы команд. Ошибка обнаруживается в течение нескольких минут после написания кода, когда разработчик еще глубоко погружен в контекст задачи, и ее исправление занимает минимум времени. В традиционной схеме между написанием кода и получением отчета от QA-инженера могли пройти дни, что требовало повторного переключения контекста и затягивало процесс.
Безопасность при высокой скорости достигается за счет полной стандартизации требований к качеству. Мы убираем человеческий фактор из процесса принятия решений о готовности кода к запуску. Параметры прохождения проверок едины для всех команд, будь то базовые сервисы уведомлений или критически важные модули процессинга платежей. Это позволяет сохранять предсказуемость поведения системы при любых объемах изменений.
Внедрение таких автоматических барьеров устраняет необходимость проведения длительных координационных совещаний перед каждым обновлением. Процесс становится прозрачным для бизнеса: если код преодолел все встроенные технологические ворота, он готов к эксплуатации. Это единственная рабочая модель, позволяющая крупным финансовым платформам выпускать обновления непрерывно, не опасаясь за стабильность текущих сервисов.
Одним из первых крупных проектов с вашим участием в Ozon Fintech стал запуск кредитной карты, который занял полтора года. С какими инфраструктурными вызовами вы столкнулись при создании тестовой среды для этого продукта и как их решали?
Создание кредитной карты с нуля в рамках существующей экосистемы является комплексной задачей, требующей интеграции множества разрозненных систем: от скоринга рисков до платежных шлюзов. Сроки в полтора года для продукта такого масштаба на финансовом рынке считаются жесткими. Основная сложность заключалась в том, что тестовая инфраструктура должна была строиться параллельно с разработкой самой карты, причем требования к логике продукта постоянно менялись и дополнялись.
К моменту запуска кредитной карты у нас уже была базовая среда с моками и эмуляторами внешних партнёров, государственных и платёжных систем. Наша задача заключалась не в том, чтобы создавать её с нуля, а в том, чтобы адаптировать существующие решения под специфику кредитных продуктов и разработать недостающие компоненты. Благодаря этому команда могла автономно тестировать интеграционные сценарии и вести разработку, не дожидаясь полной готовности внешних сервисов.
Другим вызовом стала необходимость проверки сквозных пользовательских сценариев, включающих выпуск карты, авторизацию лимита, совершение покупок и начисление кэшбэка. Каждый из этих шагов обрабатывается отдельными ИТ-системами, и сбой в любой точке рушил всю цепочку. Для проверки сквозных сценариев мы встроили в Quality Gates автоматические проверки. Они контролировали прохождение операций через связанные системы и сопоставляли результаты на каждом этапе, что позволяло выявлять расхождения в логике транзакций до релиза.
Благодаря созданной архитектуре тестирования, к моменту официального запуска продукта мы имели полностью проверенную и стабильную систему. Полтора года ушли не просто на написание программного обеспечения, а на создание масштабируемого конвейера, который позволил выпустить карту на рынок без критических сбоев в операционной деятельности и обеспечил бесшовный опыт для первых пользователей.
Следующим важным этапом стал запуск направления B2B-кредитования, реализованный всего за 9 месяцев. За счет каких архитектурных изменений в тестовой платформе удалось сократить время вывода продукта на рынок практически в два раза по сравнению с кредитной картой?
Когда перед нами встала задача запустить B2B-кредитование за девять месяцев, нам уже не требовалось создавать тестовую инфраструктуру с нуля. Мы могли переиспользовать накопленный технологический стек и сосредоточить ресурсы на специфике нового продукта. Отличие сегмента B2B заключается в повышенной сложности юридических и финансовых проверок контрагентов, интеграции с реестрами юридических лиц и кастомных механизмах расчета лимитов для бизнеса. Время играло против нас, и залогом успеха стало повторное использование архитектурных наработок.
Мы применили модульный подход к организации тестовых сред, который был разработан во время работы над кредитной картой. Базовые компоненты, такие как модули идентификации, генерации печатных форм документов и отправки уведомлений, уже имели готовые автоматизированные сценарии проверки. Нам оставалось сфокусировать инженерные ресурсы исключительно на специфической логике кредитования юридических лиц.
Кроме того, мы существенно модернизировали механизмы генерации тестовых данных. Для B2B-сегмента крайне важно проверять гипотезы на компаниях с различной формой собственности, налоговыми режимами и финансовой историей. Автоматизация процесса создания таких синтетических профилей позволила исключить ручную подготовку тестовых сценариев, которая раньше занимала до 30% всего времени разработки.
В итоге сокращение сроков запуска до 9 месяцев стало прямым следствием зрелости нашей тестовой инфраструктуры. Мы доказали, что инвестиции в создание единой платформы автоматизации окупаются при запуске последующих бизнес-линий. Компания получила возможность оперативно заходить в новые ниши, используя проверенные инженерные рельсы без необходимости расширения штата тестировщиков под каждую новую задачу.
На данный момент кредитный портфель компании превышает несколько десятков миллиардов рублей, а число выпущенных кредитных карт измеряется сотнями тысяч. Каким образом масштаб бизнеса и такие объемы операций влияют на требования к надежности и производительности систем автоматизации?
Когда масштаб кредитного портфеля достигает нескольких миллиардов рублей, а число активных карт измеряется сотнями тысяч, цена любой технической ошибки возрастает экспоненциально. В таких объемах сбой, длящийся даже несколько минут, оборачивается серьезными финансовыми и репутационными потерями. Для тестовой инфраструктуры это означает, что мы обязаны проверять системы не только на корректность выполнения функций, но и на устойчивость к экстремальным нагрузкам.
При такой клиентской базе возрастает вариативность использования продукта. Пользователи могут одновременно совершать покупки в разных часовых поясах, гасить задолженности через различные каналы и обращаться в поддержку. Наша система автоматизации должна воспроизводить эти комплексные профили нагрузки, имитируя одновременные действия десятков тысяч клиентов, чтобы гарантировать, что балансы и лимиты рассчитываются корректно в любой секундный интервал.
Большие объемы данных накладывают ограничения и на скорость работы самих тестов. Чтобы функциональные и нагрузочные проверки давали реалистичные результаты, тестовые базы должны быть сопоставимы с продуктивной средой по объему и структуре данных. При этом большие массивы данных могут существенно замедлять автоматические тесты. Поэтому мы оптимизировали хранение и подготовку тестовых данных, сохранив реалистичность сценариев и сократив время получения обратной связи для разработчиков.
Управление рисками при таком масштабе бизнеса требует от нас перехода к проактивному анализу. Мы анализируем метрики производительности на тестовых стендах и сопоставляем их с поведением реальной системы. Это позволяет выявлять деградацию производительности архитектуры на ранних стадиях, задолго до того, как она сможет повлиять на операции наших клиентов и обслуживание кредитного портфеля.
Финтех-платформа компании включает в себя более 1000 микросервисов, для проверки которых ежедневно выполняется более 25 тысяч E2E-тестов и суммарно более 300 тысяч прогонов. Как технически организована работа такой масштабной инфраструктуры тестирования и как вы справляетесь с проблемой нестабильных тестов?
Управление качеством в архитектуре, насчитывающей более 1000 микросервисов, требует распределенной вычислительной инфраструктуры. Выполнять более 300 000 тестовых прогонов ежедневно на стандартных мощностях невозможно, привело бы к огромным очередям и парализовало бы разработку. Мы построили динамически масштабируемый кластер в облаке, который автоматически выделяет вычислительные ресурсы под запуск тестов в момент сборки кода и сворачивает их после завершения проверок.
Вызов, стоящий перед нами, при запуске 25 000 сквозных (E2E) тестов — это их стабильность, так как они затрагивают цепочки из десятков микросервисов. В таких условиях возникает проблема Flaky Tests (нестабильных тестов), когда проверка падает не из-за реальной ошибки в коде, а из-за сетевой задержки или кратковременной недоступности компонента. Если с этим не бороться, инженеры перестают доверять результатам автоматизации.
Для решения этой проблемы были внедрены интеллектуальные алгоритмы анализа результатов тестирования. Система умеет автоматически перезапускать упавшие тесты, анализировать логи смежных систем и изолировать инфраструктурные сбои от реальных дефектов программного обеспечения. Если тест демонстрирует нестабильное поведение, он автоматически исключается из блокирующих Quality Gates и направляется на доработку автору.
Кроме того, мы активно используем инструменты наблюдаемости (сквозного мониторинга) внутри тестовых контуров. Каждый шаг автоматического теста размечается специальными идентификаторами трассировки. Это позволяет при падении проверки мгновенно увидеть, какой именно из 1000 микросервисов дал сбой, сокращая время локализации проблемы с нескольких часов до нескольких секунд.
Сегодня 70% из более чем 1500 еженедельных релизов компании проходят полностью без ручного участия QA. За счет чего удалось достичь такого высокого уровня доверия к автоматизации и как это меняет требования к квалификации самих инженеров по качеству?
Достижение показателя в 70% автономных релизов из общего объема в 1500 обновлений в неделю — это результат долгой работы по выстраиванию доверия к инженерным метрикам. Бизнес и ИТ-дирекция должны быть абсолютно уверены, что если автоматическая система одобрила релиз, он не нарушит работу банка. Это доверие формировалось постепенно, по мере того как наши автотесты доказывали свою стопроцентную точность на менее критичных сервисах.
Чтобы прийти к этой цифре, формализовали критерии безлюдного деплоя. Сервис может обновляться автоматически только в том случае, если он покрыт необходимым объемом контрактных и сквозных тестов, а его метрики стабильности в тестовой среде не вызывают вопросов. Если система фиксирует аномалию, автоматический процесс прерывается, и к анализу подключается человек. Это позволяет нам безопасно масштабировать частоту релизов.
Такой сдвиг кардинально меняет требования к профессии QA-инженера. Классическое ручное тестирование кликаньем по экрану в финтехе такого уровня уходит в прошлое. Сегодня инженеры по качеству — это, по сути, системные разработчики, которые пишут сложный код для тестирования другого кода. Они должны разбираться в архитектуре микросервисов, базах данных, инструментах контейнеризации и очередях сообщений.
Мы смещаем фокус работы специалистов с ручной проверки задач на проектирование надежных тестовых сценариев и развитие самой платформы автоматизации. Это делает работу инженеров более интеллектуальной и высокооплачиваемой, избавляя их от рутины. В конечном счете, автоматизация 70% релизов позволяет компании расти кратно быстрее рынка, не раздувая ИТ-штат до неуправляемых размеров.
Интеграция передовых практик автоматизации тестирования, реализованная под руководством Дмитрия Шахова, демонстрирует, как инженерные решения трансформируют операционную деятельность финансового сектора. Созданная им распределенная инфраструктура контроля качества обеспечила компании технологическую независимость и гибкость, позволив сократить сроки запуска сложных банковских продуктов в разы. Вклад Дмитрия в отрасль заключается в формировании нового стандарта построения отказоустойчивых микросервисных систем для масштабных финтех-платформ, где автоматизация процессов выступает главным гарантом стабильности бизнеса и высокой скорости доставки ценности до конечного потребителя.
Опубликовано 15.08.2026
