Может опираться на количество найденных багов или пропущенных? А может на количество вообще не стоит обращать внимание? А на какие метрики тогда ориентироваться?

Делюсь своим опытом и опытом наших подписчиков.

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

Я имею в виду сейчас не какие-то единичные метрики, а комплексный подход, который мог бы достаточно объективно и качественно оценить работу как отдела тестирования, так и отдельно взятого специалиста.

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

Мой опыт

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

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

Необходимо было менять ситуацию и стараться находить баги как можно раньше. В идеале за первые 20% времени от тестирования релиза. То есть, если у нас есть 20 часов на тестирование, то баги мы должны найти в первые 4 часа, хотя бы все критичные.
Проблема понятна, цель поставлена.

Следующим этапом необходимо было понять, во-первых, насколько все плохо сейчас и, во-вторых, как мы определим, что добились поставленной цели. Вот тут на помощь и пришла метрика, с помощью которой мы четко смогли представить нашу проблему в количественном виде.

Для этого мы взяли общее количество времени на тестирование и поделили его на несколько временных отрезков — 20%, 60% и снова 20%. На каждом из отрезков мы считали количество найденных багов. Если бОльшая часть багов была найдена на первом отрезке, то все хорошо, если на последнем — с качеством тестирования все плохо.

Сначала сделали метрику на предыдущие релизы, чтобы сформировать более-менее объективное представление текущей ситуации. Далее необходимо было выработать решение и посмотреть, как изменится метрика с новыми условиями тестирования. Что мы успешно и сделали.

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

Почему-то когда многие слышат, что собирается такая метрика, считают, что тестировщики должны находить определенное количество багов в день. Если они будут находить меньше багов, то их уволят. У нас было абсолютно не так.

Конечно, никакого дневного минимума количества багов не было. Статистика была лишь одним из инструментов оценки качества работы специалиста. Причем, к этой статистике подходили очень аккуратно. Она позволяла определить общий объем работы тестировщика за указанный период. И если этот объем систематически проседал, то метрика являлась лишь поводом узнать, все ли хорошо у специалиста.

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

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

Получается, что:
1. Метрики можно и нужно использовать для определенных целей.
2. Работать с ними требуется очень аккуратно, оценивая общую картину и смотря критическим взглядом.
3. Метрика сама по себе не эффективна, ее цель лежит за рамками этой метрики.

Опыт подписчиков

Спасибо всем, кто поделился своим опытом в использовании метрик (как под постом с вопросом так и в сообщениях). Итак, метрики, которые вы используете в тестировании:

• Тестовое покрытие кейсами, чтобы понимать сколько процентов функционала покрыто кейсами.
• Плотность дефектов в модулях, чтобы понимать какой именно модуль наиболее проблемный и где именно возникает больше всего ошибок.
• Коэффициент регрессии. Чтобы понимать чем чаще всего занимается команда, созданием и отладкой новых фитч, или чаще латаем старый функционал.
• Коэффициент повторно открытых дефектов. Чтобы оценить разработку, сложность продукта и отдельных модулей.
• Эффективность тестов. Чтобы понимать сколько ошибок находятся с помощью имеющихся кейсов и есть ли смысл их актуализировать в текущей итерации.
• Доля неподтвержденных дефектов. Чтобы понимать сколько дефектов заведено впустую.
• Учет возврата с ОЭ, на доработку, при этом разделяя на баги, пропущенные(1), неоговоренные, но подразумевающиеся «хотелки»(2) и вновь появившиеся пожелания(3).
• Срез на предмет в каком функционале больше проблем и характер их (фронт или бэк).
• Правильнее метрики вести на весь проект. Например на сколько точны оценки трудозатрат.
  «У нас были частые превышения оценки, выяснили что много возвратов задач (то ж стали метрики собирать на эту тему). Приняли некоторые меры.
  Или то что оценки оказались заниженными в среднем на одну и ту же величину. Стали коэффициент добавлять к человеческим оценкам.»
• Клиенты не жалуются — все хорошо)

***

С помощью правильных метрик можно не только оценить качество тестирование, но и выявить скрытые проблемы. Главное условие — метрики должны отталкиваться от реальности, а не основываться на недостижимых желаниях.

Смотрите, какие задачи сейчас стоят перед вами, на что нужно делать упор и что важно заказчику. Отслеживайте проблемные моменты в тестировании и вводите на них метрики, чтобы фиксировать эффективность мер по их устранению.

________________________________
Золотая мысль подписчика:
Метрики полезны для выявления определенных проблем. От проблемы и зависит то, какие метрики выбираешь. Не стоит вводить метрики ради метрик.
________________________________