答え。

問題の歴史:

テスト初期段階では、バグは体系化せずに修正されることが多かった。ソフトウェアが複雑化し、タスクやバグトラッキングが増えるにつれて、重要な問題にリソースを最優先で投資するための合理的な優先順位付けの必要性が出てきた。

問題:

優先順位付けがなければ、テスター、マネージャー、開発者は小さなバグに時間を費やし、財務的または評判的な損失を引き起こす可能性のあるクリティカルなエラーを見逃すことになる。

解決策:

優先度システムの導入：

• バグの優先度は「クリティカル」、「高」、「中」、「低」（または同様のレベル）に分かれる
• 優先度は、ビジネス、ユーザー、システム全体に対するバグの影響に基づいて決定される
• 大規模なチームでは、プロダクトマネージャーと共同で行う

主な特徴：

• 重要なビジネス欠陥に集中することで、時間とリソースの節約
• QAチーム、開発、ビジネス間の対立を回避
• 状況の変化に応じて、優先順位の柔軟な見直し

トラップのある質問。

バグの優先順位は、欠陥の重大性によるのか、ビジネスの優先順位によるのか？

両方の要因による場合がある。技術的には小さな重大性のバグでも、ビジネスにとってはクリティカルなことがある（例：決済ページの価格エラー）。

同じ重大性のバグがすべて同じ優先順位を持つべきか？

いいえ、使用文脈、発生頻度、キーなビジネス指標への影響を考慮することが重要です。

バグの優先順位は時間とともに変わる可能性があるか？

はい、プロジェクトの進展、リリース計画の変更、新しい要求やユーザーからのフィードバックによって、優先順位は変わる可能性があります。

一般的な間違いやアンチパターン

• すべてのバグに均等に高い優先順位を付けること
• PO/ビジネスの参加なしにQA内部で優先順位を話し合うこと
• 実際にはクリティカルな「低い」優先度のバグを無視すること

生活の例

ネガティブケース

eコマースサイトでは、小さなビジュアルバグが最大優先度でバグトラッカーに登録され、決済統合の障害に関するバグは最小優先度で扱われていた。

利点:

• サイトの美しい外観を迅速に修正

欠点:

• 美しい外見にもかかわらず、機能しない決済による収入損失

ポジティブケース

チームでは優先順位を共同で決定し、支払いと重要な機能の作業を妨げるバグは「クリティカル」とマークされ、最初に取り組まれました。

利点:

• ビジネスにとってクリティカルな問題が解消される
• 明確で理解しやすい作業プロセスが確立される

欠点:

• ビジネスとの議論には時々多くの時間がかかるが、それにより将来的な争いと誤解が減る。