要件の追跡可能性

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

要件の追跡可能性とは、開発プロセスの 2 つ以上のフェーズを関連付けて文書化し、その起点から前方または後方の両方にトレースする機能です。 要件の追跡可能性は、チームが要件の品質や要件の配布準備状況などのインジケーターに関する分析情報を得るのに役立ちます。 要件の追跡可能性における基本的な側面として、テスト ケース、バグ、コード変更と要件との関連付けが挙げられます。

テスト レポートの用語については、用語集を参照してください。

自動テストを実行するアジャイル チーム

アジャイル チームには次のような特性があります (ただし、これらに限定されません)

• リリース サイクルが短い
• パイプラインでの継続的なテスト
• 手動テストのフットプリントはごくわずかで、探索的テストに限定される
• 高度な自動化

次のセクションでは、アジャイル チームの品質、バグ、ソースの観点から追跡可能性について説明します。

品質の追跡可能性

ユーザー要件が品質目標を確実に満たせるように、プロジェクトの要件をテスト結果にリンクし、チームのダッシュボードで表示できます。 これにより、テスト結果を容易に行える方法で、エンドツーエンドの追跡が可能になります。 自動テストと要件をリンクするには、ビルドまたはリリースのテスト レポートにアクセスしてください。

1. ビルドまたはリリースの概要の [テスト] タブの結果セクションで、要件にリンクするテストを選択し、[リンク] を選択します。

   

2. 選択したテストにリンクする作業項目を、次のいずれかの方法で選択します。

   • 推奨される作業項目の一覧から該当する作業項目を選択します。 この一覧は、最近表示および更新された作業項目に基づいています。
   • 作業項目 ID を指定します。
   • タイトル テキストに基づいて作業項目を検索します。

   

   一覧には、要件カテゴリに属する作業項目のみが表示されます。

3. 多くの場合、チームでは、要件の追跡可能性の概要ビューをダッシュボードにピン留めします。 このために、要件の品質ウィジェットを使用します。

   

4. 必要なオプションを使用して要件の品質ウィジェットを構成し、保存します。

   • 要件クエリ: 現在のイテレーションのユーザー ストーリーなど、要件を取り込む作業項目クエリを選びます。
   • 品質データ: 要件の品質をトレースするパイプラインのステージを指定します。

   

5. チームのダッシュボードでウィジェットを表示します。 スコープ内のすべての [要件] と、テストの [合格率] と失敗したテストの数が一覧表示されます。 [失敗] のテスト数を選択すると、選択したビルドまたはリリースの [テスト] タブが開きます。 ウィジェットは、関連するテストなしで要件を追跡する場合にも役立ちます。

   

バグの追跡可能性

テストでは、ユーザーに変更を配布する信頼度が示されます。 テスト エラーでは、変更に伴う問題を通知します。 障害は、テスト対象のソースのエラー、不適切なテスト コード、環境の問題、不安定なテストなど、さまざまな理由で発生する可能性があります。 バグは、テスト エラーを追跡し、必要な改善策を講じる上でチームの説明責任を推進するための具体的な方法を提供します。 バグとテスト結果を関連付けるには、ビルドまたはリリースのテスト レポートにアクセスしてください。

1. [テスト] タブの結果セクションで、バグを作成するテストを選び、[バグ] を選択します。 複数のテスト結果を 1 つのバグにマッピングできます。 これは通常、依存サービスが利用できない、データベースの接続エラーといった問題など、障害の原因が 1 つである場合に行われます。

   

2. 作業項目を開いてバグを確認します。 エラー メッセージ、スタック トレース、コメントなどの重要な情報を含む、テスト結果の完全なコンテキストがキャプチャされます。

   

3. [テスト] タブ内で、テスト結果を示すバグをコンテキストに直接表示します。[作業項目] タブには、テスト結果でリンクされた要件も一覧表示されます。

   

4. 作業項目から、関連するテスト結果に直接移動します。 テスト ケースと特定のテスト結果の両方がバグにリンクされます。

   

5. 作業項目で、[テスト ケース] または [テスト結果] を選択して、選択したビルドまたはリリースの [テスト] ページに直接移動します。 障害のトラブルシューティングを行い、バグの分析結果を更新し、必要に応じて問題を修正するために必要な変更を加えることができます。 両方のリンクから [テスト] タブに移動しますが、既定ではそれぞれ [履歴] セクションと [デバッグ] セクションが表示されます。

   

ソースの追跡可能性

一定期間にわたって継続的に発生するテスト エラーをトラブルシューティングする場合は、最初の一連の変更 (エラーが発生した場所) までトレースし直すことが重要です。 これにより、テスト対象となる問題のあるテストやソースを特定するスコープを大幅に絞り込むことができます。 テスト エラーの最初のインスタンスを検出し、関連するコード変更までトレースするには、ビルドまたはリリースの [テスト] タブにアクセスします。

1. [テスト] タブで、分析するテスト エラーを選びます。 ビルドかリリースかに応じて、テストの [ビルドの失敗] 列か [リリースの失敗] 列を選択します。

   

2. [テスト] タブの別のインスタンスが新しいウィンドウに開き、テストで発生した連続エラーの最初のインスタンスが表示されます。

   

3. ビルドまたはリリース パイプラインに基づいてタイムラインまたはパイプライン ビューを選び、コミットされたコード変更を確認できます。 コードの変更を分析して、テスト エラーの潜在的な根本原因を特定できます。

   

計画テストを使用する従来のチーム

手動テストから継続的 (自動) テストに移行し、テストのサブセットが既に自動化されているチームでは、パイプラインの一部として、またはオンデマンドでテストを実行できます (テスト レポートを参照)。 計画テストと呼ばれる自動テストは、テスト計画のテスト ケースに関連付け、Azure Test Plans から実行できます。 関連付けられたテストは、対応する要件の品質メトリックに寄与します。

ヘルプとサポート

• トラブルシューティング ページを参照してください。
• Stack Overflow に関するアドバイスを受け取り、Developer Community を介してサポートを受ける