Какие знаешь не эффективные метрики?

Критика неэффективных метрик в QA

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

1. Метрики, стимулирующие неправильное поведение

Эти показатели напрямую влияют на действия команды, часто не в лучшую сторону.

• Количество найденных дефектов (Bug Count) в разрезе тестировщика:

    *   **Проблема:** Эта метрика поощряет соревнование между тестировщиками в поиске максимального количества багов, особенно низкоприоритетных или тривиальных (например, опечатки в неосновном интерфейсе). Это приводит к "накрутке" цифр, игнорированию более сложных и важных областей тестирования (например, security, performance) и создает конфликтную среду. Разработчики начинают воспринимать QA как "охотников за головами".
    *   **Альтернатива:** Лучше смотреть на **качество отчетов о дефектах** (четкость шагов воспроизведения, наличие логов, воспроизводимость), **покрытие риск-ориентированных сценариев** или **время отклика на инциденты в production**.

• Процент пройденных тест-кейсов (Test Case Pass Rate):

    *   **Проблема:** Эта метрика создает иллюзию прогресса. Команда может гнаться за 100% прохождением заранее написанных, возможно, устаревших тест-кейсов, игнорируя исследовательское тестирование, которое часто находит самые критичные проблемы. Кроме того, она не учитывает сложность кейсов. Пройти 100 простых кейсов — не равно обеспечить качество сложной интеграции.
    *   **Альтернатива:** Метрики, отражающие **покрытие пользовательских сценариев и бизнес-рисков**, **плотность дефектов в production (Defect Density)** после релиза или **отзывы пользователей из каналов поддержки**.

2. Метрики, не отражающие реальное качество продукта

Эти цифры могут выглядеть хорошо на дашборде, но при этом продукт может быть полон проблем.

• Строка кода, покрытая тестами (Code Coverage %):

    *   **Проблема:** Пожалуй, самый классический пример "ванной метрики". Высокий процент покрытия (например, 90%) не гарантирует, что тесты являются осмысленными, проверяют корректность логики или ловят пограничные случаи. Легко достичь высокого покрытия, написав поверхностные тесты, которые просто "проходят" по коду.

```java
// Плохой пример: тест для галочки, дает покрытие, но не проверяет логику.
@Test
public void testCalculateDiscount() {
    DiscountService service = new DiscountService();
    service.calculateDiscount(100); // Вызов метода есть, но нет assert-проверки результата!
    // Покрытие засчитано, пользы ноль.
}
```

    *   **Альтернатива:** Анализ **покрытия условий и решений (Branch Coverage)**, которое сложнее "надуть", а также регулярный **ревью тестов** на предмет их осмысленности и связи с требованиями. Важнее качество, а не количество тестов.

• Скорость закрытия дефектов (Bug Closure Rate):

    *   **Проблема:** Давление на скорость закрытия может привести к тому, что разработчики будут "закрывать" баги как `Duplicate`, `Won't Fix`, `By Design` или `Cannot Reproduce` без должного анализа, лишь бы улучшить метрику. Это откладывает реальные проблемы и подрывает доверие внутри команды.
    *   **Альтернатива:** Мониторинг **времени жизни дефекта (Bug Cycle Time)** — от создания до реального исправления, а также **коэффициента повторного открытия багов (Bug Reopen Rate)**. Эти метрики говорят о качестве анализа и исправления.

3. Абсолютные и изолированные метрики

Цифры, которые без контекста бесполезны или опасны.

• Общее время тестирования (Total Testing Time):

    *   **Проблема:** Больше времени — не значит лучше качество. Эта метрика не учитывает эффективность методов тестирования, уровень автоматизации или сложность функциональности. Она может использоваться для несправедливых сравнений между командами или проектами.
    *   **Альтернатива:** **Время на feedback-цикл (Feedback Cycle Time)** — как быстро команда получает информацию о качестве (например, от прогона автотестов). Или **соотношение времени на профилактику/обнаружение/исправление дефектов**.

• Количество автоматизированных тестов (Number of Automated Tests):

    *   **Проблема:** Как и с покрытием кода, это "ванная метрика". 5000 хрупких, нефункциональных или дублирующих автотестов — это огромные затраты на поддержку и ложное чувство безопасности. Они могут постоянно "падать" (flaky tests), создавая шум.
    *   **Альтернатива:** **Стабильность тестового набора (Pass Rate автотестов в CI/CD)**, **стоимость поддержки тестов** и их **бизнес-ценность** (сколько критичных регрессий они поймали). Ключевой вопрос: "Что эти тесты защищают?"

Вывод и рекомендации

Ни одна метрика не должна использоваться изолированно для оценки личности тестировщика или как единственный KPI команды. Эффективный мониторинг качества строится на:

• Наборе сбалансированных метрик (Balance Scorecard), которые смотрят на продукт с разных сторон: процесс (цикл разработки), продукт (стабильность в production), перспектива (удовлетворенность пользователя).
• Постоянном анализе контекста. Падение количества багов перед релизом — это хорошо (все пофиксили) или плохо (перестали искать)?
• Фокусе на метриках-результатах, а не метриках-активностях. Влияние на снижение числа инцидентов в production (MTBF — Mean Time Between Failures) или увеличение удовлетворенности клиентов (CSAT/NPS) всегда важнее, чем количество выполненных тест-кейсов.

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