Ответ
Следующие метрики часто вводят в заблуждение, так как не отражают реальное качество работы или продукта:
-
Количество найденных дефектов (Bug Count):
- Почему неэффективна: Поощряет нахождение тривиальных, незначительных багов. Не учитывает сложность, критичность или фазу проекта (на старте багов больше).
- Лучшая альтернатива: Тренд закрытия критичных/блокирующих багов, плотность дефектов на модуль.
-
Общее количество тест-кейсов:
- Почему неэффективна: Количество не равно качеству. Может быть много дублирующих или устаревших тестов.
- Лучшая альтернатива: Покрытие требований (requirements coverage) и покрытие кода (code coverage).
-
Процент пройденных тестов (Pass Rate):
- Почему неэффективна: Можно достичь 100%, пропуская сложные или хрупкие тесты. Не показывает, какие тесты были пройдены.
- Лучшая альтернатива: Статус тестов по приоритетам (например, % пройденных критичных тестов).
-
Скорость выполнения тестов (Test Execution Speed):
- Почему неэффективна: Быстрые тесты могут быть поверхностными и пропускать сложные баги.
- Лучшая альтернатива: Соотношение времени выполнения к найденным дефектам или стабильность тестов (flake rate).
Пример плохой метрики в отчете:
Отчет за спринт:
- Найдено багов: 150 ↑ (прошлый спринт: 100) // Выглядит как улучшение, но может означать низкое качество кода.
- Пройдено тестов: 95% // Не показывает, что 5% — это критические smoke-тесты.Эффективные метрики фокусируются на риске (покрытие критичных сценариев), качестве (серьезность дефектов) и эффективности (автоматизация рутинных проверок).
Ответ 18+ 🔞
Да ты посмотри, на что люди тратят время, ёпта! Сидят, высчитывают цифры, которые нихрена не говорят о реальном положении дел. Прямо как в той басне про лебедя, рака и щуку — все тянут, а воз и ныне там. Вот смотри, какие метрики нас просто в пизду заводят.
Возьмём, например, количество найденных багов. Ну, классика жанра! Руководство смотрит: "О, 150 багов! Молодцы, тестировщики, работают!". А на деле половина из них — это опечатки в сообщениях или кнопка на пиксель съехала. Серьёзных-то дефектов — штук пять. Получается, мы тут все вздрачиваем статистику, а продукт-то всё равно с душком. Вместо этого надо смотреть на тренд по критичным багам. Упало их количество — вот это уже повод выпить чаю без огорчений.
Или вот общее число тест-кейсов. Э, бошка, думай! Можно же наклепать их овердохуища, таких, что одно описание на три страницы. А по сути они все одно и то же проверяют, да ещё и на устаревший функционал. Пиздец, а не метрика. Гораздо важнее покрытие требований — чтобы каждая важная фича была под прицелом. И покрытие кода, чтобы не осталось тёмных, не проверенных закоулков, где и прячется эта манда с ушами — серьёзный баг.
Процент пройденных тестов — это вообще шедевр идиотизма. Легко достичь 95%, если просто не запускать те пять процентов сложных, хрупких или долгих проверок. "А, да похуй, они у нас постоянно падают". И что? Продукт готов? Нет, блядь! Смотрите на статус по приоритетам. Если 100% критичных сценариев прошло — вот это уже тепло. А если они все провалились, то ваши 95% — просто красивая, бесполезная хуйня.
Ну и скорость выполнения тестов. Да, конечно, если они пролетают за секунду — это хорошо. Но если они за эту секунду нихрена не проверяют, то какая разница? Это как бежать сломя голову, но не в ту сторону. Лучше уж мерять стабильность тестов или сколько реальных проблем они находят за отведённое время.
Смотри, как выглядит отчёт-мудак:
Отчет за спринт:
- Найдено багов: 150 ↑ (прошлый спринт: 100) // Выглядит как улучшение, но может означать низкое качество кода.
- Пройдено тестов: 95% // Не показывает, что 5% — это критические smoke-тесты.Волнение ебать! Руководство прочитает и успокоится. А на деле-то — пидары налетели, проект накрывается медным тазом, потому что дымовые тесты не работают!
Вывод простой, как хуй с горы: гоните не на объём, а на смысл. Эффективная метрика — это та, что показывает риск (проверили ли мы самое страшное?), качество (насколько серьёзны найденные косяки?) и толк (не тратим ли мы время на ерунду?). Всё остальное — пиздопроебибна для красивых графиков.