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

В рамках внутреннего исследовательского проекта мы пытаемся собрать некоторые метрики из базы данных Bugzilla; мы уже нашли инструмент, который поможет нам собрать из него некоторые показатели (BugzillaMetrics), но теперь мы спрашиваем себя какие метрики мы должны собирать?

Вот почему я хотел бы спросить вас:

**

Какие метрики об ошибках вы собираете?

**

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

Заранее спасибо =)


metrics
person Hugo    schedule 20.04.2009    source источник

Ответы (4)


arrow_upward
4
arrow_downward

Одним из важных показателей является количество дефектов, обнаруженных за единицу времени (например, неделя, итерация тестирования и т. Д.). Это может быть хорошим индикатором того, когда можно прекратить тестирование и исправление. Конечно, этот показатель также может учитывать приоритет ошибок (вас может быть меньше интересует, если в неделю сообщается 10 тривиальных ошибок, чем если есть 1-2 серьезных дефекта в неделю).

Другой показатель, который может оказаться полезным, - это среднее время для исправления дефекта (время между сообщением и исправлением / закрытием ошибки).

person Cătălin Pitiș    schedule 20.04.2009

arrow_upward
2
arrow_downward

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

Однако учтите, что вы все равно не сможете просто сказать, что ошибка X должна занять Y времени, потому что она похожа на ошибку Z. Но вы можете позволить разработчику Бейкеру взглянуть на это, и когда «это займет 2 дня, чтобы исправить», вам будет что судить, насколько он точен.

person RS Conley    schedule 20.04.2009

arrow_upward
1
arrow_downward

Предлагаю следующий список показателей:

  • Количество открытых в настоящее время дефектов во всем продукте.
  • Метрики для диаграммы выгорания итерации: количество открытых ошибок / задач, количество исправленных ошибок / задач, запланированных для данной итерации.
  • Процент обнаружения дефектов для каждой версии продукта. Этот показатель показывает соотношение между дефектами, обнаруженными во время разработки и контроля качества, по сравнению с дефектами, обнаруженными после контроля качества, когда версия уже была выпущена.
person Mark Kofman    schedule 30.08.2010

arrow_upward
1
arrow_downward

Ниже приведены наиболее полезные из них:

  1. Соотношение КРИТИЧЕСКИХ и ОСНОВНЫХ ошибок, обнаруженных за итерацию, и среднее время, необходимое для их устранения. например могут быть нацелены за часы для КРИТИЧЕСКОГО и за несколько дней для БОЛЬШОГО, целевые показатели могут быть пересмотрены на основе исторических цифр, чтобы быть реалистично сложными.

  2. Количество ГЛАВНЫХ ошибок, остающихся в продукте на момент выпуска. Может быть приемлемым выпуск с 3, 5 или 7 ОСНОВНЫМИ, в зависимости от продукта / отрасли / клиента. {{Предполагается, что КРИТИЧЕСКИЕ ошибки = 0, т. Е. Неприемлемо. }}.

  3. Коэффициент срока службы высокого приоритета: отношение времени разрешения P1 к СРЕДНЕМУ времени разрешения всех приоритетов.

  4. Частота повторного открытия: CR Процент повторно открытых дел из числа исправленных в итерации.

  5. CR без комментариев / ответов в течение 2 дней: доля случаев, когда нет ответа от НИОКР в течение 2 дней после создания.

  6. Приоритет серьезных ошибок Средний приоритет блокировщика и критических CR

  7. Соотношение разрешенных случаев с разрешением НЕДЕЙСТВИТЕЛЬНО | или ДУБЛИКАЦИЯ.

Сушил Джалали

person Susheel    schedule 16.04.2012