Команда использует показатель эффективности удаления дефектов, рассчитанный так:
def эффективность_удаления(до_релиза, после_релиза):
return до_релиза / (до_релиза + после_релиза)
команда_а = эффективность_удаления(90, 10)
команда_б = эффективность_удаления(9, 1)
Можно ли на основании одинакового результата сравнить качество двух команд?
Нет, одинаковый DRE (Defect Removal Efficiency, эффективность удаления дефектов) не доказывает одинаковое качество команд. Показатель отражает долю обнаруженных до релиза дефектов только в пределах зафиксированных дефектов и при сопоставимых правилах подсчёта.
В примере обе команды получили 90%, но первая обработала 100 дефектов, а вторая — 10. Кроме того, показатель не учитывает неизвестные дефекты, различия в сложности продукта, критичности ошибок и полноте пострелизного наблюдения.
Метрики вроде DRE появились из потребности оценивать не только количество найденных дефектов, но и способность процесса обнаруживать их до передачи продукта пользователям. Такой подход смещает внимание с индивидуальной продуктивности тестировщиков на эффективность всего процесса разработки и контроля качества.
Метрика полезна как инструмент анализа этапов обнаружения дефектов, но не как самостоятельная оценка качества продукта или команды. Её смысл зависит от границ измерения и качества исходных данных.
Формула использует число дефектов, найденных до релиза, и число дефектов, найденных после релиза:
DRE = дефекты до релиза / (дефекты до релиза + дефекты после релиза).
Если команда фиксирует обращения пользователей хуже, чем другая, её пострелизное число дефектов будет искусственно ниже, а DRE — выше. Аналогичное искажение возникает, если команды по-разному учитывают дубликаты, повторно открытые дефекты, исправления конфигурации или дефекты, найденные после окончания разных периодов наблюдения.
Неверное сравнение может привести к ошибочному решению: признать процесс одной команды более зрелым, сократить проверки или установить неподходящие цели качества.
DRE можно сравнивать только при согласованных условиях:
Даже при этих условиях DRE следует анализировать вместе с другими показателями: количеством критических дефектов после релиза, дефектами на единицу объёма изменения, частотой отказов и временем обнаружения. Одно высокое значение может означать как хороший процесс предотвращения дефектов, так и слабое обнаружение проблем после выпуска.
Практичнее отслеживать динамику одной команды при стабильной методике, а не ранжировать команды по одному числу. Для критичных дефектов полезно строить отдельные разрезы: общий DRE может вырасти, пока редкие, но опасные ошибки по-прежнему пропускаются.
В приведённом коде обе команды имеют одинаковый процент, но разный абсолютный объём наблюдений. Поэтому результат говорит только о совпадении рассчитанной доли, а не о равной защищённости продукта.
У двух продуктовых команд DRE за квартал составил 92%. Первая команда выпускала платёжные изменения и имела строгую регистрацию инцидентов, вторая развивала внутренний инструмент, где пользователи редко сообщали о проблемах.
Рассматривались два варианта. Можно было использовать DRE для рейтинга команд: это просто и создаёт единый числовой ориентир, но поощряет уменьшение числа зарегистрированных пострелизных дефектов и игнорирует различия в рисках. Можно было полностью отказаться от DRE: это исключает неправильное ранжирование, но лишает команд полезного сигнала о месте обнаружения дефектов.
Выбрали второй вариант использования: DRE оставили для анализа динамики внутри каждой команды, разделили дефекты по критичности и добавили число серьёзных дефектов после релиза и полноту регистрации инцидентов. Это позволило не считать одинаковые 92% доказательством одинакового качества и направить улучшения на платёжный процесс, где цена пропуска была выше.
Высокий показатель может быть следствием малого числа зарегистрированных дефектов после релиза, короткого окна наблюдения или слишком узкого набора проверок. Он также может вырасти, если дефекты обнаруживаются до релиза, но исправляются формально и повторно проявляются после выпуска. Поэтому нужно анализировать не только долю, но и абсолютные значения, критичность и последующее поведение дефектов.
У релизов различаются размер изменений, длительность эксплуатации и количество пользователей. Старый релиз успел накопить больше пострелизных находок, чем недавно выпущенный, поэтому объединение периодов может искусственно улучшить или ухудшить DRE. Корректнее задавать единое окно наблюдения или явно учитывать зрелость релиза.
Нельзя связывать оценку людей только с DRE. Иначе появится стимул не регистрировать дефекты, занижать их критичность или переносить обнаружение между категориями. Метрику нужно использовать на уровне процесса, проверять качество исходных данных и дополнять показателями пользовательского воздействия, критических пропусков и скорости устранения проблем.