Интервью с Константином Шкляром: почему автоматизация качества стала критической для крупных финансовых платформ

Об этой стороне индустрии мы поговорили с Константином Шкляром, Senior QA Automation Engineer, который более восьми лет работает с enterprise-решениями в финтехе и крупном ритейле (прим. — международная инженерная компания с офисами в десятках стран, которая специализируется на разработке и консалтинге для крупных корпоративных клиентов, в частности в финансовом секторе, e-commerce и high-tech).

Константин работал над системами автоматизации для инвестиционных компаний в Лондоне, в частности над торговыми платформами и бэк-офисными решениями. Специализируется на архитектуре автотестов для enterprise-систем, где технические ошибки имеют прямые финансовые последствия. Его подходы к интеграции UI и API-тестирования были адаптированы другими командами и применялись в рамках нескольких международных проектов.

- Константин, ваш опыт связан с финтехом и крупными корпоративными системами. Как вы пришли именно в эту нишу?

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

Постепенно я сосредоточился на автоматизации, глубоко изучая Java и C#. Меня интересовало не написание отдельных тестов, а построение системы контроля качества, которая развивается вместе с продуктом. Именно это привело меня к работе с "тяжелыми" enterprise-решениями, где качество — это основное условие существования бизнеса.

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

- Насколько образование повлияло на ваш профессиональный путь?

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

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

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

- Какие результаты вашей работы имели наиболее ощутимое влияние на продукты?

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

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

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

- Вы часто говорите об автоматизации как об элементе архитектуры продукта. Как это выглядит на практике?

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

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

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

- Какие профессиональные вызовы были для вас наиболее сложными?

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

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

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

- Какова ваша роль в проектах сегодня?

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

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

- Над чем вы хотели бы работать в будущем?

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

Отдельный фокус я планирую сохранять на экосистеме Salesforce, с которой уже имел практический опыт в рамках enterprise-проектов. Это среда со сложной конфигурацией, большим количеством интеграций и высокими требованиями к безопасности. Моя задача — строить автоматизацию, которая развивается вместе с продуктом и не создает дополнительных ограничений в долгосрочной перспективе.