Всем привет! Меня зовут Алексей Архипов. Я работаю начальником отдела тестирования в Национальном клиринговом центре (НКЦ), входящем в состав Группы «Московская биржа». За последние годы мы столкнулись с множеством вызовов в оценке качества программного обеспечения (ПО), особенно в условиях высокой нагрузки и сложности критических систем. В начале работы с QA-командой меня заинтересовал ключевой вопрос — каким образом можно точно измерить качество тестирования? Ответ оказался неочевидным.

В современных условиях тестирование ПО — это не просто процесс проверки функциональности, а ключевой элемент управления качеством. Однако популярная метрика Defect Leakage (DL), которую часто используют для оценки работы QA-инженеров, не всегда отражает реальную картину. В НКЦ мы столкнулись с этой проблемой и разработали для себя более точный подход — Коэффициент эффективности тестирования (КЭТ). В этой статье я расскажу, почему DL не работает, как мы внедрили КЭТ и какие результаты получили.

Проблема с метрикой Defect Leakage: когда цифры вводят в заблуждение

Defect Leakage — это отношение количества дефектов, найденных на промышленном контуре, к общему числу дефектов, обнаруженных в ходе тестирования. Формула выглядит так: 

На первый взгляд, это логично: чем меньше дефектов утекает на промышленный контур, тем лучше QA. Однако на практике DL обладает рядом критических недостатков:

1. Нет учета критичности дефектов

Проблема: Все дефекты считаются равными, независимо от их влияния на бизнес.

Пример: Незначительный баг (например, смещение элемента интерфейса) и критический сбой (например, ошибка в финансовой транзакции) получают одинаковый вес.

Последствия: Утечка одного критического дефекта может привести к миллионам потерь, а несколько мелких — остаться незамеченной. DL не отражает риски, связанные с дефектами.

 2. Смещение выборки из-за специфики продукта

Проблема: Некоторые дефекты невозможно обнаружить без запуска на промышленном контуре.

Пример: Ошибки интеграции с внешними системами или зависимость от конкретных железок.

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

 3. Невозможность сравнения между продуктами

Проблема: DL не учитывает сложность продуктов.

Пример:

Продукт A: 100% DL, но это простой веб-интерфейс.

Продукт B: 50% DL, но это система клиринга с десятками интеграций.

Последствия: Высокий DL для сложного продукта — это может быть допустимо, а для простого — катастрофа. Сравнивать такие метрики бесполезно.

 4. Негативное влияние на мотивацию команды

Проблема: QA-инженеры могут избегать поиска сложных дефектов, чтобы не "портить" статистику.

Пример: Фокус на сборе мелких багов (например, ошибки оформления), в то время как системные сценарии остаются непроверенными.

Последствия: Метрика превращается в инструмент давления, а не в стимул к улучшению качества.

Есть и другие причины по которым DL не всегда отображает реальную эффективность тестирования: зависимость от объема тестирования, зависимость от объема изменений в релизе и т.д.

В НКЦ мы столкнулись с подобной ситуацией: метрика DL показывала высокую эффективность, но на промышленном контуре всё равно происходили критические сбои. Это заставило нас пересмотреть подход.

Коэффициент эффективности тестирования (КЭТ): новый взгляд на качество

Чтобы учесть критичность дефектов и избежать искажений, мы внедрили КЭТ. Основная идея — присвоить к каждому дефекту коэффициент (вес), отражающий его значимость для бизнеса.

 Формула КЭТ:

где:

● W _testn- вес дефекта по критичности:

вес дефекта определяется по шкале критичности (например: 1–3):

3 — критические дефекты (блокирующие функциональность, угрожающие безопасности);

2 — значимые (некорректная логика, частичные сбои);

1 — незначительные (ошибки дизайна, мелкие неудобства).

● QA_pn– количество дефектов, найденных на QA тестировании, по приоритетам;

● UAT_pn- количество дефектов, найденных на UAT тестировании (если есть), по приоритетам;

● P_pn- количество дефектов, найденных на промышленном контуре, по приоритетам.

Сравнение Defect Leakage и коэффициента эффективности тестирования: когда что использовать? 

Преимущества коэффициента эффективности тестирования перед метрикой Defect Leakage

1. Объективность: учитывает влияние дефектов на бизнес.

2. Гибкость: метрика адаптируется к сложности продуктов.

3. Мотивация: QA-инженеры сосредотачиваются на важных сценариях, а не на количестве.

4. Сравнение: позволяет корректно оценивать эффективность разных продуктов.

Когда использовать Defect Leakage, а когда — коэффициент эффективности тестирования?

Как внедрить коэффициент эффективности тестирования в вашей компании?

1. Собрать исторические данные: проанализируйте дефекты за последние 3–6 месяцев.

2. Согласовать шкалу весов: работайте совместно с командой разработчиков, аналитиков, PM, техподдержкой и т.д.

3. Интеграция с инструментами:

   ● Добавьте при необходимости кастомное поля в Jira.

   ● Настройте автоматизированный сбор статистики.

4. Провести обучение QA-инженеров.

5. Визуализировать данные: создайте дашборды в Jira/Power BI/Grafana и т.д.

6. Регулярно пересматривать веса: адаптируйте шкалу под изменения в продукте и бизнес-приоритетах.

7. Регулярно анализировать итоги.

Примеры применения и результаты

1. Пример завышения результатов по DL

DL: 10% (5 из 50 дефектов «утекло» на промышленный контур).

КЭТ: 75% (сумма веса найденных дефектов: 45, упущенных: 15).

Анализ: хотя утечка в процентах казалась низкой, КЭТ показал, что упущенные дефекты были критичными. Это позволило скорректировать фокус тестирования на более важные сценарии.

2. Пример занижения результатов по DL

DL: 40% (20 из 50 дефектов «утекло» на промышленный контур).

КЭТ: 82% (сумма веса найденных дефектов: 90, упущенных: 20).

Анализ: хотя утечка в процентах казалась высокой, КЭТ показал, что упущенные дефекты были некритичными, а все критичные были найдены в рамках тестирования. Это важно для систем, где мелкие дефекты не критичны для бизнеса и качества работы ПО.

Итоги

Коэффициент эффективности тестирования стал для нас более объективной метрикой, чем Defect Leakage. Он помогает увидеть, насколько тестирование защищает бизнес-критичные процессы, а не просто формирует статистику.

В НКЦ мы убедились, что переход от DL к КЭТ позволяет не только точнее оценивать эффективность тестирования, но и повышать качество ПО. Эта метрика особенно актуальна в системах, где стоимость упущенного дефекта может быть катастрофической. Надеемся, что наш опыт поможет вашей команде найти баланс между количественными показателями и реальным качеством продукта.