4

内部調査プロジェクトの一環として、Bugzillaデータベースからいくつかのメトリックを収集しようとしています。そこからいくつかのメトリックを収集するのに役立つツール（BugzillaMetrics）をすでに見つけましたが、現在、どのメトリックを収集する必要があるかを自問しています。

さて、それが私があなたに尋ねたい理由です：

****

バグに関するどのような指標を収集しますか？

****

私たちのオフィスでは、チームは小さく（2〜5人の開発者）、開発者ごとのバグ、開発スプリントごと、カテゴリごとのバグ（GUI、ビジネスロジック、データベース）などのメトリックを検討しましたが、他のアイデアも聞きたいと思います。

よろしくお願いします=）

4

4 に答える 4

4

関連するメトリックの1つは、時間単位（たとえば、週、テストの反復など）で検出された欠陥の数です。これは、テストと修正を停止することが許容される場合の良い指標になる可能性があります。もちろん、このメトリックでは、バグの優先度も考慮することができます（1週間に1〜2の大きな欠陥がある場合よりも、1週間に10の些細なバグが報告されている場合は、関心が低くなる可能性があります）。

役立つと思われるもう1つの指標は、欠陥を修正するための平均時間（バグを報告してから修正/クローズするまでの時間）です。

于 2009-04-20T17:34:24.690 に答える
2

カテゴリごとのバグは間違いありません。また、実際に費やした時間に対する時間の見積もりも行います。開発者に正確な見積もりを行う方法を学ぶためのツールを提供するポイント。時間の見積もりはあいまいなプロセスであり、最良の情報源は経験です。このメトリックを使用すると、すべての人からの見積もりに自信を持てるようになります。

ただし、バグXはZバグに似ているため、Y時間かかるとは言えません。しかし、Developer Bakerにそれを見てもらうことができ、「修正に2日かかる」場合、彼がどれほど正確であるかを判断することができます。

于 2009-04-20T17:33:14.523 に答える
1

次の指標のリストをお勧めします。

  • 製品全体で現在開いている欠陥の数。
  • 反復バーンダウンチャートのメトリック：未解決のバグ/タスクの数、特定の反復で計画されている解決済みのバグ/タスクの数
  • 各製品バージョンの欠陥検出率。このメトリックは、バージョンがすでにリリースされているときにQA後に検出された欠陥と比較した、開発中に検出された欠陥とQAの比率を示します。
于 2010-08-30T05:48:30.743 に答える
1

以下は、より便利なものです。

  1. 反復ごとに検出されたクリティカルバグとメジャーバグの比率、およびそれらの解決にかかった平均時間。たとえば、CRITICALの場合は数時間、MAJORの場合は数日でターゲットを設定できます。ターゲットは、過去の数値に基づいて修正され、現実的に困難になる可能性があります。

  2. リリース時に製品に残っている主要なバグの数。製品/業界/顧客によっては、3、5、または7メジャーでリリースできる場合があります。{{CRITICAL Bugs = 0と仮定すると、受け入れられません。}}。

  3. 高優先度ライフタイム比率：すべての優先度の平均解決時間と比較したP1解決時間の比率。

  4. 再開率：CR反復で修正されたケースのうちの再開されたケースのパーセンテージ。

  5. 2日以内にコメント/回答がないCR：作成後2日以内に研究開発からの回答がないケースの割合。

  6. 重大なバグの優先度ブロッカーとクリティカルCRの平均優先度

  7. 解決されたケースと解決が無効なケースの比率| またはDUPLICATE。

Susheel Jalali

于 2012-04-16T12:59:54.590 に答える