Представьте ситуацию.

В прошлом месяце команда нашла 120 дефектов, а в этом всего 40.

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

Но действительно ли продукт стал качественнее? За время управления тестированием я убедился, что количество найденных багов само по себе практически ничего не говорит о качестве продукта.

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

→ Разработчики стали лучше проверять свой код, улучшились требования и процессы ревью.

→ Мы автоматизировали больше проверок и начали находить проблемы раньше.

→ В этом месяце просто было меньше изменений или они оказались менее сложными.

→ Команда не успела провести полноценное тестирование и часть проблем осталась незамеченной.

Результат в отчёте одинаковый. А вот выводы совершенно разные.

И здесь возникает довольно неприятный парадокс.

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

А если поставить KPI на снижение числа дефектов, можно вообще получить обратный эффект.

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

Именно поэтому мне никогда не нравилась идея оценивать эффективность QA количеством найденных ошибок.

Для меня гораздо интереснее другие вопросы. Сколько критических дефектов доходит до продакшена? На каких этапах возникают и обнаруживаются проблемы? Почему задачи возвращаются на доработку? Какие причины повторяются из релиза в релиз?

И главное — что мы изменили, чтобы этих проблем изначально возникало меньше?

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

Но если багов стало меньше просто потому, что мы сократили объём проверок, радоваться особенно нечему.

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

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

Мне кажется, одна из главных задач руководителя — не просто следить за динамикой показателей, а понимать, какие изменения в процессах за ней стоят.

Ведь наша цель не в том, чтобы тестировщики находили меньше багов.

Наша цель — чтобы пользователи сталкивались с меньшим количеством проблем. И желательно, чтобы большая часть этих проблем вообще не появлялась.