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 以降のバージョンから新しいプロジェクトを作成するときに使用できます。

前提条件

• ユーザーがプロジェクトに追加されている必要があります。
• 作業項目を表示または変更するには、[このノードの作業項目の表示] および [このノードの作業項目の編集] アクセス許可を [許可] に設定している必要があります。 既定では、共同作成者グループにはこのアクセス許可が設定されています。 詳細については、「作業追跡のアクセス許可とアクセスを設定する」を参照してください。
• 新しいタグを作業項目に追加するには、Basic 以上のアクセス権が付与されていて、プロジェクト レベルの [Create new tag definition] (新しいタグ定義の作成) アクセス許可が [許可] に設定されている必要があります。 既定では、共同作成者グループにはこのアクセス許可が設定されています。 利害関係者に対してアクセス許可が明示的に設定されている場合でも、アクセス レベルによって禁止されているため、新しいタグを追加するアクセス許可はありません。 詳細については、「利害関係者アクセスクイック リファレンス」を参照してください。
• すべてのプロジェクト メンバー (閲覧者グループのメンバーも含む) が、作業項目を含む電子メールを送信できます。

ヒント

バグを報告するには、ユーザーは少なくとも、利害関係者アクセス権を持ち、バグを追加する区分パスに対するこのノードの作業項目を編集しますアクセス許可が許可に設定されています必要があります。 詳細については、「作業追跡のアクセス許可とアクセスを設定する」を参照してください

バグ作業項目の種類

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

Note

Web ポータルに表示される画像は、この記事の画像と異なる場合があります。 それらの違いは、Web アプリに対して行われた更新、自分または管理者が有効にしたオプション、プロジェクトの作成時に選択されたプロセス (アジャイル、基本、スクラム、CMMI) に起因します。 基本プロセスは、Azure DevOps Server 2019 Update 1 以降のバージョンで使用できます。

バグに固有のフィールド

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

---

フィールド、グループ、またはタブ

使用方法

---

再現手順
(フレンドリ名 = 再現ステップ)

他のチーム メンバーがコードの欠陥を完全に理解できるよう、十分な情報をキャプチャするために使います。 バグの検出や再現に必要な操作と、予想される動作が含まれます。

---

システム情報
発見されたビルド

バグおよび適用するテストに関連するソフトウェアとシステム構成に関する情報。 テスト ツールを使ってバグを作成すると、[システム情報] と [発見されたビルド] フィールドは自動的に入力されます。 これらのフィールドは、バグが発生したソフトウェア環境とビルドに関する情報を指定します。 詳細については、「異なる構成のテスト」を参照してください。

---

受け入れ基準

バグを閉じる前に満たす条件を指定します。 作業を始める前に、顧客の受け入れ基準をできる限り明確に説明します。 チームは、この基準を受け入れテストの基礎として使用し、項目が正常に完了したかどうかを評価する必要があります。

---

ビルドに統合

バグを修正するコードを組み込むビルドの名前を指定します。 このフィールドは、バグを解決するときに指定する必要があります。 オンプレミスの Azure DevOps の場合、実行が完了したすべてのビルドのドロップダウン メニューにアクセスするには、[発見されたビルド] および [ビルドに統合] の FIELD 定義を更新して、グローバル リストを参照できます。 グローバル リストは、実行するビルドごとに自動的に更新されます。 詳細については、ビルドとテストの統合フィールドに基づくクエリに関する記事をご覧ください。
ビルド番号を定義する方法については、ビルド番号の形式オプションに関する記事をご覧ください。

---

優先度¹

• 1: 製品が出荷される前に作業項目を正しく解決し、すぐに対処する必要があります。
• 2: 製品が出荷される前に作業項目を正しく解決する必要がありますが、すぐに対処する必要はありません。
• 3: 作業項目の解決は、リソース、時間、リスクに基づき、必要に応じて行います。

---

重大度¹

プロジェクトまたはソフトウェア システムに対するバグまたは作業項目の影響に関する主観的な評価。 たとえば、ユーザー インターフェイス内のリモート リンク (まれなイベント) によってアプリケーションまたは Web ページがクラッシュする場合 (重大なカスタマー エクスペリエンス)、重大度 = 2 - 高および優先度 = 3 を指定することがあります。 使用できる値と推奨されるガイドラインは次のとおりです。

• 1 - 重大: 修正する必要があります。 1 つ以上のシステム コンポーネントまたは完全なシステムの終了を引き起こす、または広範なデータ破損を引き起こす欠陥。 また、必要な結果を得るために受け入れられる代替方法はありません。
• 2 - 高: 修正を検討します。 1 つ以上のシステム コンポーネントまたは完全なシステムの終了を引き起こす、または広範なデータ破損を引き起こす欠陥。 ただし、必要な結果を得るために、受け入れられる代替方法が存在します。
• 3 - 中: (既定値) システムが正しくない、不完全な、または一貫性のない結果を生成する原因となる欠陥。
• 4 - 低: 必要な結果を得るための受け入れられる回避策がある、軽微または表面的な欠陥。

---

デプロイ

[配置] コントロールは、作業項目を含むリリースへのリンクと表示をサポートします。 このコントロールを使用するには、リリースの設定を有効にする必要があります。 詳細については、この記事で後述する「作業項目をリリースにリンクする」をご覧ください。

---

開発

[開発] コントロールは、開発オブジェクトへのリンクとリンクの表示をサポートします。 これらのオブジェクトには、Git コミットと pull request、または TFVC 変更セットとバージョン管理された項目が含まれます。 作業項目からのリンク、またはコミット、pull request、またはその他の開発オブジェクトからのリンクを定義できます。 詳細については、この記事で後述する「作業項目を開発にリンクする」をご覧ください。

---

メモ:

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

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

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

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

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

---

オプション

以下のことが必要なときに選択

---

バグを要件として追跡する

• 要件と共にバグの優先順位を決める (スタック順位)
• 予測のためにバグの作業量を見積もる
• かんばんボードでバグの状態を更新する
• ベロシティ グラフと累積フロー ダイアグラムにバグを含める
• スプリント計画をサポートするために予測ツールを使用できる
• バグを [計画] ペインにドラッグ アンド ドロップして、スプリントにバグを割り当てることができる
• 配信計画でバグを見ることができる

Note

• バグは要件カテゴリに割り当てられます

---

タスクとしてバグを追跡する

• タスクと同じようにバグの作業を見積もる
• スプリントのタスクボードでバグの状態を更新する
• バグを子項目として要件にリンクする
• バグを [計画] ペインにドラッグ アンド ドロップして、スプリントにバグを割り当てることができる

Note

• バグはタスク カテゴリに割り当てられます
• ユーザー ストーリー (アジャイル)、プロダクト バックログ項目 (スクラム)、または要件 (CMMI) は、バグの自然な親作業項目の種類です
• バグは配信計画に表示されません

---

バックログまたはボードにバグを表示しない

• クエリを使用してバグを管理する

Note

• バグはバグ カテゴリに関連付けられ、バックログまたはボードには表示されません
• バグは、バックログ、ボード、スプリント バックログ、タスクボード、または配信計画に表示されません
• バグを [計画] ペインにドラッグ アンド ドロップして、スプリントにバグを割り当てることはできません

---

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

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

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

プロセスをカスタマイズする前に、「Azure Boards の構成とカスタマイズ」を確認することをお勧めします。

特定のプロセスのカスタマイズについては、継承プロセスのカスタマイズに関する記事をご覧ください。

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

複数の異なる 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 を Resolved、#323 と #324 を Closed に設定しています。

Azure DevOps 全体の統合

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

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

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

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

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

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

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

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

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

(YAML ではなく) クラシック パイプラインを使っている場合は、ビルド エラーで作業項目を作成できます。 詳細については、エラー時に作業項目を作成するビルド オプションに関する記事をご覧ください。

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

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

クエリ、グラフ、ダッシュボードについて詳しくは、マネージド クエリ、グラフ、ダッシュボードに関する記事をご覧ください。

Analytics ビューと Analytics サービスを使用してバグ レポートを作成する

Analytics サービスは Azure DevOps のレポート プラットフォームであり、SQL Server Reporting Services に基づく以前のプラットフォームを置き換えるものです。

Analytics ビューは、作業項目を表示するための事前構築済みのフィルターを提供します。 バグ レポートについては、4 つの Analytics ビューがサポートされています。 これらのビューは、定義どおりに使うことも、さらに編集して、フィルター処理されたカスタム ビューを作成することもできます。

• バグ - 月別のすべての履歴
• バグ - 過去 26 週間
• バグ - 過去 30 日間
• バグ - 今日

Analytics ビューの使用について詳しくは、「Analytics ビューとは」と「カスタム Analytics ビューに基づいて Power BI でアクティブなバグのレポートを作成する」をご覧ください。

Power BI を使うと、クエリから取得できるものより複雑なレポートを作成できます。 詳細については、Power BI データ コネクタでの接続に関する記事をご覧ください。

Marketplace 拡張機能

複数のバグ関連の Marketplace 拡張機能があります。 Azure DevOps に関する Marketplace をご覧ください。

拡張機能について詳しくは、Microsoft によって開発された Azure Boards 拡張機能に関する記事をご覧ください。

次のステップ

テンプレートを使って作業項目を追加および更新する

関連記事

• 作業項目の移動、種類の変更、または削除
• 作業項目をコピーまたは複製する

プロダクト バックログとかんばんボード

• バックログ、ポートフォリオ、アジャイル プロジェクト管理
• バックログの作成
• フィーチャーとエピックを定義する
• バックログを整理し、子作業項目を親にマップする
• バックログ、ボード、クエリ、計画を対話的にフィルター処理する
• プロダクト バックログを予測する

かんばんボード

• ボードとかんばんについて
• かんばんボード クイックスタート
• カードの並べ替え
• タスクまたは子項目をチェックリストとして追加する

スプリント バックログとタスクボード

• スクラムとスプリントの使用のベスト プラクティス
• バックログ項目をスプリントに割り当てる
• タスクの追加
• タスクボードの更新

Azure DevOps 内の統合

• ユーザー ストーリー、問題、バグ、その他の作業項をリンクする
• 作業項目または pull request をフォローする
• 実行番号またはビルド番号を構成する

業界リソース

• 良い技術的負債と悪い技術的負債 (および TDD の利用方法) (投稿者: Henrik Kniberg)
• 技術的負債の管理 (投稿者: Sven Johann、Eberhard Wolff)