エンドツーエンドの追跡可能性
Azure DevOps Services
Azure DevOps では、開発プロセスに関係するさまざまなオブジェクトをリンクできるようにすることで、エンドツーエンドの追跡可能性をサポートしています。 これらのオブジェクトには、作業項目、分岐、コミット、プル要求、ビルド、リリースが含まれます。 組み込みのレポートと分析を使用して、オブジェクトの追跡可能性をリアルタイムで監視できます。
この記事では、Azure DevOps を設定して使用する方法の詳細を説明することなく、Azure DevOps が追跡を可能にし、サポートする方法の概要について説明します。 詳細情報へのリンクは、全体を通して見つけることができます。
追跡可能性とリンク
開発ライフサイクル全体を通じて作業項目にリンクコードの変更、ビルド、リリースを追跡できます。 これにより、チームは、コード ベースの変更を確認することで、作業がどのように行われたか、バグがどのように修正されたかの監査証跡を確認できます。
次の図に示すように、Git リポジトリに使用されるリンクの種類は、Build、ビルド、ビルド、ブランチ、ブランチ、Commit、Pull Request、およびリリース ステージでのIntegrated です。
要件からブランチを作成する
製品ボードから 1 回の選択で多くのタスクを実行できます。 次の図に示すように、作業項目カード メニューを開くことで、要件から分岐を作成できます。 既定のメイン ブランチからブランチを作成するときに、名前とラベルを付けることができます。 ブランチは、 Branch リンクの種類を持つ作業項目に自動的にリンクされます。
または、作業項目フォーム ブランチを作成 を選択します。
要件から pull request を作成する
新しいブランチでコードの変更が行われると、開発者は作業項目からプル要求を作成できます。
ボードと作業項目を使用してソフトウェア開発を推進する利点もあります。 開発者は、作業時にコメントを追加することをお勧めします。これにより、行った変更とその背後にある理由を文書化するのに役立ちます。 これにより、作業項目は、コード変更の情報と履歴の豊富なソースになります。
要件に対するテストの追加と実行
テストを一連の要件にリンクし、アプリケーションが期待どおりに動作することを検証します。 ボードから、作業項目にテストを追加できます。 その後、ボードから新しいテストを実行し、テストの状態を設定できます。
ボードとのテスト統合により、チームは簡単に手動テストを開始し、Azure Test Plans によって提供される完全なテスト機能を利用できます。 ボードには、ボードからテスト ケースが作成されたとき、または要件ベースのテスト スイートがテスト 計画の下に作成されるときに、要件をサポートするために追加されたテストが表示されます。
手動テストと自動テスト
パイプラインまたはオンデマンドで自動テストを実行できます。 テスト 計画でテスト ケースにリンク、テスト プランから実行することもできます。 これにより、計画されたテストと呼ばれる自動テストを使用して、要件の品質 追跡できます。
運用環境に変更をデプロイする
コード変更をビルドしてリリースするパイプラインを定義したら、各リリース ステージへの要件のデプロイを追跡できます。 作業項目フォームから、 Deployment および Development コントロール セクションからのビルドとリリースへのリンクをすばやく開くことができます。
展開と開発のコントロール
作業項目フォームを開くと、要件が展開されているステージを確認し、リンクを選択して詳細をドリルダウンできます。 Development セクションで、要件にリンクされているブランチ、コミット、またはプル要求を開くことができます。
Deployment コントロールには、リリースされるビルドの一部である Git コミットに関連付けられている作業項目のリリース情報が表示されます。
リリース ビュー
次の図は、選択した作業項目が関連付けられているリリースが対象とする複数の環境を示しています。
リリース設定
リリース設定から表示オプションを管理します。 作業項目の展開コントロールには、作業項目にリンクされているリリースの進行状況が表示されます。 ビルドにコミットされた作業項目と、Azure Boards にデプロイ情報を送信するように設定したリリース パイプラインのリリース状態を確認できます。
要件の追跡性マトリックス
要件の追跡可能性により、要件の品質や要件を出荷する準備状況などのインジケーターに関する分析情報がチームに提供されます。 要件の追跡可能性における基本的な側面として、テスト ケース、バグ、コード変更と要件との関連付けが挙げられます。
要件追跡マトリックス (RTM) を使用すると、システムに定義されているすべての要件がテスト プロトコルでテストされます。
要件の追跡可能性レポート
要件の追跡可能性レポートは、開発プロセスのさまざまなフェーズがどのように関連し、文書化されているかを示す方法です。 チームは、要件の品質と完全性を測定し、配信の準備状況を評価するのに役立ちます。 また、要件にリンクされているコードの変更、テスト、バグ、デプロイを追跡するのにも役立ちます。
バグの追跡可能性
バグとテスト結果は、同じコンテキストの Tests タブでまとめて確認できます。 [ 作業項目 ] タブには、テスト結果にリンクされている要件も表示されます。
バグとソースの追跡可能性については、「 Requirements の追跡可能性を参照してください。
ソースの追跡可能性
ビルドまたはリリース パイプラインに基づいてタイムラインまたはパイプライン ビューを選び、コミットされたコード変更を確認できます。 コードの変更を分析して、テスト エラーの潜在的な根本原因を特定できます。
テスト分析
ビルドとリリースのテスト分析、要件の品質の追跡、およびテストエラーの詳細については、「 Test Analyticsを参照してください。