Defect Triage とは？
Defect Triage とは、テスト担当者がバグを見つけてリスク、再起、深刻度の程度をそれに割り振るプロセスです。 この度合いによって、基本的に最初に治療すべきバグの優先順位が決まります。
ただし、トリアージは医学用語で、基本的に試験または試運転を意味します。 救急部に到着すると、最初の医療評価は看護師によって行われます。
救急部では、通常トリアージルームで行われます。 この間、患者が自分の問題を看護師に説明し、次に何が必要かを正確に評価できるようにすることが非常に重要です。
別の人の医学的状態の重大性や緊急性に基づいて、その人はあなたよりも早く引き取られるかもしれません。 これはまさに、ソフトウェア テスターが欠陥またはバグのトリアージを行うときに起こることです。
彼らはそれぞれのバグに重大度の度合いを割り当て、より深刻に見えるバグ、またはシステムの完全性を損なう可能性がより高いバグが最初に考慮されるのです。
欠陥トリアージ会議
トリアージ会議はQAリードが進行し、ビジネスアナリスト、ITリード、プロジェクトマネージャー、あるいは製品マネージャーと調整される。 このトリアージ会議の主な目的は、問題を分類し、優先順位を付け、追跡することです。
トリアージ会議は、プロジェクトの規模、プロジェクトの状況、スケジュール、および欠陥の数に応じて、頻繁に、ときには1週間に3～4回行われます。 複数の要因が、バグを完全に除去するために必要なトリアージ ミーティングの回数を決定するのに重要な役割を果たします。
最良の結果を得るために、QAリーダーはミーティングごとに、既存の欠陥または新しい欠陥を含むバグレポートを送信する必要があります。
ミーティングでは、各バグが3つのカテゴリのいずれかに分類されます：
- IMMEDIATE ACTION TO FIX THE BUG: 欠陥は2つの理由でこのカテゴリに分類されます。
- ACTION ON THE BUG AT A POINT LATER IN TIME（ある時点からバグを修正する）：このカテゴリに入る理由は2つあります。
- ACTION ON THE BUG AT POINT IN TIME: バグはこのカテゴリに分類され、チームはそれが何か大きなものではなく、いくつかの時間の後に処理することができると知っています。 これは基本的に、バグが非常に軽微で、システム全体に影響を与えないことを意味します。
Steps in Defect Triage
トリアージチームは、プロジェクトマネージャ、テスター、テストリード、開発者、環境マネージャ、テストマネージャ、ビジネスアナリストで構成されます。 欠陥のトリアージには、欠陥のレビュー、欠陥の評価、欠陥の割り当ての3つのステップがある。 各ステップについて、以下で詳しく説明します。
- 欠陥レビュー：上記のすべての担当者は、各欠陥の原因と結果を深く掘り下げ、それらを修正しようとします。 このステップでは、不具合は修正予定と保留の2つのカテゴリに分類されます。 欠陥の重大性がこの分類の主な根拠となる。 上記の担当者は、どの欠陥を直ちに処理し、どの欠陥を保留にするかをまとめて決定します。 最初に処理する必要のある欠陥のリストができたので、チームは各欠陥を関係者に割り当てる。
Roles and Responsibilities of each Member in the Triage Team
- TEST LEAD: テストリーダーはすべてを開始する人である。 テスト担当者は、詳細な欠陥レポートと一緒に、すべてのトリアージメンバーに正式な招待状を送ります。 テスト リーダーは、各欠陥を特定し、その深刻度を割り当てる最初の人物です。 テストリードの主な役割の1つは、トリアージチームに対して、各不具合についてより深く理解できるようなプレゼンテーションを準備することである。 このプレゼンテーションは、チームメンバーが問題の根源に迅速にたどり着くのに役立つ。
- プロジェクトマネージャー：プロジェクトマネージャーは、欠陥の優先順位付け、欠陥リストの作成、および会議全体の調停において極めて重要な役割を果たす。 また、トリアージチームのメンバー全員が議論に参加できるようにする。
- DEVELOPMENT TEAM LEAD: 開発チームのリードとプロジェクトマネージャは、まとめて欠陥の優先順位を決める。 開発リードの主な役割は、関係するリスクと各欠陥の複雑さのレベルを伝えることである。
チームには他のメンバーもいるが、プロジェクトマネージャー、テストリード、開発チームリードがキーパーソンである。
トリアージミーティングでは何が行われるのか？
欠陥トリアージミーティングは、事前ミーティング、ミーティング中、事後ミーティングの3つの部分に分けられる。 ミーティングが始まる前に、テストリードはトリアージチームの全メンバーにレポートを送り、最新のバグについてある程度知ってもらう。 テスターは事前ミーティングで重要な役割を果たす。 テスターはバグに関する情報をチームに提供し、彼らは重要度と優先度に基づいて各バグを異なるセクションに分類します。 ですから、基本的にプレミーティング・セッションはテスターが所有するものです。 ミーティング中: ミーティングですべての問題が解決されるとは限りません。 新しい課題に移る前に、前の欠陥トリアージミーティングからのいくつかの保留課題が議論される。 そして、前の問題の進捗状況が話し合われる。 この時点から、既存の欠陥の深刻度について、あらゆる点がメモされる。 チームメンバーは、どの不具合をすぐに修正し、どの不具合を後日に延期するか、まとめて判断する。 締め切りが近い場合は、深刻度の高いバグを先に処理し、深刻度の低いバグは保留にします。 しかし、納期のプレッシャーがなければ、どんなに些細なバグでもプロジェクトの開始時に修正することができる。 これを元にバグリストが更新され、ここでタスクの割り当てが行われる。 ミーティングでは、テストリードが最後に発言します。 彼はミーティング全体をすばやく要約し、それぞれのチームメンバーに当面の行動方針を伝えます。 MOM（会議の議事録）は、会議終了後、欠陥トリアージチームに共有される。 このドキュメントには、ミーティング中に議論された重要なポイントが含まれています。
Contents of a Bug Triage Report
- DEFECT ID:
- DEFECT DESCRIPTION: これは、欠陥がどのようにシステムで誤動作を引き起こすかに関連しています。
- CREATION DATE: これは、バグが最初に気づかれた日です。
- CREATOR: 作成者は、最初にバグに気づき報告した人です。
- SEVERITY: これは、バグがどれくらい深刻かを示す指標です。
- PRIORITY: 優先度は高、中、低のいずれかになるでしょう。 高優先度は、そのバグが即時の対応を必要とすることを意味し、中優先度は、そのバグがしばらくしてから解決でき、即時の対応を必要としないことを意味し、低優先度は、そのバグがプロジェクトに重大なまたは顕著な影響を与えないため、解決されるかどうかがわからないことを意味します。
- ASSIGNMENT DATE: バグが解決のために各担当者に割り当てられた日付です。
- RESOLUTION: バグを解決するために行われていること.
- DATE OF RESOLUTION: 欠陥が完全に解決される推定日.
- ESTIMATED TIME: 欠陥解決にかかる推定時間.
- ACTUAL TIME: バグの解決にかかる推定時間です.
- このフィールドはバグ解決のために割り当てられた人物の名称.
- 解決日.このフィールドはバグが解決のために割り当てられた人の名前を示します:
- ROOT CAUSE DESCRIPTION: このフィールドには、なぜバグが最初に現れたかに関連する情報があります。
RESOLUTION: 障害の解決のために行われていること.
Why do We Need Defect Triage?
このプロセスから得られる主な利点は、チームがバグの重大性を評価し、それを釣り出す計画を考案して、プロセスに割り当てられるべきリソースに関して結論を出すことができるようになることです。 欠陥のトリアージは主にアジャイルテスト手法で使用される
CONCLUSION
欠陥を解決するために、欠陥のトリアージ会議が召集される。 トリアージチームのメンバー全員のうち、テストリード、プロジェクトマネージャー、開発チームリードが出席しなければならない。
欠陥トリアージ会議は、事前会議、会議中、会議後の3段階で完了する。
レポートには、欠陥が最初に気づいたときから、欠陥の根本原因までのすべての情報が記載されている。 週単位、月単位、あるいは日単位で組織することができる
。