要件の追跡可能性

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

   

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

手動テストから継続的な自動テストに移行し、既に自動化されているテストのサブセットを持つチームは、パイプラインの一部として、またはオンデマンドで実行できます。 計画されたテスト、つまり「自動テスト」は、テスト計画内のテスト ケースに関連付け、Azure テスト計画から実行できます。 関連付けられたテストは、対応する要件の品質メトリックに寄与します。

ヘルプとサポート

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