テストのダッシュボード (アジャイル)

テストのダッシュボードを使用して、テスト動作の監視、進行状況の報告、テスト カバレッジの矛盾点の検出、および追加の調査が必要なテスト区分の特定を行うことができます。 このダッシュボードは、5 つのレポートを表示して、過去 4 週間以内に発生したテストに関する情報を提供します。

注意

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

このトピックの内容

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

  • テストの追跡に必要なアクティビティ

  • テストの進行状況の監視

  • テストの矛盾点の特定

  • テストの失敗と回帰の監視

  • テストのダッシュボードのカスタマイズ

このダッシュボードを使用すると、次の事項を確認できます。

  • テスト ケースの作成が順調に進んでいるか。

  • チームはすべてのユーザー ストーリーのテスト ケースを定義したか。

  • テスト ケースの結果が成功、失敗、およびブロックになっている割合はどれぐらいか。

  • テスト失敗の測度によって、詳細な調査が必要な問題が示されているか。

  • 昨日のナイト ビルドはどのような状態であるか。

  • 最新のチェックインは何であるか。

必要なアクセス許可

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

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

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

テストのダッシュボードに表示されるデータ

テストのダッシュボードを使用すると、ユーザー ストーリーのテストにおけるチームの進行状況を把握できます。 具体的には、このダッシュボードには、次の図と表で説明する Web パーツが表示されます。

テストの進行状況ダッシュボードの Web パーツ

注意

テスト計画の進行状況テスト ケース準備ユーザー ストーリーのテストの状態、およびテスト動作の各レポートを使用できるのは、チームがテスト計画を作成し、テスト ランナーと Microsoft テスト マネージャー を使ってテストを実行する場合のみです。 テスト スイートおよびテスト計画を定義する方法の詳細については、「テスト スイートを使用したテスト ケースの整理」を参照してください。

バーンダウン グラフ、進行状況グラフ、傾向表、およびレポート 手順 1.手順 5. は、チーム プロジェクトの Analysis Services をホストするサーバーが使用できない場合には表示されません。

Web パーツ

表示されるデータ

関連トピック

手順 1.

過去 4 週間以内のすべてのテスト ケースのテスト結果を最後に記録された結果でグループ化した積み上げ面グラフ。 結果には、実行しないブロック失敗、および成功があります。

テスト計画の進行状況 Excel レポート

テスト計画の進行状況レポート

手順 2.

過去 4 週間以内にデザインまたは準備完了の状態であったテスト ケースの数を示す積み上げ面グラフ。

テスト ケース準備 Excel レポート

テスト ケース準備レポート

手順 3.

各ユーザー ストーリーに定義されているテスト ケースとテスト構成の組み合わせごとのテスト結果の数を示す横向きの横棒グラフ。 グラフでは、最後のテストの実行に基づいてテスト結果がグループ化されます。グループの内訳は、成功 (緑)、失敗 (赤)、ブロック (紫)、または実行なし (灰) です。

ユーザー ストーリー テスト状態 Excel レポート

ユーザー ストーリー テスト状態 Excel レポート (アジャイル)

手順 4.

過去 4 週間以内に実行された手動テスト ケースのすべての実行結果の累積数を示す折れ線グラフ。

テスト動作 Excel レポート

テスト動作 Excel レポート

手順 5.

過去 4 週間以内に失敗に終わったすべてのテスト ケースの結果の累積数を失敗の種類を基準として並べ替えた積み上げ面グラフ。 失敗の種類には、回帰新しい問題、および既知の問題があります。

失敗の分析 Excel レポート

失敗の分析 Excel レポート

手順 6.

間近に迫っているイベントのリスト。 このリストは、SharePoint Web パーツから派生します。

インポート イベント Web パーツ

該当なし

手順 7.

アクティブな作業項目、解決した作業項目、および終了した作業項目の数。 それぞれの数字をクリックして、作業項目のリストを開くことができます。 このリストは、Team System Web Access Web パーツから派生します。

プロジェクトの作業項目 Web パーツ

作業項目とワークフロー (アジャイル)

9

最新のビルドおよびそのビルド状態のリスト。 特定のビルドをクリックすることで、詳細を表示できます。 このリストは、Team System Web Access Web パーツから派生します。

最新ビルド Web パーツ

凡例:

進行中のビルド: ビルドは進行中です

開始していないビルド: ビルドは開始されていません

成功したビルド: ビルドに成功しました

失敗したビルド: ビルドに失敗しました

停止したビルド: ビルドが停止されました

一部成功したビルド: ビルドが一部成功しました

完了したビルドの管理と表示

10

最新のチェックインのリスト。 特定のチェックインをクリックすることで、詳細を表示できます。 このリストは、Team System Web Access Web パーツから派生します。

最新チェックイン Web パーツ

[チェックイン] ウィンドウと [保留中の変更] ウィンドウの使用

テストの追跡に必要なアクティビティ

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

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

  • テスト計画を定義し、テスト ケースをテスト計画に割り当てます。 詳細については、「テスト計画の使用によるテスト作業の定義」を参照してください。

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

    重要

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

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

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

テストの進行状況の監視

テストのダッシュボードの最初の 3 つのレポートを使用して、テストの進行状況を監視し、次の表に示す事項を確認できます。

レポート

確認できる事項

メモ

テスト ケース準備

  • テスト チームが定義したテスト ケースはいくつあるか。

  • 現時点で実行の準備ができているテスト ケースはいくつあるか。

  • チームがこれからまだ作成およびレビューする必要があるテスト ケースはいくつあるか。

  • テスト ケースの全体的な数は、チームが実装しているユーザー ストーリーの数に対して十分であるか。

  • 現時点でテスト チームが実行できるテスト ケースの割合はどれぐらいか。

  • イテレーションの終わりまでにすべてのテスト ケースを準備できるかどうか。

  • 正常な進行状況では、チームがデザイン状態から準備状態に移行しているテスト ケースの数が安定的に増加していることが示されます。

  • 問題のある進行状況では、実行準備状態にあるテスト ケースがまったくないか、またはわずかであることが示されます。

    すべてのテスト ケースが長期間デザイン状態にある場合は、進行を妨げている問題がある可能性があります。 進行を妨げている原因を調査します。

  • テストの矛盾点が出現する可能性が高いのは、テスト ケースの数が十分ではないと考えられる場合です。

    プロジェクトに対して定義されているテスト ケースの数は、チームが実装しているユーザー ストーリーの数と同じかそれ以上である必要があります。 そうでなければ、テスト ケースの数が十分ではないと考えられます。

テスト計画の進行状況

  • 成功しているテスト ケースはいくつあるか。

  • 失敗しているテスト ケースはいくつあるか。

  • ブロックされているテスト ケースはいくつあるか。

  • 一度も実行されていないテスト ケースはいくつあるか。

  • すべてのテスト計画にわたって成功しているテスト ケースの割合はどれぐらいか。

  • チームはどの程度のテストを完了しているか。

  • チームがテストを時間どおりに完了できるか。

  • 開発サイクルが進むと、成功するテスト ケースの数が増加し、それ以外の状態のテスト ケースの数は減少します。

  • 失敗するテスト ケースの数が多すぎると、問題のある進行状況となります。 製品サイクルの時点によっては、多数のテスト ケースが失敗している理由を調査する必要があります。

  • 失敗しているテスト ケースの数または一度も実行されていないテスト ケースの数に変化がない場合は、各区分に影響を与えている具体的な原因を調査する必要があります。

ユーザー ストーリーのテストの状態

  • テスト ケースはユーザー ストーリーごとに実行されているか。

  • テスト ケースがブロックされているか実行されていない場合、チームは作業を妨げる問題を把握して、それらの問題に対処しているか。

  • 正常な進行状況では、各ユーザー ストーリーのほとんどのテスト ケースが成功していることが示されます。

  • 問題のある進行状況では、特定のユーザー ストーリーのテスト ケースで実行しないブロック、または失敗の各状態が多すぎることが示されます。 ユーザー ストーリーに対して定義されているテスト ケースの成功を妨げている原因を調査する必要があります。

テストの矛盾点の特定

ユーザー ストーリーのテストの状態レポートを使用して、すべてのコードがテストの対象になっているかどうかを判断し、次の事項を確認できます。

  • テスト ケースの総数が少ないのはどのユーザー ストーリーであるか。

  • ブロックされているまたは一度も実行されていないテスト ケースの総数が多いのはどのユーザー ストーリーであるか。

  • 各ユーザー ストーリーのテスト ケース カバレッジは予期したとおりであるか。

  • テストの失敗率が高いのはどのユーザー ストーリーであるか。

  • ユーザー ストーリーごとに定義されているテスト ケースの平均的な数はどれくらいか。

テストの失敗と回帰の監視

テストの失敗を監視することで、コードの問題をすばやく特定して対処できます。 テストのダッシュボードの最後の 2 つのレポートを使用することで、失敗しているテストの数をより的確に把握できます。

レポート

確認できる事項

メモ

手動テスト動作

  • チームが一度も実行しなかったテストの数は減少しているか。

  • チームはブロックされているテストの全体的な数を最小限に抑えているか。

  • 失敗するテストの数は時間の経過と共に減少しているか。

  • 成功するテストの数は増加しているか。

  • テスト動作に説明できないスパイクが含まれているか。

手動テスト動作レポートには、各テスト構成およびすべてのテスト計画について実行されたテスト ケースの結果が示されます。 スパイクの発生は、チームがチェックインしているテスト動作またはコード品質の問題を早期に示す徴候である場合があります。

最新のビルド、バグの状態、およびコード チャーンの測度をチェックして、これらのいずれかの測度で変化の説明ができないかどうかを判断する必要があります。

テスト失敗分析

  • いくつのテストが回帰しているか。

  • チームは回帰または失敗したテストの総数を想定の範囲内またはチームのゴール内に抑えているか。

  • 問題が既知の問題であると特定された場合に、チームはその問題に適時に対処しているか。

正常なテスト失敗分析レポートには、適度な数の新しい問題、既知の問題、および回帰が示されます。 これらの区分でスパイクが発生した場合、チームはさらに詳しく調査する必要があります。 スパイクの発生は、チームがチェックインしているテスト動作またはコード品質のいずれかの問題を示している可能性があります。

また、最新のビルド、バグの状態、およびコード チャーンの測度をチェックして、これらのいずれかの測度で変化の説明ができないかどうかを判断する必要があります。

テストのダッシュボードのカスタマイズ

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

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

  • 手動テスト動作レポートのフィルター処理は、Office Excel で行うか (特定のテスト計画の場合)、手動または自動のテスト ケースで行います。

  • バグの状態コード チャーンコード カバレッジなどの既存の Excel レポートをダッシュボードに追加します。

  • チームの特定のメンバー別に進行状況を表示するレポートを作成して、Office Excel に追加します。 例については、「バグ (割り当て順) Excel レポート」を参照してください。

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

参照

概念

テスト計画の使用によるテスト作業の定義

テスト ランナーを使用した手動テストの実行

自動テストの実行

テスト ケース (アジャイル)

ユーザー ストーリー (アジャイル)

テスト ケース準備レポート

テスト計画の進行状況レポート

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

その他の技術情報

成果物 (アジャイル)