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

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

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

**

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

**

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

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

Ответы [ 4 ]

4 голосов
/ 20 апреля 2009

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

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

2 голосов
/ 20 апреля 2009

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

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

1 голос
/ 16 апреля 2012

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

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

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

  3. Коэффициент времени жизни высокого приоритета: отношение времени разрешения P1 к времени разрешения AVERAGE всех приоритетов.

  4. Частота повторных открытий: CRs Процент вновь открытых дел из числа зафиксированных в итерации.

  5. CRs без комментариев / ответов в течение 2 дней: соотношение случаев, когда ответы на исследования и разработки не были получены через 2 дня после создания.

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

  7. Соотношение разрешенных дел с разрешением INVALID | или ДУБЛИКАТ.

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

1 голос
/ 30 августа 2010

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

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