defect triage process
欠陥トリアージプロセスの完全ガイドと欠陥トリアージミーティングを処理する効果的な方法：
今日の記事では、欠陥トリアージ会議と、より簡単で効果的な方法でトリアージ会議を処理する方法について学習します。
この記事を進める前に、欠陥、欠陥ライフサイクル、および欠陥の意味をすべての人に知ってもらいたいと思います。 各欠陥の優先度と重大度を設定する方法 。そして、欠陥やバグに関連するこれらの基本的な概念を理解する必要があります。
私の以前の記事も読むことができます 「」 欠陥のライフサイクル そして 欠陥管理プロセス 「」 これらの概念をすばやく理解するため。
学習内容：
概要概要
言葉 「トリアージ」 基本的に医療分野で使用されています。実際、それは患者が治療されるべき順序を決定するために使用されました。通常、大規模な病院では、日常的に診察や実際の治療のために何千もの患者のアプローチがあります。しかし、すべての患者がすぐに入院または治療されるわけではありません。
病気やけがの重症度が相談の主な基準であり、これに基づいてすべての患者がそれに応じて分類されます。患者の怪我や健康が非常に重大である場合、医師は通常、そのような患者を優先事項として扱い、必要に応じて入院します。
正常な疾患または重大ではない傷害は優先度が低いと見なされ、そのような患者は後で治療されます。
同様に、トリアージという用語は、アプリケーションまたはプロジェクトの欠陥のソフトウェアテストで導入されています。通常、欠陥トリアージプロセスは大規模なプロジェクトで実装され、多くの場合、小規模なプロジェクトには適用できません。中規模または小規模のプロジェクトよりも大規模なプロジェクトでは、膨大な数の欠陥を特定する可能性があります。
また、大規模なプロジェクトでは、欠陥の特定の頻度が非常に高くなります。
欠陥トリアージ会議の結果を示し、次のような特定の質問に対する回答を提供する以下の画像をご覧ください。
欠陥トリアージ会議
トリアージ会議の主な目的は、すべての欠陥を追跡し、タイムリーに正しい解決策を確保することです。
アンドロイドのための良い音楽ダウンローダーは何ですか
テスト実行フェーズ中に、テスターは次のような欠陥管理ツールで欠陥の報告を開始します。 HP ALM 、QCなど。 欠陥トリアージ会議 開発者とテスターがすべての欠陥について話し合い、必要なさらなる行動を取るため、開発者とテスターが立ち会う必要がある場所で開催されます。
主に以下の参加者の立ち会いが義務付けられています。
例pptを使用したブラックボックステスト手法
- プロジェクトマネージャ
- テストリード
- 開発リーダーまたは開発者
- テスター
- テストマネージャー
- ビジネスアナリスト
- 環境マネージャー
会議のすべての参加者の完全なリストを示しましたが、ビジネスアナリスト、環境マネージャー、テストマネージャーなどのすべての参加者を毎日の会議に参加させる必要はありません。必要に応じて、テストリーダーまたはプロジェクトマネージャーが彼らを招待し、特定の欠陥に関する貴重なフィードバックや意見を共有できます。
そして、チーム全体はとして知られています トリアージチーム 。次に、トリアージ会議の正確なプロセスと、この会議の設定方法について説明します。
1つの架空の例を考えてみましょう ：銀行アプリケーションに関連するプロジェクトが1つあり、サイズが非常に大きく、欠陥を特定して報告する頻度が高くなっています。したがって、テストリードは、必要な参加者との欠陥トリアージ会議を設定することを決定します。
会議を設定するために、テストリードは全員に電子メールで会議の招待状を送信し、トリアージ会議の特定のタイミングを設定します。以下の架空の画像は、テストリードがOutlookを介してすべての参加者に送信した会議の招待状を示しています。
以下の画像では、参加者の名前、会議室、電話会議の詳細、日付、時刻など、すべてが架空のものです。
（（注意：画像をクリックすると拡大表示されます）
トリアージ会議の開始前に、テストリードはすべての「未解決」の欠陥のリストをスプレッドシート形式ですべての参加者に送信します。これにより、参加者は会議の前にすべての欠陥を調べて、欠陥が正確に何であるかを理解できます。それにどのような修正が必要か。
すべてのトリアージ会議を開始する前に、各欠陥を確認してください。
- 会議のすべての参加者の欠陥を理解するのに十分な情報があります。
- 正しいプロジェクトとカテゴリで報告しています。
- 欠陥の優先順位と重大度について言及しました。
- すべての参加者に正しく理解するために、欠陥で提供されたすべての詳細情報。
おすすめの読み物 => 欠陥管理プロセスの完全ガイド
欠陥トリアージテンプレート
すべての欠陥トリアージ会議のキックスタートの前に、テストリードは特定の形式ですべての参加者に欠陥レポートを共有し、レポートはHP ALM、HPQCなどの欠陥管理ツールから抽出されます。1つのサンプル形式を下の画像は、欠陥レポートテンプレートに記載されているフィールドの概要を示しています。
通常、欠陥レポートに含まれるフィールドは次のとおりです。
- 欠陥ID
- 説明
- 優先度
- 重大度
- 検出日
- 検出者
- 状態
リストは網羅的ではありませんが、プロジェクトのニーズに応じて、欠陥レポートテンプレートの他のフィールドを含めることができます。
通常、スプレッドシート形式は欠陥報告のテンプレートとして使用されるため、仮想的な欠陥の詳細をスプレッドシート形式で示しました。 上記の欠陥レポートで提供されるすべての情報は架空のものであり、プロジェクトや実際のアプリケーションに関連するものではないことに注意してください。
欠陥トリアージプロセス
テストチームでよく耳にし、経験する状況は、リソースの利用可能性が限られていることです。欠陥トリアージは、この現象の結果としてリバランスを行おうとするプロセスです。したがって、欠陥が多く、それらを修正/検証する開発者/テスターが限られている場合、欠陥トリアージは、優先度や重大度などの欠陥パラメーターに基づいて技術担当者のバランスをとることにより、できるだけ多くの欠陥を解決するのに役立ちます。
通常、欠陥トリアージセッションには、製品マネージャー、開発リーダー、テストリード、場合によってはビジネスアナリストが参加します。場合によっては、他の特定のメンバーを招待して、特定の欠陥に関する意見や見解を示すこともできます。これらはまとめてトリアージチームと呼ばれます。
ほとんどのシステムは、欠陥を評価するための主要な基準として優先度を使用しますが、適切なトリアージプロセスでは、重大度も考慮されます。
前のセクションで説明した2つの例を使用して、トリアージプロセスを詳しく見てみましょう。上記の両方の例で、実際には非常に高い優先度が与えられる最初の欠陥になります。外観上の欠陥に過ぎませんが、修正しないことによる影響は甚大です。
一方、2つ目は確かに機能上の欠陥ですが、その発生は、顧客のシナリオではめったに実行されない特定の条件でのみ発生します。それを修正するには、より多くの時間と人員が必要になる可能性があり、他の欠陥にうまく利用できる可能性があります。したがって、最初の候補よりも優先度が低く、おそらく別のリリースに延期されると見なされます。
したがって、トリアージプロセスには、トリアージチームが一緒に座って、拒否された欠陥を含むすべての欠陥を確認することが含まれます。彼らは、その内容、それぞれの優先順位、および重大度の設定に基づいて、欠陥の初期評価を行います。トリアージチームの各担当者が、欠陥に優先順位を付ける方法についての見解を示します。
次に、製品マネージャーはすべての入力に基づいて優先順位を設定し、欠陥を正しいリリースに割り当てます。現在のリリースまたは将来のリリースで。彼はまた、さらなるアクションのために欠陥を正しい所有者/チームにリダイレクトします。拒否された欠陥も同様の分析にかけられます。拒否の理由に基づいて、延期する必要があるかキャンセルする必要があるかという未来的な行動が決定されます。
トリアージ会議では、優先度の低いものとして分類された欠陥を含め、すべての欠陥について話し合う必要があります。トリアージチームのレビューでは、すべての欠陥を評価し、各欠陥に対して必要なアクションを実行します。欠陥の情報が不足している場合、開発者はそのような欠陥をテスターに割り当て、必要な情報を要求します。
すべての参加者が同じ場所にいる場合、トリアージ会議は会議室で開催できます。ただし、多くの組織では、作業は別の場所から実行され、すべてのチームがさまざまな場所に分散しているため、会議も電話会議またはビジネスSkypeを使用して開催されます。
( 画像 ソース )
欠陥トリアージ会議の段階的なプロセス：
- テストリードは、当日の早い時間に送信された欠陥レポートで会議を開始します。
- 議論は、前回のトリアージ会議で保留中のアクションから始まります。最初に、欠陥に対して実行された必要な更新またはアクションについて説明します。
- 欠陥レポートに新しい欠陥がある場合、これらの欠陥はレビューおよび評価されます。また、優先度と重大度が適切に割り当てられているかどうかを確認し、割り当てられていない場合は、会議で修正されます。
- 会議ではすべての欠陥について話し合い、開発チームは欠陥の修正の複雑さについても話し合います。欠陥に関連するリスクについても、トリアージチームが話し合います。
- トリアージチームは、どの欠陥に早急な対応と修正が必要であり、どの欠陥がしばらく待つ必要があり、必要に応じてそれらの欠陥を将来のリリースに延期できるかについて結論を出します。
- すべての欠陥は、会議中にQCまたはALMのそれぞれのチームに同時に割り当てられます。適切なコメントもQC / ALMに追加されます。
- 重要な更新とアクションアイテムはすべて書き留められ、テストリーダーは会議の終了を呼びかけます。
- トリアージ会議の完了後、テストリードはすべての参加者に会議の議事録を送信します。
役割と責任
各カテゴリに基づく役割と責任について、以下で説明します。
テストリード
- テストリードは、欠陥トリアージ会議をスケジュールし、必要なチームに正式な会議招待状を送信します。
- すべてのトリアージ会議の前に欠陥レポートを送信します。
- 前回のトリアージ会議で保留中のアクションアイテムを使用して会議を開始します。
- 欠陥が原因で機能がブロックされた場合は、各欠陥とスケジュールへの影響について話し合います。
- 以前に正しく割り当てられていなかった場合に、各欠陥の優先度と重大度を割り当てるのに役立ちます。
- 適切なコメントでQC / ALMを更新します。
- すべての更新、アクションアイテム、欠陥に関連するリスクなどを書き留めます。
- すべての参加者に会議の議事録を送信します。
開発リーダー/開発者
- 前回のトリアージ会議から保留中のアクションアイテムの最新情報を共有します。
- 技術的な観点からすべての欠陥について話し合います。
- 欠陥と機能の複雑さに基づいて、修正に必要な時間を特定します。
- 欠陥の複雑さと、欠陥に関連するリスクがある場合はそれについて話し合います。
- 開発リードは、利用可能なすべての詳細情報を検証した後、適切な開発者に欠陥を割り当てます。
- 欠陥を解決予定日で更新します。
- 欠陥の根本原因の特定を支援します。
プロジェクトマネージャ
- すべての地域のすべての代表者が会議に参加できるかどうかを確認します。
- 必要に応じて、プロジェクトマネージャーは、特定の欠陥についての意見を求めて、ビジネスアナリストを会議に招待します。
- 欠陥が動いていない場合、または主要なブロッカーがある場合は、エスカレーションプロセスでエスカレーションします。
- 必要に応じて、チーム間で紛争や対立が発生した場合に仲介者として機能し、必要な決定を下します。
- 修正された欠陥の次のリリース日については、開発チームから確認を受けてください。
- プロジェクトの更新されたスケジュールとリリース日をすべてのチームに知らせます。
場合によっては、他のチームメンバーをトリアージコールに参加させて、他のチームメンバーも会議を理解して貢献し、必要に応じてフィードバックを提供できるようにすることもお勧めします。
Macでトレントファイルを開く方法
結論
ログに記録されたすべての欠陥は、トリアージ会議で話し合う必要があります。
欠陥が拒否された場合でも、テストチームは拒否の理由を知っている必要があります。また、欠陥のいずれかが再現できない場合、トリアージ会議中に開発者はテスターにリアルタイムの詳細を要求し、欠陥の再現を試みることができます。
欠陥がいつ修正され、再テストできるようになるかは誰もが知っているため、欠陥のトリアージは重要です。いずれかの欠陥が重大ではなく、欠陥を修正するためには、開発チームの多大な努力が必要であり、決定はプロジェクトマネージャーが行います。
プロジェクトマネージャーはそのような欠陥の優先順位を決定し、必要に応じて欠陥を次のリリースに延期することができます。
欠陥トリアージ、欠陥トリアージプロセス、および欠陥トリアージ会議を効果的に処理する方法について明確なアイデアが得られたことを願っています。