Azure Boardsでのバグの定義、キャプチャ、トリアージ、管理

Azure DevOps サービス |Azure DevOps Server |Azure DevOps Server 2022

コード内の欠陥をどのように追跡し、管理していますか。 高品質のソフトウェアを配置するため、どのようにして、ソフトウェアの問題と顧客からのフィードバックに、速やかに対応していますか。 新機能の開発を順調に進め、技術的負債に対処するにはどうすればよいのでしょうか。

少なくとも、ソフトウェアの問題をキャプチャし、優先順位を付け、チーム メンバーに割り当て、進行状況を追跡する方法が必要です。 アジャイル プラクティスに合った方法でコードの欠陥を管理する必要があります。

これらのシナリオをサポートするために、Azure Boardsは、Bug という名前のコードの欠陥を追跡する特定の作業項目の種類を提供します。 バグ作業項目は、他の作業項目の種類のすべての標準機能に加えて、さらにいくつかの機能を備えています。 標準機能の概要については、「作業項目と作業項目の種類の概要」を参照してください。

バグにより、以下の追加機能も提供されます。

• 各チームがバグを追跡する方法を選択するためのオプション
• バグをキャプチャするためのテスト ツール
• ビルド、リリース、テストにリンクされているバグを追跡するためのAzure DevOps全体の組み込み統合

Prerequisites

バグ作業項目の種類

次の図は、スクラム プロセスのバグ作業項目の種類を示したものです。 アジャイルおよび Capability Maturity Model Integration (CMMI) プロセスのバグ作業項目の種類でも、同様の情報が追跡されます。 これは、要件と共にプロダクト バックログに表示されるか、タスクと共にタスクボードに表示されます。

バグに固有のフィールド

バグ作業項目の種類では、バグ固有のフィールドがいくつか使用されます。 最初の問題と進行中の検出の両方をキャプチャするには、次の表に示すフィールドを使います。 能力成熟度モデル統合 (CMMI) プロセスで定義されているバグに固有のフィールドについては、 バグ、イシュー、リスクのフィールド リファレンスに関する記事をご覧ください。 その他のすべてのフィールドの詳細については、「作業項目フィールドのインデックス」を参照してください。

Notes

1 メニューの選択または候補リストの変更については、「作業追跡エクスペリエンスをカスタマイズする」をご覧ください。 カスタマイズ方法は、プロジェクトで使われているプロセス モデルによって異なります。

チームがバグを追跡する方法を選択する

チームは、要件またはタスクとしてバグを追跡できます。 チームの選択をサポートするには、次の要因を検討します。

• チームのサイズ。 小規模なチームは、要件としてバグを追跡することで、作業量を増やさないでおくことができます。
• 作業の追跡に関する組織の要件。 時間を追跡する必要があるチームは、タスクとしてバグを追跡することを選択します。
• チームの作業の整理。 チームがプロダクト バックログを利用して作業に優先順位を付け、バグを追加する場合は、要件としてバグを追跡します。
• チームが使用するツール ([計画] ペイン、ベロシティ グラフ、予測、ロールアップ、配信計画など)。 タスクとしてバグを追跡すると、これらのツールの一部を使用できません。

次の表は、バグの追跡に関するチームの 3 つのオプションをまとめたものです。 チームの詳細とオプションを設定するには、「 バックログとボードにバグを表示する」を参照してください。

作業項目の種類をカスタマイズする

バグやその他の作業項目の種類をカスタマイズできます。 または、カスタムの種類を作成して、ソフトウェアの問題や顧客からのフィードバックを追跡します。 すべての種類の作業項目で、次の要素をカスタマイズできます。

• カスタム フィールドを追加または削除する
• 作業項目フォームにカスタム コントロールまたはカスタム タブを追加する
• ワークフローの状態をカスタマイズする
• 条件付きルールを追加する
• 作業項目が表示されるバックログ レベルを選択する

プロセスをカスタマイズする前に、Azure Boards。

バグを追加またはキャプチャする

複数の異なるAzure DevOps ツールからバグを定義できます。 これらのツールには、バックログ、ボード、テスト ツールが含まれます。

バックログまたはボードからバグを追加する

チームが 要件に合わせてバグを管理することを選択した場合は、製品のバックログまたはボードからバグを定義できます。 詳細については、「プロダクト バックログを作成する」または「ボードを使う」を参照してください。

• プロダクト バックログからバグを追加する

  スクリーンショットは、プロダクト バックログからのバグの追加を示しています。

• ボードからバグを追加する

  スクリーンショットは、ボードからのバグの追加を示しています。

スプリント バックログまたはタスクボードからバグを追加する

チームが タスクでバグを管理することを選択した場合は、ボード、製品バックログ、スプリント バックログ、またはスプリント タスクボードからバグを定義できます。 製品バックログ作業項目に子としてバグを追加します。

• スプリント バックログからリンクされた子バグを追加する

  スプリント バックログにタスクを追加するのと同じ方法でバグを追加します。 詳細については、 バックログ項目へのタスクの追加に関する記事をご覧ください。

  スクリーンショットは、リンクされた子バグをプロダクト バックログから追加する方法を示しています。

• ボードからリンクされた子バグを追加する

  バックログ項目にタスクを追加するのと同じ方法でバグを追加します。 詳細については、 タスクまたは子項目をチェックリストとして追加する方法に関するページを参照してください。

  スクリーンショットは、リンクされた子バグをボードから追加する方法を示しています。

テスト ツールからバグを作成する

テストの間にバグを追加するために使用できるテスト ツールは、Web ポータルの Test Runner とテスト & フィードバック拡張機能の 2 つです。

• Test Runner: 手動でテストを実行しているときに、[バグの作成] を選択できます。 詳細については、「手動テストの実行」を参照してください。

  スクリーンショットは、テスト ランナーを示しています。ここで、バグを追加できます。

• テスト & フィードバック拡張機能: 探索的テストを実行する際、[バグの作成] または [タスクの作成] を選択できます。 詳細については、「テスト & フィードバック拡張機能を使用した探索的テスト」を参照してください。

  スクリーンショットは、テスト & フィードバック拡張機能を示しています。ここでバグやタスク機能を追加できます。

バグのライフサイクルとワークフローの状態

他のすべての作業項目の種類と同様に、バグ作業項目の種類には明確に定義されたワークフローがあります。 各ワークフローは、3 つ以上の 状態 と 理由で構成されます。 理由は、ある状態から別の状態に項目が遷移する理由を指定します。 次の図は、 アジャイル、 スクラム、 CMMI プロセスで定義されている既定のバグ ワークフローを示しています。

スクラムのバグの場合は、 状態 を "コミット済み" ("アクティブ" に似ています) から "完了" に変更します。 アジャイルと CMMI の場合は、最初にバグを解決し、バグが修正されたことを示す理由を選びます。 通常、バグを作成したユーザーが、修正を検証して、 状態を "解決済み" から "終了" に更新します。 バグを解決またはクローズした後で、さらに作業が見つかった場合は、状態をコミット済みまたはアクティブに設定することで、バグを再アクティブ化します。

修正を確認する

修正プログラムを検証するために、開発者またはテスト担当者はバグの再現を試み、より予期しない動作を探します。 必要に応じて、バグを再アクティブ化します。

バグの修正を確認するときに、バグが修正されていないことが判明する場合や、解決に同意できない場合があります。 この場合、バグの解決者とバグについて話し合い、合意に達してから、場合によってはバグを再度アクティブにします。 バグを再度アクティブにする場合は、バグの説明にバグの再アクティブ化の理由を含めます。

バグを閉じる

チーム メンバーがバグを修正済みとして検証したら、バグを閉じます。 ただし、次のいずれかの理由でバグを閉じることもあります。 表示される理由は、プロジェクト プロセスとバグ移行の状態によって異なります。

アジャイル プロセス:

• 延期: 次の製品リリースまでバグ修正を延期します。
• 修正済み: バグが修正済みとして検証されました。
• 重複: バグは、現在定義されている別のバグを追跡しています。 各バグを 重複と重複元 のリンクの種類でリンクして、バグの 1 つを閉じることができます。
• 設計どおり: 機能は設計どおりに動いています。
• 再現できない: バグを再現できないことがテストで証明されました。
• 古い: バグの機能は製品からなくなっています。
• バックログにコピー: バグを追跡するためにユーザー ストーリーが開かれます。

スクラム プロセス:

• バグではない: このバグはバグではないことが確認されました。
• 重複: バグは、現在定義されている別のバグを追跡しています。 各バグを 重複と重複元 のリンクの種類でリンクして、バグの 1 つを閉じることができます。
• バックログから削除: このバグはバグではないことが確認されました。 バックログからバグを削除します。
• 作業が完了しました:バグは修正済みとして検証されます。

CMMI プロセス:

• 延期: 次の製品リリースまでバグ修正を延期します。
• 重複: バグは、現在定義されている別のバグを追跡しています。 各バグを 重複と重複元 のリンクの種類でリンクして、バグの 1 つを閉じることができます。
• 拒否済み: このバグはバグではないことが確認されました。
• 検証済み: バグが修正済みとして検証されました。

バグが閉じられた理由に関する将来の混乱を避けるために 、[ディスカッション ] フィールドでバグを閉じるための詳細について説明します。

バグの一覧表示とトリアージ

ほとんどのチームは、バグを追跡するために選択したオプションに関係なく、1 つ以上のバグ クエリを定義します。 クエリを使うと、アクティブなバグ、割り当てられていないバグ、古いバグ、バグの傾向などの一覧を表示できます。 クエリとクエリ グラフをチーム ダッシュボードに追加して、バグの状態と進行状況を監視できます。

バグ クエリ

共有クエリを開くか、クエリ エディターを使用して、次のオプションなどの便利なバグ クエリを作成します。

• 優先度別のアクティブなバグ ( または )
• 進行中のバグ ( または )
• ターゲット リリースのために修正するバグ ()
• 過去 3 週間に開かれたバグ () など、最近のバグ

チームに関心のあるクエリがある場合は、 状態グラフまたは傾向グラフを作成します。 作成したグラフを ダッシュボードに追加することもできます。

クエリ結果でのトリアージ モード

コーディングとテストを開始したら、定期的にトリアージ会議を開いて、バグの確認と優先度付けを行う必要があります。 通常は、プロジェクト所有者がバグ トリアージ会議を行います。 特定のプロジェクト リスクについて話すことができるチーム リーダー、ビジネス アナリスト、その他の利害関係者が、トリアージ会議に参加します。

プロジェクト所有者は、新しいバグと再開されたバグの共有クエリを定義して、トリアージ対象のバグの一覧を取得できます。

クエリ結果ページでは、上下の矢印を使って、バグ作業項目の一覧内を上下に移動できます。 各バグを確認しながら、その割り当て、詳細の追加、優先度の設定を行うことができます。

クエリ結果、アクティブなバグ、右ペインのトリアージ モードのスクリーンショット。

スプリントにバグを整理して割り当てる

チームが "バグを要件として追跡している" 場合は、バックログからアクティブなバグの一覧を表示します。 フィルター関数を使用すると、バグのみに集中できます。 プロダクト バックログからは、次のタスクを実行することもできます。

• バックログのバグを整理する。 他の項目と比べてバグを優先順位付けします。 フィルタリングが有効になっている場合、スタック順位付けは無効になります。
• [計画] ウィンドウを使用して、バックログからスプリントにバグを割り当てます。
• 親バグをフィーチャーまたはその他のポートフォリオ バックログ項目にマップするには、[マッピング] ペインを使用します。
• ポートフォリオ バックログ項目への作業のロールアップを表示します。

チームが "バグをタスクとして追跡している" 場合は、マネージド クエリを使ってバグの一覧表示とトリアージを行います。 各スプリントでは、スプリント バックログまたはタスクボードからスプリントに割り当てられたバグが表示されます。

タスクボードの項目とクエリ リストの項目

スプリント タスクボードに表示される項目が、対応するスプリント バックログで作成されたクエリ リストと異なる理由に気付き、疑問に思うかもしれません。

イテレーションにタスクやバグを割り当てることができますが、親バックログ項目にリンクすることはできません。 これらの項目は、作成されたクエリには表示されますが、タスクボード自体には表示されない可能性があります。 システムはクエリを実行し、タスクボード項目を表示する前にいくつかのバックグラウンド プロセスを適用します。

次の原因により、タスク カテゴリに属している作業項目がスプリント バックログまたはタスクボードに表示されないことがあります。

• タスクまたはバグが親バックログ項目にリンクされていません。 スプリントにイテレーション パスが設定されている親製品バックログ項目 (スクラム)、ユーザー ストーリー (アジャイル)、または要件 (CMMI) にリンクされているバグとタスクのみが、スプリント バックログ ページに表示されます。
• タスクまたはバグが別のタスクまたはバグの親であるか、ユーザー ストーリーが別のユーザー ストーリーの親です。 タスク、バグ、またはユーザー ストーリーの階層を作成した場合、階層の下端にある子レベルのタスクまたは子レベルのストーリーのみが表示されます。 詳細については、「問題の順序の付け直しとネストに関するトラブルシューティング」を参照してください。
• タスクまたはバグのリンクされている親が、別のチームに定義されているバックログ項目に対応しています。 または、タスクまたはバグの親バックログ項目の区分パスが、タスクまたはバグの区分パスと異なっています。

バグにリンクされたインライン テストを作成する

チームが バグを要件として追跡する場合は、ボードを使用して、バグ修正を検証するテストを追加します。

ボードのスクリーンショット。3 つの列に、追加されバグにリンクされたインライン テストが示されています。

バグの状態を更新する

ボード上の新しい列にバグをドラッグ アンド ドロップして、バグの状態を更新します。

• チームが 要件としてバグを追跡する場合は、次の図に示すようにボードを使用します。 詳細については、「作業項目の状態を更新する」を参照してください。

  ボードのスクリーンショット。ここで、バグをドラッグして状態を更新できます。

• チームが タスクとしてバグを追跡する場合は、タスクボードを使用します。 詳細については、「タスクボードを更新して監視する」を参照してください。

  タスクボードのスクリーンショット。ここで、バグをドラッグして状態を更新できます。

ボードをカスタマイズして中間状態を追跡する

ボード上のバグの状態を追跡する中間列を追加します。 ボードの列の状態に基づいてフィルター処理するクエリを定義することもできます。 詳細については、次の記事を参照してください。

ワークフローの状態に基づいてバグの再割り当てを自動化する

選択アクションを自動化するには、バグ作業項目の種類にカスタム ルールを追加します。 たとえば、次の図に示すようなルールを追加します。 このルールは、チーム メンバーがバグを解決したときに、バグを開いたユーザーにそのバグを再割り当てすることを指定します。 通常、そのユーザーが、バグが修正されていることを確認して、バグを閉じます。 詳細については、「ワークフローの状態にルールを適用する (継承プロセス)」をご覧ください。

解決済み状態に基づいてバグを割り当て直すように定義されたルールのスクリーンショット。

pull request で作業項目の状態を設定する

Azure DevOps間の統合

統合をサポートするために使用Azure DevOpsメソッドの 1 つは、オブジェクトを他のオブジェクトにリンクすることです。 作業項目を作業項目にリンクするだけでなく、作業項目を他のオブジェクトにリンクすることもできます。 次の図に示すように、ビルド、リリース、ブランチ、コミット、pull request などのオブジェクトにリンクします。

作業項目をビルドとリリース オブジェクトにリンクするために使われるリンクの種類を示す図。

作業項目からの、またはビルドとリリース オブジェクトからの、リンクを追加できます。

作業項目を開発にリンクする

開発コントロールでは、ビルド、Git コミット、プル要求へのリンクと、それらに対して行われているリンクの表示が、サポートされています。 TFVC リポジトリを使用すると、変更セットとバージョン管理された項目へのリンクがサポートされます。 リンクを選択すると、対応する項目が新しいブラウザー タブで開きます。詳細については、「 作業項目から Git 開発を推進する」を参照してください。

スクリーンショットは、作業項目フォーム上の開発コントロールを示しています。ビルド、プル要求、コミットへのサンプル リンクがあります。

作業項目をリリースにリンクする

[配置] コントロールは、作業項目を含むリリースへのリンクと表示をサポートします。 たとえば、次の図は、現在の作業項目へのリンクを含む複数のリリースを示しています。 各リリースを展開して、各ステージの詳細を見ることができます。 各リリースとステージのリンクを選んで、対応するリリースまたはステージを開くことができます。 詳細については、「作業項目を配置にリンクする」を参照してください。

スクリーンショットは、作業項目フォーム上の配置コントロールとサンプル リリースを示しています。

作業項目をパイプライン実行にリンクする

多くの場合、Git リポジトリに対して新しいコミットが発生したときに自動的に実行されるようにパイプラインを定義します。 パイプラインの設定をカスタマイズすると、コミット パイプラインに関連付けられている作業項目が、パイプライン実行の一部として表示されます。 詳細については、「パイプラインのカスタマイズ」を参照してください。

パイプライン設定のスクリーンショット。選択したブランチから [この実行に含まれている作業項目を自動的にリンクする] が強調表示されています。

ビルド エラー時に作業項目を作成または編集する

(YAML ではなく) クラシック パイプラインを使っている場合は、ビルド エラーで作業項目を作成できます。 詳細については、「失敗時に作業項目を作成」を参照してください。

バグの状態、割り当て、傾向を監視する

グラフ化してダッシュボードに追加できるクエリを使用して、バグの状態、割り当て、傾向を追跡できます。 たとえば、次の 2 つの例は、時間の経過に伴う状態別のアクティブなバグの傾向と優先度別のアクティブなバグの傾向を示しています。

状態別と優先度別の 2 つのアクティブなバグの傾向のクエリ グラフのスクリーンショット。

クエリ、グラフ、およびダッシュボードの詳細については、 マネージド クエリ、 グラフ、 およびダッシュボードを参照してください。

Marketplace 拡張機能

Marketplace には、バグ関連の拡張機能が複数用意されています。 Azure DevOpsについては、「Marketplace」を参照してください。

拡張機能の詳細については、「Azure Boards Microsoft によって開発された拡張機能を参照してください。

次のステップ

AI を使用してバグを管理する

Azure DevOps MCP Server を構成する場合は、自然言語を使用してバグをトリアージおよび管理できます。

関連コンテンツ

• プロダクト バックログを予測する
• タスクボードを更新する