バグの傾向レポート
バグの傾向レポートを使用すると、チームがバグを発見してから解決するまでの時間の速度を追跡できます。 このレポートでは、時間の経過と共に、報告、解決、および終了したバグのローリング平均または移動平均を示します。 大規模チームまたは大量のバグを管理する場合、バグの傾向レポートを毎週監視することで、チームがバグを適切に発見、解決、および終了できているかどうかを把握できます。
レポートへのアクセス、レポートの更新、またはレポートの管理の方法については、「レポート (アジャイル)」を参照してください。
注意
このレポートを使用するには、チーム プロジェクトを含むチーム プロジェクト コレクションが SQL Server Reporting Services でプロビジョニングされている必要があります。このレポートは、チーム エクスプローラーを開いて、チーム プロジェクト ノードを展開したときに .gif "レポート"){kind=icon}
[レポート] が表示されない場合は使用できません。
このトピックの内容
|
このレポートを使用すると、次の事項を確認できます。
|
必要なアクセス許可
レポートを表示するには、SQL Server Reporting Services で閲覧者ロールが割り当てられているグループに割り当てられているか、そのグループに属している必要があります。 詳細については、「チーム プロジェクトへのユーザーの追加」または「アクセス許可の管理」を参照してください。
レポートのデータ
バグの傾向レポートでは、指定するフィルターに基づいてチームが開始、解決、および終了するバグ数のローリング平均を計算します。 ローリング平均は、計算する日の前日までの 7 日間を対象にしています。 つまり、レポートは、計算日の前日までの 7 日間ごとに各状態のバグ数の平均を求め、次に結果を 7 で割ります。 データは、データ ウェアハウスから派生します。
バグの傾向レポートの例を次の図に示します。
.png "バグの傾向レポートの例")
このレポートは最大 3 つの折れ線グラフを表示し、各グラフはアクティブ化、解決、および終了したバグ数のローリング平均を表します。
レポートは、次の方法でフィルター処理できます。
レポートの開始日と終了日を変更します。
イテレーション パス、領域パス、バグの状態、優先度、または重大度を指定して、レポートに反映させるバグをフィルター処理します。
詳細については、このトピックの「レポートのフィルター処理」を参照してください。
バグの追跡に必要なアクティビティ
有益で正確なバグの傾向レポートを作成するには、チームは次のアクティビティを実行する必要があります。
バグを定義して、バグのイテレーション パスと領域パスを指定します。
各バグの修正、検証、および終了時に、そのバグの [状態] を更新します。
トリアージ中に各バグの [優先度] と [重大度] を指定します。
トリアージ ブックを使用すると、バグのイテレーション、区分、状態、優先度、および重大度を迅速に更新できます。 詳細については、「トリアージ ブック」を参照してください。
スプリントまたはイテレーションの期間の設定
現在のイテレーションに対するバグの傾向を把握するには、現在のイテレーション サイクルに合わせてレポートの開始日と終了日を設定する必要があります。
イテレーションの期間を変更するには
[イテレーション開始 (日付)] または [イテレーション終了 (日付)] の横にある予定表アイコンをクリックし、日付をクリックします。
[レポートの表示] をクリックします。
レポートの解釈
バグ率は、製品開発サイクルの時点によって変わるということを理解しておく必要があります。 一連のイテレーションで見つかるバグの件数は、後半よりも前半の方が少なくなります。 また、製品サイクルの終了に近いイテレーションでは、より多くのバグが終了されます。
現在のチーム プロジェクトのすべてのアクティビティ、およびバグの状態レポートやバグの再アクティブ化レポートが提供する他のすべての測度にバグ率を関連付けて確認することで、バグ率を最適に解釈することができます。 たとえば、チームは、不適切なコード内や新規に統合されたコード内で、または強化されたテストの実行時やバグ バッシュなどの例外イベント発生時に、バグを特にすばやく発見できる場合があります。 一方で、高品質の製品の場合や効果の薄いテストを実行している場合は、バグの発見は難しくなります。 コード カバレッジ、コード チャーン、およびテスト率の測度を使用すると、バグの傾向が示す意味をより詳細に理解できます。
製品サイクルの終了に向けて製品が安定するにつれて、チームのバグ発見頻度は少なくなります。
バグの傾向レポートでは、次の表の左側の列に記載された指標が 1 つ以上表示される場合があります。 区分の右側の列の質問事項を確認して、より詳細に対処できます。
指標 |
確認事項 |
|---|---|
チームが連続する期間に同じ数のバグを発見している。 チームが同じ数のバグを連続した週または連続したイテレーションで発見する場合は、根本的な原因を究明する必要があります。 テスト サイクルの早い時期に実施したテストの厳密さやレベルが不足していたために、多くのバグを発見できなかった可能性があります。 この状況は、一連のイテレーションの早い時期に起こることが想定されます。 ただし、製品が完成に近づくにつれて、テストではより広範囲のシナリオや統合を実行する必要があります。 |
|
チームが各期間で多くのバグを発見している。 粗雑なコードや新規に統合されたコード内で、または効果的なテストの実行時やバグ バッシュなどの特定のイベント発生時に、バグを簡単に発見できる場合があります。 |
|
チームが各期間でほとんどバグを発見していない。 チームは、高品質のソリューションの場合や効果の薄いテストを実行している場合は、バグの発見に苦労する場合があります。 |
|
チームが各期間で多くのバグを解決している。 高い解決率は一般に、チームが正常な進行状況で作業を進めていることを示します。 |
|
チームはバグを迅速に解決しているが、バグが終了されない。 バグ修正の検証に割り当てられるチーム メンバーの配分が不足しているか、別の事項を優先するために、これらのメンバーが解決済みバグの終了に専念できていない場合があります。 |
|
正常なレポート
正常なバグの傾向レポートでは、チームのバグの発見数は、開発サイクルの開始時により多く、リリースの終了に向かってより少なくなります。 プロジェクトの終了に向けて、チームはより多くのバグを解決し、終了する必要があります。
チームがバグを発見する速度よりも解決する速度が速くなると、アクティブなバグの数が減少し始めます。 バグの発見が少なくなることは、製品が安定してきたことを示します。
問題のあるレポート
問題のあるバグの傾向レポートでは、出荷日が近づくにつれてチームがバグを発見する速度が速くなり、バグを解決する速度が遅くなる場合があります。 この状況では、バグが修正されないためチームのバグのバックログが増え続けるので、原因を究明する必要があります。 次の図は、多くのバグを発見しているにもかかわらず、バグの解決が遅れ、さらにバグの終了が遅れているチームのレポート示しています。
.png "問題のあるバグの傾向レポート")
レポートのフィルター処理と表示の変更
バグの傾向レポートは、次の方法でフィルター処理または表示変更できます。
レポートの開始日と終了日を変更します。
イテレーション パス、領域パス、状態、優先度、または重大度を指定して、レポートに反映させるバグをフィルター処理します。
使用できるフィルターを次の図に示します。
.png "バグの傾向レポートのフィルター")
レポートに反映させるバグをフィルター処理するには
次の操作のいずれか、または両方を実行します。
[イテレーション] ボックスと [区分] ボックスで、含めるイテレーションまたは製品区分のチェック ボックスをオンにします。
[状態] ボックス、[優先度] ボックス、または [重大度] ボックスの一覧で、含める各状態、優先度、および重大度のチェック ボックスをオンにします。
[レポートの表示] をクリックします。