Качество · Измеримость

Как перевести тестовое покрытие цифрового банка из экспертной оценки в измеримую модель

Как превратить спор о полноте тестирования в проверяемую модель покрытия функционала?

Артем Федорчук ·

Фраза «мы всё проверили» ничего не говорит о полноте тестирования, пока у команды нет модели, по которой эту полноту можно посчитать.

Проблема

В цифровом банке покрытие тестами долго оценивалось экспертно. Команда могла назвать сильные и слабые зоны, но не могла одинаково объяснить динамику, приоритеты доработки и изменение покрытия между релизами. Такой показатель оставался мнением, а не инструментом управления.

Контекст и ограничения

В актуальной тестовой базе было 4 000+ тест-кейсов. Это масштаб, при котором ручная оценка быстро становится неполной. Покрытие не должно превращаться в самоцель: функциональность различается по критичности, а формальное добавление кейсов способно улучшить процент и ухудшить реальную проверяемость.

Подход

  1. 1Разложить продукт на функциональные элементы, для каждого из которых можно зафиксировать состояние покрытия.
  2. 2Связать требования и тест-кейсы, чтобы пробел находился по трассировке, а не по памяти инженера.
  3. 3Расставить приоритеты по критичности и сначала закрывать основные пользовательские и бизнес-сценарии.
  4. 4Использовать AI как дополнительный анализатор большой базы: искать пробелы, дубли и слабые проверки, но каждый вывод подтверждает инженер.
  5. 5Пересчитывать модель регулярно и обсуждать динамику вместе с командами разработки.

Результат

30% → 86%
покрытие функционала тестами

Обсуждение полноты сменилось разбором конкретных пробелов по модели. Покрытие стало входом для планирования работ, а не отчётом для галочки.

Ограничения показателя

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

Вывод

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