Как QA-аудит помог финтех-команде выйти на стабильные релизы

Крупная финтех-организация обратилась в SimbirSoft со срочным запросом: требовалось оперативно подключить к проекту квалифицированных QA-специалистов. Причина — резкий рост нагрузки на команду и критическая нестабильность релизов в одном из новых направлений.

О проекте

Заказчик — федеральный банк с развитой цифровой экосистемой, работающий по гибкой методологии Agile.

В его структуре — десятки кросс-функциональных команд, каждая из которых отвечает за свои микросервисы. Состав команд стандартный: тимлид (руководитель команды), системные аналитики, профильные разработчики, QA-инженеры. Но в одной из них произошли изменения.

Особенности проекта

Команда работала над микросервисом по обработке финансовых транзакций. Модель контроля качества на проекте была реализована без отдельного QA-подразделения.

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

В теории такой подход работал и был удобен для команды, но на практике он продемонстрировал ряд ограничений.

Уже через несколько спринтов (2-х недельных циклов) выявили следующие сложности:

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

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

Задача

Требовалось провести диагностику и аудит текущего состояния, настроить процессы тестирования и представить их команде.

Решение: QA как архитектурный компонент качества

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

SimbirSoft оперативно подключил двух опытных QA-инженеров с глубокой экспертизой в финтех-проектах, микросервисной архитектуре и тестировании API (Application Programming Interface, программный интерфейс приложения).

Этап 1: Диагностика и аудит

За первую неделю работы специалисты провели комплексную оценку текущего состояния процессов обеспечения качества:

1. Проанализировали текущие процессы тестирования;
2. Выявили «слепые зоны» в покрытии (например, как система реагирует на повторяющиеся одинаковые запросы, какой предельно допустимый срок обработки запросов);
3. Оценили технический долг по задачам QA.

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

Этап 2: Настройка процессов

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

• Внедрена ранняя вовлеченность QA — участие в приоритизации задач и планировании спринта.
• Введена оценка объема для QA-работ: теперь объем тестирования планируется как часть спринта, а не «остаточный ресурс».
• Стартовало написание тест-кейсов в системе управления тестированием (TMS) с четкой структурой: функциональные, негативные, граничные сценарии.
• Настроено приемочное тестирование пользователями (UAT): аналитики теперь проверяют готовый функционал, а не промежуточную стадию.

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

Этап 3: Техническая реализация

Разработаны стандартизированные чек-листы, позволяющие быстро верифицировать базовую работоспособность системы перед выпуском. Для каждого релиза выполняется дымовое тестирование — краткий набор проверок, вынесенный в тест-сьют (структурированный набор тест-кейсов), подтверждающий, что ключевые функции запущены и отвечают корректно.

Тест-кейсы, которые часто повторяются в регрессионном тестировании, были запущены для  автоматизация с использованием Postman + Newman для API и Playwright для пользовательского интерфейса (UI).

Результаты через шесть месяцев

Налажено тестирование не только функциональности, но и:

Интеграций.  Обеспечили корректность взаимодействия между внутренними компонентами системы и внешними сервисами с помощью инструментов Postman, SOAPUI, WireMock. До запуска интеграционных тестов каждая команда разработки обязана предоставить актуальный OpenAPI или Swagger-спецификацию. Интеграционные тесты в CI/CD (непрерывной интеграции и поставке) запускаются на каждом этапе пайплайна. Чтобы тесты были надежнее и меньше зависели от требований к скорости и доступности сервисов (SLA), используют замену реального сервиса заглушкой.

Производительности. Обеспечение стабильной работы при пиковых нагрузках (до 5000 RPS), Соответствие SLA: время ответы < 2 сек для 95% запросов. В частности, было выполнено моделирование реального поведения пользователей, а также превышения ожидаемой нагрузки в 2-3 раза  для выявления точек отказа.

Безопасности. Выполнена защита персональных данных клиентов по ФЗ-152, а также соответствие стандартам ISO/IEC 27001. Поставлен запрет на слияние при обнаружение критических уязвимостей и обязательная проверка безопасности (security review) перед выпуском обновлений.  При тестировании строго выполняются установленные правила и нормы (например, законы, отраслевые стандарты, внутренние регламенты компании).

Совместимости. Обеспечение работоспособности приложения на всех поддерживаемых платформах и устройствах с помощью инструментов BrowserStack для кросс-браузерного тестирования, Appium — для мобильных Е2Е-тестов (end-to-end, проверка всей системы целиком)

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