Как QA-аудит помог финтех-команде выйти на стабильные релизы
Крупная финтех-организация обратилась в SimbirSoft со срочным запросом на подключение специалистов по обеспечению качества (QA-специалистов). Поводом стали резкий рост нагрузки на команду и критическая нестабильность релизов в одном из новых направлений.
Проект развивался в структуре федерального банка с большой цифровой экосистемой и десятками кросс-функциональных команд, работающих по гибкой методологии Agile. Одна из команд занималась микросервисом обработки финансовых транзакций, но при этом модель контроля качества была выстроена без отдельного QA-подразделения: часть проверок выполняли аналитики, а интеграционное тестирование передавалось смежной команде.
На практике такой подход быстро показал ограничения: проверки сдвигались из-за более приоритетных задач, критические ошибки находили поздно, а глубинные сценарии часто вообще не покрывались. В результате релизы переносились, росли операционные затраты и усиливался риск ошибок из-за ручной проверки.
Задача
Требовалось:
- провести диагностику и аудит текущего состояния QA-процессов;
- выявить слабые места в покрытии и организации тестирования;
- настроить процессы тестирования и встроить их в жизненный цикл разработки;
- представить и внедрить новые подходы в работу команды.
Решение
Работу начали не с автоматизации, а с аудита процессов, поскольку в финтехе любые поспешные действия без понимания корневых причин только маскируют риски. SimbirSoft подключил двух QA-инженеров с опытом в финтехе, микросервисной архитектуре и тестировании программного интерфейса (API). Дальше работа шла поэтапно:
-
Диагностика и аудит.
За первую неделю специалисты проанализировали существующие процессы тестирования, выявили «слепые зоны» в покрытии и оценили технический долг по QA-задачам. Аудит затронул не только техническую часть, но и бизнес-контекст, что помогло увидеть расхождения между ожиданиями заказчика и фактической работой команды в спринтах. -
Настройка процессов.
После аудита была выстроена базовая инфраструктура QA-процессов. QA подключили к приоритизации задач и планированию спринтов, а объем тестирования стали учитывать как полноценную часть спринта, а не как остаточную нагрузку. Также началось системное ведение тест-кейсов в TMS (системе менеджмента кейсов): с разделением на функциональные, негативные и граничные сценарии. Отдельно было настроено приемочное тестирование пользователями, при котором аналитики проверяют уже готовый функционал, а не промежуточные результаты. Уже на этапе проектирования тест-кейсов заложили проверки на соответствие ФЗ-152 и внутренним банковским регламентам. -
Техническая реализация.
Для релизов разработали стандартизированные чек-листы и внедрили дымовое тестирование, чтобы быстро подтверждать базовую работоспособность ключевых функций перед выпуском. Повторяющиеся сценарии регрессионного тестирования начали автоматизировать: для API использовали Postman + Newman, для пользовательского интерфейса — Playwright. -
Расширение тестового покрытия.
Через несколько месяцев тестирование охватило не только функциональность, но и интеграции, производительность, безопасность и совместимость. Для интеграций применяли Postman, SOAPUI и WireMock, запускали проверки в CI/CD (непрерывная интеграция и доставка) и использовали заглушки для снижения зависимости от внешних сервисов. Для производительности моделировали реальные и повышенные нагрузки до 5000 RPS. В блоке безопасности обеспечили соответствие ФЗ-152 и ISO/IEC 27001, ввели запрет на слияние при критических уязвимостях и обязательную проверку безопасности перед релизом. Для совместимости использовали BrowserStack и Appium.
Результат
Через шесть месяцев получили такие результаты:
- 100% соблюдение графика релизов и повышение их стабильности.
- На 70% снижены критические ошибки в рабочей среде.
- Время на интеграционное тестирования сокращено до 3-5 дней.
Полную версию материала с детальным описанием кейса читайте на сайте РБК Компании.