Інтерв"ю з Костянтином Шкляром: чому автоматизація якості стала критичною для великих фінансових платформ

Про цю сторону індустрії ми поговорили з Костянтином Шкляром, 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-проєктів. Це середовище зі складною конфігурацією, великою кількістю інтеграцій і високими вимогами до безпеки. Моє завдання- будувати автоматизацію, яка розвивається разом із продуктом і не створює додаткових обмежень у довгостроковій перспективі.