Краткий ответ

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

Исторический контекст

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

Однако любая метрика является лишь приближённым сигналом. Когда на неё напрямую накладывают индивидуальную оценку или бонус, участники начинают адаптировать поведение под измеряемый показатель, даже если это ухудшает исходную цель — надёжный продукт.

Постановка проблемы

Число найденных дефектов зависит не только от качества работы QA. На него влияют объём изменений, сложность продукта, зрелость требований, количество проверок, время на тестирование и то, насколько тщательно команда оформляет мелкие несоответствия.

Если высокий показатель считается безусловно хорошим, возникают нежелательные последствия:

дефекты могут дробиться на множество малозначимых задач;
серьёзные проблемы могут скрываться до поздних этапов, чтобы не ухудшать статистику других участников;
проверки выбираются по способности находить дефекты, а не по влиянию на риск;
разработчики и QA начинают конфликтовать из-за количества зарегистрированных задач.

В результате метрика растёт, но качество продукта и доверие к отчётности снижаются.

Подробное решение

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

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

Метрики следует использовать для поиска системных причин и выбора улучшений. Если после изменения процесса снизилось число дефектов после релиза при сопоставимом объёме и риске изменений, это более убедительный сигнал, чем простое увеличение количества найденных задач.

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

Главный компромисс состоит в том, что многомерные метрики сложнее объяснять и сравнивать. Зато они хуже поддаются манипулированию и ближе к реальной цели. Абсолютно универсального набора показателей нет: состав зависит от типа продукта, модели поставки и цены дефекта.

Ситуация из практики

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

Рассматривались два варианта. Первый — полностью отказаться от метрик; это убрало бы прямой стимул к накрутке, но лишило бы команду данных для анализа. Второй — сохранить количество дефектов как единственный KPI; его было проще считать, однако он закреплял ошибочное поведение.

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

Через несколько итераций команда стала раньше подключать QA к анализу изменений и направлять усилия на критичные сценарии. Число зарегистрированных дефектов снизилось, но уменьшилось и количество серьёзных проблем после релиза — то есть улучшился целевой результат, а не только отчётный показатель.

Что кандидаты часто упускают

Можно ли считать большое число найденных дефектов признаком сильной работы QA?

Нет, без контекста такой вывод некорректен. Большое число находок может означать тщательное тестирование, низкое качество входящих изменений, неясные требования или чрезмерное дробление задач. Оценивать нужно не объём находок сам по себе, а их значимость, своевременность обнаружения и влияние на риск выпуска.

Почему показатель дефектов после релиза тоже нельзя использовать как единственный KPI?

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

Как понять, что метрика стала вредной для процесса?

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