品質のダッシュボード (アジャイル)

品質のダッシュボードを使用して、開発中のソフトウェアの品質に関係するテスト、開発、およびビルドの各区分における進行状況の概要を確認できます。 チームは、品質のダッシュボードを使用して、製品の品質を把握し、製品の品質に関するチームのゴールをサポートする決定を行うことができます。

このダッシュボードを使用することで、テストの進行状況、ビルドの状態、バグの解決と終了の進行状況、バグの再アクティブ化率、テストされたコードの割合、およびコードの変更の傾向を確認できます。 これらの測度は、それぞれ過去 4 週間についてプロットされます。

ダッシュボードへは、チーム プロジェクト ポータルからアクセスします。 品質のダッシュボードにアクセスできるのは、ポータルが有効化され、SharePoint Server Enterprise Edition を使用するようにプロビジョニングされている場合だけです。 詳細については、「ダッシュボード」を参照してください。

このトピックの内容 ダッシュボードに表示されるデータ 品質の追跡に必要なアクティビティ 品質に関する懸案事項のトラブルシューティング 品質のダッシュボードのカスタマイズ

このダッシュボードを使用すると、次の事項を確認できます。 テストが順調に進行しているか。 チームは適切な機能をテストしているか。 チームのバグ修正は高品質であるか。 テストが古くなっていないか。 チームは十分なテストを設定しているか。 ボトルネックが発生していないか。

必要なアクセス許可

ダッシュボードを表示するには、チーム プロジェクトの SharePoint 製品に対する [読み取り] アクセス許可が割り当てられているグループに割り当てられているか、そのグループに属している必要があります。 ダッシュボードを変更、コピー、またはカスタマイズするには、チーム プロジェクトの SharePoint 製品に対する [メンバー] アクセス許可が割り当てられているグループに割り当てられているか、そのグループに属している必要があります。 詳細については、「チーム プロジェクトへのユーザーの追加」を参照してください。

Office Excel でレポートを変更するには、SQL Server Analysis Services の TfsWarehouseDataReaders セキュリティ ロールのメンバーであることが必要です。また、チーム プロジェクトの SharePoint 製品に対する [メンバー] アクセス許可が割り当てられているグループに割り当てられているか、そのグループに属している必要があります。 詳細については、「Visual Studio ALM 用データ ウェアハウスのデータベースへのアクセスの許可」を参照してください。

作業項目を表示するには、読み取りユーザー グループのメンバーであるか、または [このノードの作業項目を表示します] アクセス許可が [許可] に設定されている必要があります。 作業項目を作成または変更するには、貢献者グループのメンバーであるか、または [このノードの作業項目を編集します] のアクセス許可が [許可] に設定されている必要があります。

ダッシュボードに表示されるデータ

チーム メンバーは、品質ダッシュボードを使用して、開発している製品の全体的な品質を確認できます。 テスト成功率、バグ、およびコード チャーンがすべて同じ状況を示すのが最適な状態ですが、多くの場合、同じではありません。 相違が見つかった場合は、適切なビルドとデータ系列を綿密に調べる必要があります。 品質のダッシュボードでは、テスト結果、テストからのコード カバレッジ、コード チャーン、およびバグが集結されるので、さまざまな側面を同時に把握できます。

品質のダッシュボードに表示される Web パーツについては、次の図と表を参照してください。

注意

テスト計画の進行状況レポートは、チームがテスト ランナーおよび Microsoft Test Manager を使用して、テスト計画を作成し、テストを実行するときにのみ使用できます。

進行状況、ビルド、およびコード表 ( ～ のレポート) は、チーム プロジェクトのデータ ウェアハウスが使用できない場合には表示されません。

品質のダッシュボードに表示されるグラフの解釈、更新、またはカスタマイズの方法については、次の表に示されているトピックを参照してください。

Web パーツ	表示されるデータ	関連トピック
	過去 4 週間以内のすべてのテスト ケースのテスト結果を最後に記録された結果 ([実行しない]、[ブロック]、[失敗]、または [成功]) でグループ化した積み上げ面グラフ。	テスト計画の進行状況レポート
	過去 4 週間以内に失敗または成功したビルドの数を示す積み上げ縦棒グラフ。	ビルドの状態 Excel レポート
	過去 4 週間以内のすべてのバグの累積数を状態別にグループ化した積み上げ面グラフ。	バグの進行状況 Excel レポート
	過去 4 週間以内にチームが解決済みの状態または終了状態から再アクティブ化したバグの数を示す積み上げ面グラフ。	バグの再アクティブ化 Excel レポート
	過去 4 週間以内にビルド確認テスト (BVT: Build Verification Test) およびその他のテストでテストされたコードの割合を示す折れ線グラフ。	コード カバレッジ Excel レポート
	過去 4 週間以内にチームがビルドの前にチェックインで追加、削除、および変更したコードの行数を示す積み上げ面グラフ。	コード チャーン Excel レポート
	間近に迫っているイベントのリスト。 このリストは、SharePoint Web パーツから派生します。	該当なし
	アクティブな作業項目、解決した作業項目、および終了した作業項目の数。 作業項目のリストを開くには、それぞれの数字を選択します。 このリストは、Team System Web Access Web パーツから派生します。	該当なし
	最新のビルドおよびその状態のリスト。 詳細を表示するには、特定のビルドを選択します。 このリストは、Team System Web Access Web パーツから派生します。 凡例: : ビルドは開始されていません : ビルドは進行中です : ビルドに成功しました : ビルドに失敗しました : ビルドが停止されました : ビルドが一部成功しました	ビルドの実行、監視、管理
	最新のチェックインのリスト。 詳細を表示するには、特定のチェックインを選択します。 このリストは、Team System Web Access Web パーツから派生します。	コードの作成と保留中の変更の管理

品質の監視に必要なアクティビティ

正確で効果的な品質のダッシュボードが生成されるようにするためには、チームはこのセクションで説明するアクティビティを実行する必要があります。

テスト計画の進行状況の追跡に必要なアクティビティ

正確で効果的なテスト計画の進行状況レポートが生成されるようにするためには、チームは次のアクティビティを実行する必要があります。

• テスト ケースおよびユーザー ストーリーを定義し、テスト ケースとユーザー ストーリーの間にテスト担当者リンクを作成します。

• テスト計画を定義し、テスト ケースをテスト計画に割り当てます。

• 手動テストの場合は、テスト ケースの各検証手順の結果を、成功または失敗としてマークします。

  重要

  テスト担当者は、テスト ステップが検証テスト ステップである場合、そのことを示す状態でマークする必要があります。テスト ケース全体の結果には、テスト担当者がマークしたすべてのテスト ステップの状態が反映されます。したがって、テスト担当者がテスト ステップを失敗とマークしている場合、またはまったくマークしていない場合、テスト ケースは失敗の状態になります。

  自動テストの場合は、各テスト ケースは成功または失敗として自動的にマークされます。

• (省略可能) フィルター処理をサポートするには、イテレーション パスと区分パスを各テスト ケースに割り当てます。

  注意

  区分パスとイテレーション パスの定義方法については、「区分およびイテレーション パスの追加および変更」を参照してください。

バグの進行状況およびバグの再アクティブ化の追跡に必要なアクティビティ

正確で効果的なバグの進行状況レポートとバグの再アクティブ化レポートが生成されるようにするためには、チームは次のアクティビティを実行する必要があります。

• バグを定義します。

• チームがバグを修正し、検証して、終了または再アクティブ化したら、バグの状態を更新します。

• (省略可能) イテレーション パスおよび領域パスのフィールドでフィルター処理する場合は、各バグのイテレーション パスと領域パスを指定します。

ビルド状態、コード カバレッジ、およびコード チャーンの追跡に必要なアクティビティ

正確で効果的なビルド状態、コード カバレッジ、およびコード チャーンの各レポートが生成されるようにするためには、チーム メンバーは次のアクティビティを実行する必要があります。

• ビルド システムの設定。 Team Foundation ビルドを使用するには、ビルド システムを設定する必要があります。

  詳細については、「ビルド システムの構成と管理」を参照してください。

• ビルド定義の作成。 いくつかのビルド定義を作成し、各ビルド定義を実行して別のプラットフォームのコードを生成できます。 また、別の構成で各ビルドを実行することもできます。

  詳細については、「ビルド プロセスの定義」を参照してください。

• ビルドの一部として自動的に実行するテストの定義。 ビルド定義では、ビルドの一部としてテストを実行し、テストに失敗した場合はビルドが失敗するように定義できます。

  詳細については、「ビルド プロセスに既定のテンプレートを使用」を参照してください。

• コード カバレッジ データを収集するテストの設定。 コード カバレッジ データをレポートに表示するために、チーム メンバーはテストをインストルメントしてそのデータを収集する必要があります。

  詳細については、「ビルド プロセスでのテストの実行」を参照してください。

• ビルドの定期的な実行。 ビルドは、定期的な間隔で、またはチェックインが行われるたびに実行できます。 スケジュール トリガーを使用すると、定期的なビルドを作成できます。

  詳細については、「ビルド定義の作成または編集」および「ビルドの実行、監視、管理」を参照してください。

  注意

  チーム メンバーはビルド エクスプローラーを使用してビルドを手動で評価することができますが、この評価はビルド品質指標レポートには反映されません。ビルド評価は、ビルドの概要レポートに表示されます。詳細については、「完了したビルドの品質の評価」および「ビルドの概要レポート」を参照してください。

品質に関する懸案事項のトラブルシューティング

品質のダッシュボードによって監視できる品質に関する懸案事項の説明と、チームがこれらの懸案事項に対して講じることのできるアクションを次の表に示します。

懸案事項	確認するレポート	トラブルシューティングに関する説明
ビルドが失敗する	ビルドの状態	夜間ビルドは、ソフトウェア開発プロジェクトのハートビートです。 ビルドが正常に完了しなかった場合、またはビルド確認テスト (BVT) に合格しなかった場合、チームは問題を直ちに修正する必要があります。
テストが失敗する	テスト計画の進行状況 コード チャーン	失敗したテストおよびコード チャーンの率が高い場合、チームはソフトウェアが頻繁に失敗する理由を調べます。 原因として、初期のイテレーション サイクルで厳しすぎた開発手法またはテストを緩めたことなどがあります。
テストは成功したにもかかわらずバグの検出率が高い	テスト計画の進行状況 バグの進行状況	同じ期間に多くのテストが成功しているにもかかわらず多くのバグが検出される場合、チームは次のような可能性を調べます。 テストが現在の製品段階に対して十分に厳格ではない可能性があります。 初期のイテレーションでは、単純なテストが適しています。 ただし、製品が完成に近づくにつれて、より広範囲のシナリオおよび統合をテストで実施する必要があります。 テストが古くなっているか、誤った機能をテストしている可能性があります。 別のテスト手法を試すと、より有意義な結果が得られる場合があります。 バグが報告されているにもかかわらずテストの対象になっていません。 バグが報告されているにもかかわらずテスト ケースにリンクされていなければ、それらのバグは回帰テストの対象になりません。
テストが古くなっている	テスト計画の進行状況 コード カバレッジ コード チャーン	多くのテストが成功し、大量のコードが変更され、コード カバレッジが減少している場合、チームは、新しいコードを実行するテストを実行していない可能性があります。 テストは、コードの変更と同じ速度で開発されないため、テスト カバレッジは徐々に適さなくなっていく場合があります。
チームが解決済みバグをテスト、終了、または再アクティブ化していない	バグの進行状況	バグの進行状況レポートで解決済みバグが急増している場合、開発者がバグを解決していても、テスト担当者がそれらを検証および終了していないことを意味します。 チームは、このパターンが発生した理由を調べる必要があります。
テストが少なすぎる	テスト計画の進行状況 コード チャーン	チームが実行しているテストの数が少なく、コード チャーンが高い値を示し、コード カバレッジが期待値よりも低い場合、チームはより多くのリソースをテストに割り当てる必要がある可能性があります。 また、チームは、テスト担当者がチームの他のメンバーと同じ機能について取り組んでいるかどうかを確認する必要があります。
再アクティブ化	バグの再アクティブ化が多い	チームがバグを再アクティブ化する率が高い、または上昇している場合、テスト担当者は頻繁に開発者の修正を拒否します。 チームは、拒否された修正のやり直しに多大なリソースが割り当てられることを回避するために、これらの問題に対処する必要があります。 考えられる原因として、不適切なバグ レポート、不適切なテスト ラボ管理、過度に積極的なトリアージなどがあります。
単体テストが不適切である	コード カバレッジ コード チャーン	コード カバレッジが減少するのと同時にコード チャーンが上昇していく場合、開発者は対応する単体テストでそれに対処せずにコードをチェックインしている可能性があります。 一般的に、チームがテスト駆動開発または同様の手法を使用している場合、コード カバレッジは 100% に近づきます。 単体テストが BVT として再利用されている場合、コード カバレッジは対応するレポートに表示されます。

品質のダッシュボードのカスタマイズ

品質のダッシュボードは、次の方法でカスタマイズできます。

• 各 Excel レポートのフィルターを変更して、特定の製品区分またはイテレーションだけが表示されるようにします。

• クエリが検索する作業項目のリストを表示するカスタムのクエリ Web パーツを追加する。 たとえば、テスト ケースにリンクされていないすべてのアクティブなバグを示すクエリを追加できます。 このクエリには、報告されていても、テストでは検出されないため回帰テストの対象とならないバグの総量が示されます。

• バグの傾向や失敗の分析などの既存の Excel レポートをダッシュボードに追加します。

Office Excel でのレポートの使用とカスタマイズの方法の詳細については、Microsoft Web サイトの次のページを参照してください。

• ピボットテーブル レポートを変更する方法

• Excel Services からブックを編集または削除する

• ブックを Excel Services に発行する

• SharePoint ライブラリまたは別の Web 上の場所にファイルを保存する