−70% критических ошибок в финтех-кейсе за счёт внедрения QA

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

Компания обратилась к нам за наймом двух QA-специалистов. Но мы начали не с подбора людей, а с аудита процессов. Выяснилось, что команда проверяла только базовые сценарии, упуская поведение системы при сбоях сети или некорректных форматах данных. Интеграционные тесты отдавались соседней команде с её более высокими приоритетами. А регуляторные требования ФЗ‑152 вообще не были зашиты в тест-кейсы. Качество проверялось по остаточному принципу.

Что мы внедрили: раннее вовлечение QA в планирование спринта, чёткое разделение ответственности между автоматизированными и ручными проверками, обязательное ревью перед каждым релизом. Теперь объём QA-работ оценивается наравне с разработкой.

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

Подробности кейса — https://companies.rbc.ru/news/Y1lcwDL7oI/kak-qa-audit-pomog-finteh-komande-vyijti-na-stabilnyie-relizyi/

−70% критических ошибок в финтех-кейсе за счёт внедрения QA
Поделюсь кейсом. В одном из проектов QA-функция изначально была «размазана» между аналитиками и смежной командой | Сетка — социальная сеть от hh.ru