Юлия Дрогунова: как держать мобильный банк 24/7 без откатов
По оценкам, банки и финтех-компании останутся крупнейшими заказчиками QA-решений вплоть до 2033 года. Так, в Великобритании, по данным исследования, на финансовые сервисы уже приходится около 31% всех расходов в стране на тестирование ПО. Причина — в высокой цене ошибок в отрасли: даже кратковременный сбой может привести к потере клиентов, серьезному удару по репутации и штрафам со стороны регуляторов.
В таких условиях особенно важны методики, которые позволяют выпускать обновления без откатов и обеспечивать стабильную работу приложений 24/7. О том, как устроено тестирование в мобильном банкинге, какие практики помогают обходиться без откатов и почему стабильность 24/7 — это ключевая инженерная задача, мы поговорили с Юлией Дрогуновой, ведущим QA-инженером в Raiffeisenbank.
Юлия, расскажите как сформировалась ваша экспертиза в QA? Что повлияло на формирование вашей экспертизы в тестировании?
Я получила профильное образование, окончила ОмГУ им. Достоевского по специальности «Компьютерные науки». Уже тогда меня привлекала логика, системность и стремление к тому, чтобы всё работало как надо. Это органично привело меня в сферу тестирования.
Первый опыт я получила в международной ИТ-компании Luxoft, где начала работать junior QA-инженером. После я перешла в компанию Lineate, где отвечала за тестирование сервиса крупного медицинского центра NYU Langone в США. Позже я работала ведущим инженером по тестированию в ВТБ и в МТС Банке. В МТС в моей команде было четыре тестировщика, двоих я обучила с нуля. С 2020 года я занимаю позицию Senior QA Engineer в крупнейшем международном банке. Занимаюсь комплексным обеспечением качества мобильного банка: ручным и автоматизированным тестированием, интеграцией автотестов в CI/CD, поддерживаю релизы. Помогаю приложению работать стабильно, удобно и без сбоев.
Как опыт вне банковской сферы помог вам понять важность бесперебойной работы цифровых сервисов?
Во время работы над проектом для NYU Langone Medical Center я впервые столкнулась с по-настоящему высокой ценой стабильной работы сервисов. Медицинские системы не могут позволить себе простои, потому что на кону здоровье и даже жизни пациентов. Сбой в системе может привести к задержке в передаче данных, а значит ошибкам в назначении лечения, невозможности оперативно получить доступ к рецептам и другой критически важной информации.
Этот опыт сильно изменил мой профессиональный взгляд: я стала иначе относиться к вопросам надежности приложений. Позже, придя в финтех, я поняла, что принципы очень похожи. Только вместо здоровья — деньги клиента.
Чем мобильный банкинг отличается от других цифровых продуктов с точки зрения требований к стабильности и безопасности?
В отличие от многих цифровых продуктов, мобильный банк должен быть доступен 24/7 без сбоев. В банке, котором я работаю, более 17 миллионов клиентов в 14 странах. Каждое обновление влияет на реальные финансовые операции — здесь нет права на ошибку, которую можно исправить когда-нибудь потом. Любой сбой может привести к потере средств, срыву транзакций, блокировке доступа к счетам. В таких условиях требования к стабильности, безопасности и качеству релизов значительно выше, чем в большинстве других отраслей.
Термин «даунтайм» часто звучит в контексте критических сбоев. Расскажите, пожалуйста, читателям, что считается даунтаймом в мобильном банке и почему даже секундный простой может обойтись банку слишком дорого?
«Даунтайм» — это любое время, когда пользователь не может совершить нужную операцию: перевести деньги, оплатить счёт, зайти в приложение. Даже если сбой длится всего несколько секунд, он может привести к серьезным последствиям — от финансовых потерь и срыва транзакций до штрафов со стороны юридических лиц и регулятора. Но самое главное — это удар по доверию клиента. Если человек не может воспользоваться банковским сервисом в критический момент, он вряд ли захочет вернуться. А вернуть доверие всегда сложнее, чем удержать его.
Какие ключевые показатели вы постоянно держите под контролем, чтобы обеспечить работу приложения 24/7, и как они влияют на финансовые показатели и репутацию банка?
В центре внимания — несколько метрик. Прежде всего, это MTTR (среднее время восстановления после сбоя) и MTBF (среднее время между сбоями). Они показывают, насколько быстро мы реагируем на инциденты и как долго система может работать без сбоев. Также важны частота релизов, процент откатов и уровень ошибок на стороне клиента. Эти показатели позволяют понять, насколько стабильны и качественны наши обновления.
Все эти метрики напрямую связаны с доверием пользователей, удержанием клиентов и, в конечном счёте, с финансовыми результатами банка. Чем быстрее мы замечаем и устраняем сбой — тем меньше рисков, потерь и негатива вокруг имиджа банка.
Как вы организовали процесс внедрения изменений: какие этапы проверки проходит код, прежде чем обновление становится доступным клиентам?
Каждое изменение проходит через автоматический процесс, который называется CI/CD (Continuous Integration/Continuous Delivery — непрерывная интеграция и доставка). Это значит, что как только разработчик вносит изменения в код, они автоматически проходят серию проверок. Сначала запускаются юнит-тесты — они проверяют базовую логику и работу отдельных функций. Затем идут автоматические тесты API (проверка, как система обменивается данными с другими сервисами) и UI-тесты, которые проверяют, как обновление отображается и работает на устройствах пользователей — как на iOS, так и на Android.
После этого мы применяем стратегию canary-релиза: обновление сначала получает небольшая часть пользователей. Это помогает отследить возможные ошибки до того, как обновление станет доступно всем. Дополнительно мы используем feature flags — специальные настройки, с помощью которых можно включать или отключать отдельные функции приложения без выпуска новой версии. Такой подход позволяет нам быстро находить и устранять ошибки, делать обновления безопасно и безболезненно для пользователей.
Последние четыре года вы занимаете позицию ведущего QA-инженера в международном банке. Какие внедрённые вами практики дали наибольший эффект и как это отразилось на ключевых бизнес‑показателях банка?
Одним из ключевых достижений стало внедрение подхода раннего тестирования, при котором контроль качества начинается ещё на этапе проектирования и написания требований. Это позволило снизить количество ошибок, обнаруживаемых на проде, на 30%, а также ускорило выпуск новых обновлений на 15–20% за счёт сокращения времени на исправление ошибок.
Так же я помогала внедрять автоматизацию регрессионного тестирования. Мы покрыли автотестами более 80% критических пользовательских сценариев, что дало уверенность в качестве релизов. Это напрямую отразилось на повышении удовлетворённости клиентов и их лояльности, особенно в мобильном банке.
Вы уже более 7 лет в тестировании. За это время сформировалась ли у вас собственная методика управления релизами? Если да, поделитесь её тремя главными принципами, которые помогают выпускать обновления без откатов.
Да, за это время у меня действительно сложилась своя система, которая помогает выпускать стабильные обновления и сводить количество откатов к минимуму. Она опирается на три ключевых принципа. Первый — превентивный подход. Мы применяем практику shift-left, когда тестирование начинается как можно раньше, еще на этапе проектирования задачи. Вместо того чтобы искать ошибки после сбоя, мы заранее оцениваем риски и закладываем проверку потенциально уязвимых мест прямо в структуру тестов.
Второй принцип — комплексная автоматизация. Мы автоматизируем не только пользовательские сценарии (UI-тесты), но и взаимодействие с другими сервисами (API-тесты), и всё это встраиваем в процесс CI/CD — систему непрерывной интеграции и доставки. Это позволяет нам запускать сотни проверок при каждом обновлении автоматически, не тратя время на ручное тестирование.
Третий принцип — безопасные релизы. Мы выкладываем обновления поэтапно, используя canary-релизы, то есть на ограниченную аудиторию. А благодаря feature-flags можем включать или выключать отдельные функции без выпуска новой версии. Это дает гибкость и снижает риски: если что-то идёт не так, мы быстро реагируем, не затрагивая работу приложения для всех пользователей.
Часто автоматизация тестирования воспринимается как затратная история. В каких случаях она действительно окупается?
Автоматизация действительно требует вложений. Но она начинает окупаться в тот момент, когда затраты на ручную проверку и риски от возможных ошибок в релизах становятся выше, чем стоимость создания и поддержки автотестов.
Это особенно заметно в продуктах с регулярными обновлениями, таких как банкинг. Если вы выкатываете новые версии каждую неделю или даже чаще, проверять всё вручную становится просто неэффективно. Автотесты позволяют проверять функциональность быстро, повторяемо и с минимальными затратами на каждую итерацию. Кроме того, автоматизация снижает человеческий фактор и помогает быстрее находить критичные баги заранее. В итоге это экономит не только ресурсы команды, но и сохраняет репутацию продукта — а значит, напрямую влияет на бизнес.
Команда, полагающаяся на ручное тестирование и ночные релизы, хочет перейти к непрерывному выпуску обновлений. С каких трёх шагов вы советуете начать этот переход?
Во-первых, я бы порекомендовала начать с приоритизации тестов. Важно понять, какие сценарии критичны для продукта, что точно не должно сломаться при любом обновлении. Эти сценарии нужно формализовать и превратить в чёткие чек-листы или тест-кейсы. Можно начать делать их сначала в ручном формате тестирования.
Во-вторых, нужно запустить базовый набор автотестов. Не обязательно покрывать всё сразу, достаточно начать с самого важного: тестировать ключевые пользовательские действия, бизнес-логику, API. Эти тесты стоит встроить в CI/CD-процесс, чтобы они запускались автоматически при каждом изменении.
И в-третьих, рекомендую сразу внедрять feature-flags, с помощью которых можно включать или отключать отдельные функции без выпуска новой версии. Это даст возможность тестировать обновления на ограниченной аудитории (например, через canary-релизы) и снижать риски при выкладке.
И напоследок, какие профессиональные цели и планы на ближайшее будущее вы ставите перед собой?
В ближайшие годы я ставлю перед собой цель не только продолжать развиваться как инженер,
За годы в индустрии я успела накопить широкий практический опыт — от построения процессов тестирования в высоконагруженных системах до внедрения инженерных практик в обеспечении качества. Я вижу большую ценность в систематизации и передаче накопленных знаний.
Поэтому в ближайшие годы я планирую расширять свою экспертную деятельность: выступать на международных конференциях, публиковать статьи, активно участвовать в профессиональных сообществах, в том числе выступать в роли ментора для начинающих специалистов.
Я также рассматриваю возможность судейства хакатонов, технических конкурсов и peer-review деятельности. Такие инициативы позволяют не только поддерживать высокие стандарты в профессии, но и формировать культуру качества в глобальном инженерном сообществе.
Моя цель — внести вклад в развитие международных практик обеспечения качества. Мне хочется сформировать вокруг себя сильное профессиональное окружение, способное двигать отрасль вперёд, и быть полезной не только как инженер-практик, но и как эксперт индустрии, лидер и ментор.
Автор: Ульяна Ильина
