Azure Boards でソフトウェアのバグを定義、キャプチャ、トリアージ、管理する
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
コード内の欠陥をどのように追跡し、管理していますか。 高品質のソフトウェアを配置するため、どのようにして、ソフトウェアの問題と顧客からのフィードバックに、速やかに対応していますか。 新機能の開発を順調に進め、技術的負債に対処するにはどうすればよいのでしょうか。
少なくとも、ソフトウェアの問題をキャプチャし、優先順位を付け、チーム メンバーに割り当て、進行状況を追跡する方法が必要です。 アジャイル プラクティスに合った方法でコードの欠陥を管理する必要があります。
これらのシナリオをサポートするため、Azure Boards には、コードの欠陥を追跡するために、バグという名前の特定の作業項目の種類が用意されています。 バグ作業項目は、他の作業項目の種類のすべての標準機能に加えて、さらにいくつかの機能を備えています。 標準機能の概要については、「作業項目と作業項目の種類の概要」を参照してください。
バグにより、以下の追加機能も提供されます。
- 各チームがバグを追跡する方法を選択するためのオプション
- バグをキャプチャするためのテスト ツール
- ビルド、リリース、テストにリンクされているバグを追跡するための Azure DevOps 全体の組み込み統合
Note
バグの作業項目の種類は、Basic プロセスでは使用できません。 基本プロセスでは、バグはイシューとして追跡されます。これは、Azure DevOps Services または Azure DevOps Server 2019.1 以降のバージョンから新しいプロジェクトを作成するときに使用できます。
前提条件
Project access: project メンバーになります。
アクセス許可:
- 作業項目を表示、フォロー、編集するには、このノードの作業項目を表示しこのノードの作業項目を編集権限を Allow に設定します。 デフォルトでは、 Contributors グループにこれらの権限が与えられます。 詳細については、「作業追跡権限を設定する」を参照してください。
作業項目にタグを追加するには、プロジェクト レベルの 新しいタグ定義の作成 権限を Allow に設定します。 デフォルトでは、 Contributors グループにこの権限が与えられます。
アクセス レベル:
- 作業項目に新しいタグを追加したり、pull request を表示またはフォローしたりするには、少なくとも Basic アクセス権を持ちます。
- 作業項目を表示またはフォローするには、少なくとも Stakeholder アクセス権を持つ必要があります。 詳細については、「アクセス レベルについて」を参照してください。
- Readers グループのメンバーを含むすべてのプロジェクト メンバーは、作業項目を含む電子メールを送信できます。
Note
- ディスカッションに貢献し、進捗状況を確認するメンバーにStakeholder アクセス権を付与します。 これらは通常、コードには貢献しないが、作業項目、バックログ、ボード、ダッシュボードを表示したいメンバーです。
- 利害関係者 アクセス レベルにより、アクセス許可が明示的に設定されている場合でも、新しいタグを追加することはできません。 詳細については、「利害関係者アクセスクイック リファレンス」を参照してください。
ヒント
バグを報告するには、ユーザーが利害関係者以上のアクセス権を持っている必要があります。 バグを追加するエリア パスに対して、ユーザーの [このノードの作業項目を編集する] アクセス許可が [許可] に設定されている必要があります。 詳細については、「作業追跡権限を設定する」を参照してください
バグ作業項目の種類
次の図は、スクラム プロセスのバグ作業項目の種類を示したものです。 アジャイルおよび Capability Maturity Model Integration (CMMI) プロセスのバグ作業項目の種類でも、同様の情報が追跡されます。 これは、要件と共にプロダクト バックログに表示されるか、タスクと共にタスクボードに表示されます。
Note
Web ポータルに表示される画像は、この記事の画像と異なる場合があります。 それらの違いは、Web アプリに対して行われた更新、自分または管理者が有効にしたオプション、プロジェクトの作成時に選択されたプロセス (アジャイル、基本、スクラム、CMMI) に起因します。 基本プロセスは、 Azure DevOps Server 2019 Update 1 以降のバージョンで使用できます。
バグに固有のフィールド
バグ作業項目の種類では、バグ固有のフィールドがいくつか使用されます。 最初の問題と進行中の検出の両方をキャプチャするには、次の表に示すフィールドを使います。 能力成熟度モデル統合 (CMMI) プロセスで定義されているバグに固有のフィールドについては、 バグ、イシュー、リスクのフィールド リファレンスに関する記事をご覧ください。 その他のすべてのフィールドの詳細については、「作業項目フィールドのインデックス」を参照してください。
フィールド、グループ、またはタブ
使用方法
再現するための手順 (フレンドリ名 = 再現手順)
他のチーム メンバーがコードの欠陥を完全に理解できるよう、十分な情報をキャプチャするために使います。 バグの検出や再現に必要な操作と、予想される動作が含まれます。
バグおよび適用するテストに関連するソフトウェアとシステム構成に関する情報。 テスト ツールを使ってバグを作成すると、 [システム情報] と [発見されたビルド] フィールドは自動的に入力されます。 これらのフィールドは、バグが発生したソフトウェア環境とビルドに関する情報を指定します。 詳細については、「異なる構成のテスト」を参照してください。
バグを閉じる前に満たす条件を指定します。 作業を始める前に、顧客の受け入れ基準をできる限り明確に説明します。 チームは、この基準を受け入れテストの基礎として使用し、項目が正常に完了したかどうかを評価する必要があります。
バグを修正するコードを組み込むビルドの名前を指定します。 このフィールドは、バグを解決するときに指定する必要があります。
オンプレミスの Azure DevOps の場合、実行が完了したすべてのビルドのドロップダウン メニューにアクセスするには、[ビルドで検出] および [ビルドに統合] の FIELD 定義を更新して、グローバル リストを参照できます。 グローバル リストは、実行するビルドごとに自動的に更新されます。 詳細については、 ビルドとテストの統合フィールドに基づくクエリに関する記事をご覧ください。
ビルド番号を定義する方法については、「クラシック パイプラインの構成」を参照してください。
優先度1
- 1: 製品が出荷される前に作業項目を正しく解決し、すぐに対処する必要があります。
- 2: 製品が出荷される前に作業項目を正しく解決する必要がありますが、すぐに対処する必要はありません。
- 3: 作業項目の解決は、リソース、時間、リスクに基づき、必要に応じて行います。
重大度1
プロジェクトまたはソフトウェア システムに対するバグまたは作業項目の影響に関する主観的な評価。 たとえば、ユーザー インターフェイス内のリモート リンク (あまり生じない) によってアプリケーションまたは Web ページがクラッシュする場合 (重大なカスタマー エクスペリエンス)、"重大度 = 2 - 高" および "優先度 = 3" を指定することがあります。 使用できる値と推奨されるガイドラインは次のとおりです。
- 1 - 重大: 修正する必要があります。 1 つ以上のシステム コンポーネントまたは完全なシステムの終了を引き起こす、または広範なデータ破損を引き起こす欠陥。 必要な結果を得るために受け入れられる代替方法はありません。
- 2 - 高: 修正を検討します。 1 つ以上のシステム コンポーネントまたは完全なシステムの終了を引き起こす、または広範なデータ破損を引き起こす欠陥。 必要な結果を得るために、受け入れられる代替方法は存在します。
- 3 - 中: (既定値) システムが正しくない、不完全な、または一貫性のない結果を生成する原因となる欠陥。
- 4 - 低: 必要な結果を得るための受け入れられる回避策がある、軽微または表面的な欠陥。
[配置] コントロールは、作業項目を含むリリースへのリンクと表示をサポートします。 このコントロールを使用するには、リリースの設定を有効にする必要があります。 詳細については、この記事で後述する「作業項目をリリースにリンクする」をご覧ください。
[開発] コントロールは、開発オブジェクトへのリンクとリンクの表示をサポートします。 これらのオブジェクトには、Git コミットと pull request、または TFVC 変更セットとバージョン管理された項目が含まれます。 作業項目からのリンク、またはコミット、pull request、またはその他の開発オブジェクトからのリンクを定義できます。 詳細については、この記事で後述する「作業項目を開発にリンクする」をご覧ください。
メモ
1 メニューの選択または候補リストの変更については、「作業追跡エクスペリエンスをカスタマイズする」をご覧ください。 カスタマイズ方法は、プロジェクトで使われているプロセス モデルによって異なります。
チームがバグを追跡する方法を選択する
チームは、要件またはタスクとしてバグを追跡できます。 チームの選択をサポートするには、次の要因を検討します。
- チームのサイズ。 小規模なチームは、要件としてバグを追跡することで、作業量を増やさないでおくことができます。
- 作業の追跡に関する組織の要件。 時間を追跡する必要があるチームは、タスクとしてバグを追跡することを選択します。
- チームの作業の整理。 チームがプロダクト バックログを利用して作業に優先順位を付け、バグを追加する場合は、要件としてバグを追跡します。
- チームが使用するツール ([計画] ペイン、ベロシティ グラフ、予測、ロールアップ、配信計画など)。 タスクとしてバグを追跡すると、これらのツールの一部を使用できません。
次の表は、バグの追跡に関するチームの 3 つのオプションをまとめたものです。 チームのオプションの詳細と設定については、「バックログとボードにバグを表示する」をご覧ください。
オプション
以下のことが必要なときに選択
バグを要件として追跡する
- 要件と共にバグの優先順位 (スタック順位) を決める
- 予測のためにバグの作業量を見積もる
- ボード上のバグステータスを更新
- ベロシティ グラフ と 累積フロー ダイアグラムにバグを含める
- スプリント計画をサポートするために予測ツールを使用できるようにしておく
- バグを [計画] ペインにドラッグして、バグをスプリントに割り当てる
- [デリバリー計画] でバグを確認する
Note
- バグは要件カテゴリに割り当てられます
タスクとしてバグを追跡する
- タスクと同じようにバグの作業を見積もる
- スプリントのタスクボードでバグの状態を更新する
- バグを子項目として要件にリンクする
- バグを [計画] ペインにドラッグして、バグをスプリントに割り当てる
Note
- バグはタスク カテゴリに割り当てられます
- ユーザー ストーリー (アジャイル)、プロダクト バックログ項目 (スクラム)、または要件 (CMMI) は、バグの自然な親作業項目の種類です
- バグは [デリバリー計画] に表示されません
バックログまたはボードにバグを表示しない
- クエリを使用してバグを管理する
Note
- バグはバグ カテゴリに関連付けられ、バックログまたはボードには表示されません
- バグは、バックログ、ボード、スプリント バックログ、タスクボード、またはデリバリー計画に表示されません
- バグを [計画] ペインにドラッグして、スプリントにバグを割り当てることはできません
作業項目の種類をカスタマイズする
バグやその他の作業項目の種類をカスタマイズできます。 または、カスタムの種類を作成して、ソフトウェアの問題や顧客からのフィードバックを追跡します。 すべての種類の作業項目で、次の要素をカスタマイズできます。
- カスタム フィールドを追加または削除する
- 作業項目フォームにカスタム コントロールまたはカスタム タブを追加する
- ワークフローの状態をカスタマイズする
- 条件付きルールを追加する
- 作業項目が表示されるバックログ レベルを選択する
プロセスをカスタマイズする前に、「Azure Boards の構成とカスタマイズについて」を確認することをお勧めします。
特定のプロセスのカスタマイズについては、 継承プロセスのカスタマイズに関する記事をご覧ください。
特定のプロセスのカスタマイズについては、 継承プロセスのカスタマイズ または オンプレミス XML プロセス モデルのカスタマイズに関する記事をご覧ください。
バグを追加またはキャプチャする
複数の異なる Azure DevOps ツールでバグを定義できます。 これらのツールには、バックログ、ボード、テスト ツールが含まれます。
ヒント
既定では、バグを作成するときに必要なフィールドは [タイトル] フィールドだけです。 Azure Boards を使ってユーザー ストーリーやプロダクト バックログ項目を追加するのと同じ方法で、バグを追加できます。 一部のフィールドを必須にするには、状態の変更に基づく条件付きルールを追加します。 詳細については、「作業項目の種類にルールを追加する」を参照してください。
バックログまたはボードからバグを追加する
チームが 要件を使用してバグを管理する ことを選択した場合は、製品バックログまたはボードからバグを定義できます。 詳細については、「プロダクト バックログを作成する」または「ボードを使う」を参照してください。
プロダクト バックログからバグを追加する
ボードからバグを追加する
ヒント
製品バックログまたはボードからバグを追加すると、チームに定義されているデフォルトのエリア パスとイテレーション パスがバグに自動的に割り当てられます。 詳細については、「バックログとボードによって参照されるチームの既定値」をご覧ください。
スプリント バックログまたはタスクボードからバグを追加する
チームが タスクを使用してバグを管理することを選択した場合は、ボード、製品バックログ、スプリント バックログ、またはスプリント タスクボードからバグを定義できます。 プロダクト バックログ作業項目に子としてバグを追加します。
スプリント バックログからリンクされた子バグを追加する
スプリント バックログにタスクを追加するのと同じ方法でバグを追加します。 詳細については、 バックログ項目へのタスクの追加に関する記事をご覧ください。
ボードからリンクされた子バグを追加する
バックログ項目にタスクを追加するのと同じ方法でバグを追加します。 詳細については、 タスクまたは子項目をチェックリストとして追加する方法に関するページを参照してください。
テスト ツールからバグを作成する
テストの間にバグを追加するために使用できるテスト ツールは、Web ポータルの Test Runner とテスト & フィードバック拡張機能の 2 つです。
Test Runner: 手動でテストを実行しているときに、 [バグの作成] を選択できます。 詳細については、「手動テストの実行」を参照してください。
テスト & フィードバック拡張機能: 探索的テストを実行する際、 [バグの作成] または [タスクの作成] を選択できます。 詳細については、「テスト & フィードバック拡張機能を使用した探索的テスト」を参照してください。
バグのライフサイクルとワークフローの状態
他のすべての作業項目の種類と同様に、バグ作業項目の種類には明確に定義されたワークフローがあります。 各ワークフローは、3 つ以上の 状態 と 理由で構成されます。 理由は、ある状態から別の状態に項目が遷移する理由を指定します。 次の図は、 アジャイル、 スクラム、 CMMI プロセスで定義されている既定のバグ ワークフローを示しています。
| アジャイル | スクラム | CMMI |
|---|---|---|
|
|
|
スクラムのバグの場合は、 状態 を "コミット済み" ("アクティブ" に似ています) から "完了" に変更します。 アジャイルと CMMI の場合は、最初にバグを解決し、バグが修正されたことを示す理由を選びます。 通常、バグを作成したユーザーが、修正を検証して、 状態を "解決済み" から "終了" に更新します。 バグを解決またはクローズした後で、さらに作業が見つかった場合は、状態をコミット済みまたはアクティブに設定することで、バグを再アクティブ化します。
Note
アジャイル プロセスのバグ作業項目の種類には、以前、バグを作成したユーザーに再度割り当てるルールがありました。 このルールは、既定のシステム プロセスから削除されています。 ルールを追加することで、この自動化を元に戻すことができます。 継承プロセスについては、「状態変更に基づいて再割り当てを自動化する」を参照してください。
修正を確認する
修正を確認するには、開発者またはテスト担当者が、バグを再現して、予期しない動作が他にもあるか探します。 必要に応じて、バグを再度アクティブにする必要があります。
バグの修正を確認するときに、バグが修正されていないことが判明する場合や、解決に同意できない場合があります。 この場合、バグの解決者とバグについて話し合い、合意に達してから、場合によってはバグを再度アクティブにします。 バグを再度アクティブにする場合は、バグの説明にバグの再アクティブ化の理由を含めます。
バグを閉じる
チーム メンバーがバグが修正されたことを確認したら、バグを閉じます。 ただし、次のいずれかの理由でバグを閉じることもあります。 考えられる理由は、プロジェクトのプロセスとバグ遷移の状態によって異なります。
アジャイル プロセス:
- 延期: 次の製品リリースまでバグ修正を延期します。
- 修正済み: バグが修正済みとして検証されました。
- 重複: バグは、現在定義されている別のバグを追跡しています。 各バグを 重複と重複元 のリンクの種類でリンクして、バグの 1 つを閉じることができます。
- 設計どおり: 機能は設計どおりに動いています。
- 再現できない: バグを再現できないことがテストで証明されました。
- 古い: バグの機能は製品からなくなっています。
- バックログにコピー済み: バグを追跡するためにユーザー ストーリーが開かれています。
スクラム プロセス:
- バグではない: このバグはバグではないことが確認されました。
- 重複: バグは、現在定義されている別のバグを追跡しています。 各バグを 重複と重複元 のリンクの種類でリンクして、バグの 1 つを閉じることができます。
- バックログから削除: このバグはバグではないことが確認されました。 バックログからバグを削除します。
- 作業完了済み: バグが修正済みとして検証されました。
CMMI プロセス:
- 延期: 次の製品リリースまでバグ修正を延期します。
- 重複: バグは、現在定義されている別のバグを追跡しています。 各バグを 重複と重複元 のリンクの種類でリンクして、バグの 1 つを閉じることができます。
- 拒否済み: このバグはバグではないことが確認されました。
- 検証済み: バグが修正済みとして検証されました。
ヒント
バグが閉じられ、配置で修正がアクティブにリリースされた後は、回帰のために再度開かないことをお勧めします。 代わりに、新しいバグを開き、古い閉じられたバグにリンクすることを検討する必要があります。
バグが閉じられた理由について将来の混乱を避けるため、 [ディスカッション] フィールドにバグの終了に関する詳細を記述することをお勧めします。
pull request をマージするときのバグの終了を自動化する
チームが Git リポジトリを使っている場合は、pull request のマージが成功したときに、リンクされたバグやその他の作業項目の状態を終了に設定できます。 詳しくは、この記事で後述する「pull request で作業項目の状態を設定する」をご覧ください。
バグの一覧表示とトリアージ
ほとんどのチームは、選択したバグ追跡オプションが何であっても、1 つ以上のバグ クエリを定義します。 クエリを使うと、アクティブなバグ、割り当てられていないバグ、古いバグ、バグの傾向などの一覧を表示できます。 クエリとクエリ グラフをチーム ダッシュボードに追加して、バグの状態と進行状況を監視できます。
バグ クエリ
共有クエリを開くか、クエリ エディターを使用して、次のオプションなどの便利なバグ クエリを作成します。
- 優先度別のアクティブなバグ (
State <> DoneまたはState <> Closed) - 進行中のバグ (
State = CommittedまたはState = Active) - ターゲット リリースのために修正するバグ (
Tags Contains RTM) - 過去 3 週間に開かれたバグ (
Created Date > @Today-21) など、最近のバグ
チームにとって関心のあるクエリを作成すれば、状態グラフまたは傾向グラフを作成できます。 作成したグラフを ダッシュボードに追加することもできます。
クエリ結果でのトリアージ モード
コーディングとテストを開始したら、定期的にトリアージ会議を開いて、バグの確認と優先度付けを行う必要があります。 通常は、プロジェクト所有者がバグ トリアージ会議を行います。 特定のプロジェクト リスクについて話すことができるチーム リーダー、ビジネス アナリスト、その他の利害関係者が、トリアージ会議に参加します。
プロジェクト所有者は、新しいバグと再開されたバグの共有クエリを定義して、トリアージ対象のバグの一覧を取得できます。
クエリ結果ページでは、上下の矢印を使って、バグ作業項目の一覧内を上下に移動できます。 各バグを確認しながら、その割り当て、詳細の追加、優先度の設定を行うことができます。
スプリントにバグを整理して割り当てる
チームが "バグを要件として追跡している" 場合は、バックログからアクティブなバグの一覧を表示します。 フィルター機能を使うと、バグのみに集中できます。 プロダクト バックログからは、次のタスクを実行することもできます。
- バックログのバグを整理する。 他の項目に対してスタック順位を付ける。 フィルタリングが有効になっている場合、スタック順位付けは無効になります。
- [計画] ペインを使用して、バックログからスプリントにバグを割り当てる。
- [マッピング] ペインを使用して、親バグを機能にマッピングまたは他のポートフォリオ バックログ項目にマッピングします。
- ポートフォリオ バックログ項目への作業のロールアップを表示します。
チームが "バグをタスクとして追跡している" 場合は、マネージド クエリを使ってバグの一覧表示とトリアージを行います。 各スプリントでは、スプリント バックログまたはタスクボードからスプリントに割り当てられたバグが表示されます。
タスクボードの項目とクエリ リストの項目
スプリント タスクボードに表示される項目が、対応するスプリント バックログで作成されたクエリ リストと異なることに気付き、なぜなのか疑問に思うかもしれません。
タスクまたはバグをイテレーションに割り当てることはできますが、親バックログ項目にリンクすることはできません。 これらの項目は、作成されたクエリには表示されますが、タスクボード自体には表示されない可能性があります。 システムはクエリを実行してから、いくつかのバックグラウンド プロセスを適用した後、タスクボード項目を表示します。
次の原因により、タスク カテゴリに属している作業項目がスプリント バックログまたはタスクボードに表示されないことがあります。
- タスクまたはバグが親バックログ項目にリンクされていません。 イテレーション パスがスプリントに設定されている親プロダクト バックログ項目 (スクラム)、ユーザー ストーリー (アジャイル)、または要件 (CMMI) にリンクされているバグとタスクのみが、スプリント バックログ ページに表示されます。
- タスクまたはバグが別のタスクまたはバグの親であるか、ユーザー ストーリーが別のユーザー ストーリーの親です。 タスク、バグ、またはユーザー ストーリーの階層を作成した場合、階層の下端にある子レベルのタスクまたは子レベルのストーリーのみが表示されます。 詳細については、「問題の順序の付け直しとネストに関するトラブルシューティング」を参照してください。
- タスクまたはバグのリンクされている親が、別のチームに定義されているバックログ項目に対応しています。 または、タスクまたはバグの親バックログ項目の区分パスが、タスクまたはバグの区分パスと異なっています。
バグにリンクされたインライン テストを作成する
チームが バグを要件として追跡する場合、ボードを使用してテストを追加し、バグ修正を検証できます。
バグの状態を更新する
ボード上の新しい列にバグをドラッグ アンド ドロップすることで、バグの状態を更新できます。
チームが バグを要件として追跡する場合は、次の図に示すようにボードを使用します。 詳細については、「作業項目の状態を更新する」を参照してください。
チームが "バグをタスクとして追跡している" 場合は、タスクボードを使います。 詳細については、「タスクボードを更新して監視する」を参照してください。
ボードをカスタマイズして中間状態を追跡する
バグの状態を追跡するための中間列をボードに追加できます。 ボードの列の状態に基づいてフィルター処理するクエリを定義することもできます。 詳細については、次の記事をご覧ください。
ワークフローの状態に基づいてバグの再割り当てを自動化する
選択アクションを自動化するには、バグ作業項目の種類にカスタム ルールを追加します。 たとえば、次の図に示すようなルールを追加します。 このルールは、チーム メンバーがバグを解決したときに、バグを開いたユーザーにそのバグを再割り当てすることを指定します。 通常、そのユーザーが、バグが修正されていることを確認して、バグを閉じます。 詳細については、「ワークフローの状態にルールを適用する (継承プロセス)」をご覧ください。
pull request で作業項目の状態を設定する
pull request を作成するときに、リンクされた作業項目の "状態" 値を[説明] に設定できます。 構文 {state value}: #ID を使用します。
pull request をマージするときに、システムが説明を読み取り、作業項目の状態を更新します。 次の例では、作業項目 #300 と #301 を解決済みに、#323 と #324 をクローズ済みに設定しています。
Note
この機能では、Azure DevOps Server 2020.1 更新プログラムのインストールが必要です。 詳しくは、Azure DevOps Server 2020 Update 1 RC1 リリース ノートの Boards に関する説明をご覧ください。
Azure DevOps 全体の統合
Azure DevOps で統合をサポートするために使われる方法の 1 つは、オブジェクトを他のオブジェクトにリンクすることです。 作業項目を作業項目にリンクするだけでなく、作業項目を他のオブジェクトにリンクすることもできます。 次の図に示すように、ビルド、リリース、ブランチ、コミット、pull request などのオブジェクトにリンクします。
作業項目からの、またはビルドとリリース オブジェクトからの、リンクを追加できます。
作業項目を開発にリンクする
開発コントロールでは、ビルド、Git コミット、プル要求へのリンクと、それらに対して行われているリンクの表示が、サポートされています。 TFVC リポジトリを使っているときは、変更セットとバージョン管理された項目へのリンクがサポートされます。 リンクを選択すると、それに対応する項目が新しいブラウザー タブで開きます。詳細については、「作業項目から Git 開発を推進する」を参照してください。
作業項目をリリースにリンクする
[配置] コントロールは、作業項目を含むリリースへのリンクと表示をサポートします。 たとえば、次の図は、現在の作業項目へのリンクを含む複数のリリースを示しています。 各リリースを展開して、各ステージの詳細を見ることができます。 各リリースとステージのリンクを選んで、対応するリリースまたはステージを開くことができます。 詳細については、「作業項目を配置にリンクする」を参照してください。
作業項目をパイプライン実行にリンクする
Git リポジトリへの新しいコミットが発生したときに自動的に実行するため、パイプラインが定義されることがよくあります。 パイプラインの設定をカスタマイズすると、コミット パイプラインに関連付けられている作業項目が、パイプライン実行の一部として表示されます。 詳細については、「パイプラインのカスタマイズ」を参照してください。
![パイプライン設定のスクリーンショット。選択したブランチから [この実行に含まれている作業項目を自動的にリンクする] が強調表示されています。](media/manage-bugs/pipeline-settings.png?view=azure-devops)
ビルド エラー時に作業項目を作成または編集する
(YAML ではなく) クラシック パイプラインを使っている場合は、ビルド エラーで作業項目を作成できます。 詳細については、「失敗時に作業項目を作成」を参照してください。
バグの状態、割り当て、傾向を監視する
クエリを使ってバグの状態、割り当て、傾向を追跡し、グラフを作成してダッシュボードに追加できます。 たとえば、状態別のアクティブなバグと優先度別のアクティブなバグの経時的な傾向を示す 2 つの例を次に示します。
クエリ、グラフ、ダッシュボードの詳細については、マネージド クエリ、グラフ、ダッシュボードに関する記事を参照してください。
Analytics ビューと Analytics サービスを使用してバグ レポートを作成する
Analytics サービスは、Azure DevOps のレポート プラットフォームです。 SQL Server Reporting Services に基づく以前のプラットフォームに代わるものです。
分析ビューには、作業項目を表示するための事前構築済みフィルターが用意されています。 バグ レポートについては、4 つの Analytics ビューがサポートされています。 これらのビューは、定義どおりに使うことも、さらに編集して、フィルター処理されたカスタム ビューを作成することもできます。
- バグ - 月別のすべての履歴
- バグ - 過去 26 週間
- バグ - 過去 30 日間
- バグ - 今日
分析ビューの使用に関する詳細については、「Analytics ビューについて」および「カスタム分析ビューに基づいて Power BI でアクティブなバグ レポートを作成する」を参照してください。
Power BI を使用すると、クエリよりも複雑なレポートを作成できます。 詳細については、 Power BI データ コネクタでの接続に関する記事をご覧ください。
定義済みの SQL Server バグ レポート
アジャイルと CMMI プロセスでは、次のレポートがサポートされています。
これらのレポートを使用するには、プロジェクトに対して SQL Server Analysis Services と SQL Server Reporting Services が構成されている必要があります。 プロジェクトに SQL Server レポートを追加する方法については、 プロジェクトへのレポートの追加に関する記事をご覧ください。
Marketplace 拡張機能
複数のバグ関連の Marketplace 拡張機能があります。 Azure DevOps に関する Marketplace をご覧ください。
拡張機能について詳しくは、 Microsoft によって開発された Azure Boards 拡張機能に関する記事をご覧ください。
次のステップ
関連記事
製品バックログとボード
- バックログを使用してプロジェクトを管理する
- バックログの作成
- フィーチャーとエピックを定義する
- バックログを整理し、子作業項目を親にマップする
- バックログ、ボード、クエリ、計画を対話的にフィルター処理する
- プロダクト バックログを予測する
Board
スプリント バックログとタスクボード
Azure DevOps 内の統合
業界リソース
- 良い技術的負債と悪い技術的負債 (および TDD の利用方法) (投稿者: Henrik Kniberg)
- 技術的負債の管理 (投稿者: Sven Johann & Eberhard Wolff)