失敗の分析 Excel レポート

[アーティクル]
08/09/2011

失敗の分析レポートを使用すると、検出された回帰の数をテストチームが監視するのに役立ちます。回帰とは、以前のバージョンのソフトウェアでは出現せず、テスト対象のバージョンのソフトウェアでは出現したバグです。回帰テストを実行するチームは、新しいバージョンのソフトウェアにのみ出現するバグを検出することに重点を置きます。失敗の分析レポートには、過去 4 週間以内の、以前は合格し、今回は失敗した各テストケースの構成の数が示されます。

このレポートは、チームがテスト計画を作成して、Microsoft テストマネージャーでテストを開始した後にのみ使用できます。テストスイートおよびテスト計画を定義する方法の詳細については、「テスト計画の使用によるテスト作業の定義」を参照してください。このレポートにアクセスする方法については、「Excel レポート (アジャイル)」を参照してください。

注意

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

このトピックの内容

レポートのデータ
レポートの解釈
レポートの更新とカスタマイズ

関連トピック

注意

チームは、テストケースを使用して、テストランナーおよび Microsoft テストマネージャーで実行および管理できる手動テストおよび自動テストの両方を定義します。Microsoft テストマネージャーを使用すると、テストケースだけでなく、プロジェクトのテストをサポートするテストスイートとテスト構成を作成することもできます。テスト構成を使用して、テストケースおよびテストスイートを実行する方法を定義できます。テスト計画で複数のテストケースをテストスイートの階層構造にまとめて、テストケースをグループ化できます。テストスイートを作成することで、一連のテストケースをグループとして実行できます。詳細については、「テスト計画の使用によるテスト作業の定義」を参照してください。

必要なアクセス許可

レポートを表示するには、チームプロジェクトの SharePoint 製品に対する [読み取り] アクセス許可が割り当てられているグループに割り当てられているか、そのグループに属している必要があります。

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

レポートのデータ

失敗の分析レポートは、過去 4 週間以内のすべての構成のテストケースで失敗に終わったすべての結果の累積数を、積み上げ面グラフで示します。失敗の種類には、"新しい問題"、"既知の問題"、および "回帰" があります。

失敗の分析 Excel レポート

このレポートは、データウェアハウスに格納されている過去 4 週間以内のテスト結果データを示すピボットグラフに基づいています。

システムは、テストケースが実行された各構成を検証し、テストケースの同じ構成の過去の結果を識別しようと試みます。テストケースまたは構成に割り当てられる失敗の種類は、次の基準に基づいて決定されます。

回帰: 直前の結果が "成功" だった場合。
新しい問題: 直前の結果が見つからない場合。
既知の問題: 直前の結果が "失敗" だった場合。

回帰の監視に必要なアクティビティ

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

テストケースとテスト計画を定義し、テストケースをテスト計画に割り当てます。
手動テストの場合は、テストケースの各検証手順の結果を、成功または失敗としてマークします。

重要

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

自動テストの場合、各テストケースは成功または失敗として自動的にマークされます。
(省略可能) フィルター処理をサポートするには、イテレーション パスと区分パスを各テストケースに割り当てます。

レポートの解釈

失敗の分析レポートは、現在製品開発サイクルのどの段階であるかに応じて異なるということを理解しておく必要があります。イテレーションの初期の段階では、回帰アクティビティは少ししかないか、まったくありません。開発サイクルの後半になると、いくつかの回帰があることを想定しておく必要があります。具体的には、このレポートをレビューして、次の事項を確認する必要があります。

全体でいくつのテストが回帰しているか。
チームは回帰または失敗したテストの総数を想定の範囲内またはチームのゴール内に抑えているか。
チームは問題を特定してからすぐにその問題に対処しているか。既知の問題に適時に対処しているか。

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

また、最新のビルドの状態、バグの状態、およびコードチャーンをチェックして、これらの要因の測度によってテスト動作の線の変化を説明できないかどうかを判断することをお勧めします。

レポートの更新とカスタマイズ

失敗の分析レポートは、Office Excel で開いて、ピボットテーブルレポートのフィルターオプションを変更することで更新できます。このレポートは、次の表に示すその他のビューをサポートするようにカスタマイズできます。

ビュー	アクション
イテレーションの失敗の分析	Iteration のフィルターを変更します (既定 = すべて)。
製品区分の失敗の分析	Area のフィルターを変更します (既定 = すべて)。
特定のテスト計画またはテスト計画のスイートに対する失敗の分析	Test Plan のフィルターを追加します (既定 = すべて)。
過去 6 週間、8 週間、またはそれ以上の期間内の失敗の分析	列の [ピボットテーブルのフィールドリスト] で、@@Last 4 weeks@@ を別の Set に置き換えます。