ソフトウェアテストにおけるバグ/欠陥のトリアージ
編集チーム
⚡ スマートサマリー
欠陥トリアージとは、テストリーダー、開発リーダー、プロジェクトマネージャーが、報告された各バグを深刻度、優先度、リスクに基づいてランク付けし、担当者を割り当て、現実的な修正スケジュールに合意するレビュー会議のことです。
「欠陥トリアージ」とは何ですか?
欠陥トリアージとは、各バグの深刻度、頻度、リスクなどに基づいて優先順位を付けるプロセスです。トリアージという用語は、 ソフトウェアテスト 品質保証部門は、新規不具合の深刻度と優先度を定義する。
この名称は救急医療から借用されたもので、限られたリソースの中で患者を緊急度に応じて振り分けるトリアージに由来する。品質保証チームも同様の制約に直面する。つまり、不具合リストは常にリリース日までの時間よりも長いため、どの不具合を今すぐ修正し、どの不具合を後で修正し、どの不具合を後回しにするかを誰かが決定しなければならない。トリアージとは、その決定を下し、記録する会議のことである。
なぜ「欠陥トリアージ」が必要なのでしょうか?
バグトリアージの目的は、欠陥を評価し、優先順位を付け、解決策を割り当てることです。 チームは欠陥の重大度を検証し、必要に応じて変更を加え、欠陥の解決を最終決定し、リソースを割り当てる必要があります。 主にアジャイルプロジェクト管理で使用されます。
トリアージがなければ、欠陥は trac報告するテスターがたまたま選択した深刻度に応じて、ker が報告され、開発者はビジネスへの影響よりも個人的な好みで作業を選択します。以下のバナーは、チームが会議をカレンダーに残しておく理由をまとめたものです。
リリースでは「欠陥トリアージ」をどれくらいの頻度で実施する必要がありますか?
欠陥トリアージ会議の頻度は固定されていません。 プロジェクトの状況により異なります。
欠陥トリアージ会議の頻度を決定する重要な要素をいくつか示します。
これらの重要な要素は次のとおりです。
- プロジェクトスケジュール通り
- システム内の欠陥の数
- チームメンバーの空き時間のスケジュールへの影響
- プロジェクト全体の健全性
通常、欠陥トリアージ会議は週に XNUMX ～ XNUMX 回開催されます。
リリースが近づくにつれて、ペースが速くなる。 スクラム イテレーションでは、最後のスプリント中に短いトリアージを日常業務に組み込むことが多いが、より長い計画主導型サイクルのプロジェクトでは、 回帰試験 フェーズが始まります。
「欠陥トリアージ」の必須参加者およびその他の参加者は誰ですか?
必須参加者
不具合トリアージ会議には以下のプロジェクトメンバーが必ず参加します。
- Project Manager
- テストチームリーダー
- テクニカルリード
- 開発チームリーダー
任意の参加者
- 開発者向け
- テスター
- ビジネスアナリスト
オプションの参加者は、特定の不具合について意見が必要な場合に招待されます。例えば、ビジネスアナリストが、報告された動作が実際に要件に矛盾しているのか、それとも変更要求を偽装したものなのかを確認する必要がある場合などです。
「欠陥トリアージ」中の参加者の役割と責任。
必須参加者はそれぞれ異なる役割を担っており、会議は3人全員が事前に準備を整えた場合にのみ時間通りに進む。
テストチームリーダー
- バグトリアージ会議をスケジュールし、出席者に会議通知を送信します。
- 欠陥レポートを作成し、会議の前にすべての出席者に送信します。
- 優先順位を割り当てて 重症度 欠陥の。
- 他のメンバーが欠陥の根本原因を理解できるようにプレゼンテーションを行います。
- すべての会議メモがキャプチャされ、会議出席者に送信されます。
開発リード
- 欠陥の優先順位付けに役立ちます。
- 欠陥の難しさについて話し合い、その欠陥に伴うリスクについて説明します。
- 欠陥を修正する作業を関連する開発者に割り当てます。
- 欠陥の解決策を更新し、情報が不足している場合や開発者が必要とする追加情報がある場合に備えて、開発メモを含めます。
Project Manager
- 欠陥の優先順位付けに役立ちます。
- QA の次のイテレーションのリリース日について話し合います。
- 関連するユーザーの代表者もバグトリアージ会議に招待されていることを確認する必要があります。
プロジェクトマネージャーはリリース日を決定する権限を持っているため、異議申し立てのあった不具合に関する最終決定権は通常、その役割にある。以下に示すように。
「欠陥トリアージ」会議では何が行われますか?
- テスト チームのリーダーは、新しい欠陥を含むバグ レポートを送信します。 欠陥トリアージ会議では、各欠陥が分析され、適切な優先順位と重大度が割り当てられているかどうかが確認されます。
- 必要に応じて優先順位が再調整されます。
- 欠陥を分析し、重大度によって評価します。
- これには、欠陥の複雑さ、リスク、拒否、エラーの再割り当てに関する議論が含まれます。
- 更新内容はバグに記録されています tracキングシステム。
- QA エンジニアは各欠陥に変更を加え、各出席者とそれについて話し合います。
- 「コメント」フィールドは、会議の重要な点をメモすることで正しく更新されます。
議論時間のほとんどは、最も混同されやすい2つの分野に費やされる。深刻度と優先度は独立して設定され、欠陥は一方では高いスコアでも、他方では低いスコアになる可能性がある。
| 側面 | 重大度 | 優先 |
|---|---|---|
| 測定対象 | 欠陥が製品またはその機能にどの程度深刻な損害を与えるか | 他の作業との比較において、欠陥をどれだけ早く修正する必要があるか |
| 通常はによって設定されます | 欠陥を報告するテスター | トリアージで合意され、プロジェクトマネージャーと製品側が主導した。 |
| 駆動される | 技術的な影響と影響を受ける機能 | ビジネスへの影響、顧客認知度、リリース日 |
| 不一致の例 | 深刻度は高いが優先度は低い：次の四半期まで誰も使わない機能でのクラッシュ | 深刻度は低いが優先度は高い：ランディングページに会社名のスペルミスがある。 |
ヒント： 一つの不具合に関する議論は短時間で済ませましょう。数分で解決できない問題がある場合は、いったん保留にして担当者を任命し、次のセッションで改めて取り上げるようにしてください。一つの不具合に会議の時間を費やしてしまうのは避けましょう。
「欠陥トリアージ」の結果は何ですか?
すべての会議の終わりに、欠陥トリアージ メトリックが作成され、すべての出席者に提供されます。 このレポートは会議の議事録として機能し、今後の会議に役立ちます。
この報告書は、トリアージがより広範な医療システムと連携するポイントである。 欠陥管理プロセスチームは一般的に以下の内容を記録します。
- セッションで確認された不具合について、それぞれ合意された深刻度と優先度を決定した。
- 新たに割り当てられた不具合と、それらを現在所有している開発者。
- 欠陥品は、理由を添えて、保留、拒否、または重複品としてマークされます。
- セッションごとの傾向を把握できるよう、深刻度別の未解決の不具合件数を表示します。
- 次回の会議に持ち越された事項。
すべての変更は tracker、各アイテムの状態は、その位置と一貫しています。 欠陥ライフサイクルそして、次のセッションは、古いリストではなく、正確なリストから始まる。
