ホームページ上の会社名のスペルミスと、めったに使用されないエクスポート機能のクラッシュ: どちらを最初に修正しますか?このような議論がテストチームを分離する理由です重大度と優先度。 1 つは技術的な損害を説明し、もう 1 つはビジネスの緊急性を説明します。

この区別がなければ、すべてのバグは「重大」というラベルが付けられ、そのラベルは意味を失い、開発者はラベルを信頼しなくなります。このガイドでは、明確な定義と例、およびこれらの決定を下すための簡単なプロセスを説明します。例は例示的なものであり、正確な規模はチームやツールによって異なります。

短い答え

重大度の回答: このバグは製品にどの程度の悪影響を及ぼしますか?クラッシュやデータ損失は深刻ですが、表面上の不具合は深刻ではありません。

優先事項の答え: どれくらい早く修正する必要がありますか?それは、影響を受ける顧客、期限、収益、法的暴露、ブランドの評判によって異なります。

病院を考えてみましょう。重症度は、患者の状態がどれほど深刻であるかを表します。優先順位は患者が治療される順序であり、誰が安全に待つことができるか、どのリソースが空いているかなどの他の要因にも依存します。

重大度と優先度を並べて表示

重大度レベル

ほとんどのチームは約 4 つまたは 5 つのレベルを使用します。一般的なスケールは次のとおりです。

優先レベル

チームにとって各レベルが何を意味するかを書き留め、理想的にはそれぞれの目標応答時間を示します。 「P1 は、誰かが 1 時間以内に開始することを意味します」は、「P1 は非常に重要であることを意味します」よりもはるかに便利です。

4 つの組み合わせと例

これを理解する最も明確な方法は、各組み合わせを確認することです。

重大度が高く、優先度が高い

チェックアウトは誰にとっても失敗し、ビジネスは刻々と損失を被り、回避策はありません。これは明白なケースです。すべてを削除して修正してください。

重大度は高く、優先度は低い

従来の形式にエクスポートすると、アプリケーションがクラッシュします。技術的には、それは重大な失敗です。ただし、ごく一部のユーザーのみがこの機能に触れ、最新の形式が問題なく動作する場合は、予定されたリリースを待つことができます。

重大度は低く、優先度は高い

ホームページ上の会社名のスペルが間違っています。何も壊れておらず、データが危険にさらされることもありません。しかし、すべての訪問者がそれを目にすることになり、信頼が損なわれます。明日大規模なリリースが予定されている場合は、今日中に修正する必要があります。

重大度が低く、優先度が低い

めったにアクセスされないヘルプ記事に小さなタイプミスがありました。都合の良いときに修正してください。バックログがこれらでいっぱいの場合は、それらを 1 つのクリーンアップ タスクにまとめることを検討してください。

1 つのバグ、2 つの異なる優先順位

同じ欠陥でも、コンテキストに応じて異なる優先順位が与えられる可能性があります。注文確認メールが間違ったロゴで送信されたとします。

システムへの影響は同じであるため、重大度は変わりません。しかし、経営状況はそうなりました。時間は物事を変えることもあります。現在 P3 であるバグが、主要クライアントの稼働前週には P1 になる可能性があります。

重大度と優先度は誰が決定しますか?

• テスターは、動作を確認し、システムへの影響を理解しているため、通常、重大度を提案します。
• プロダクトオーナーまたはマネージャーは通常、顧客、収益、ロードマップを比較検討して優先順位を決定します。
• 開発者は、原因、修正のリスク、修正にかかる時間に関する情報を追加します。
• サポート チームは、影響を受ける顧客の数とその深刻さに関する証拠を提出します。

これらの責任はソースやチームによって異なり、小規模なスタートアップでは 1 人ですべてを行う場合もあります。重要なのは、誰が最終決定を下すかを誰もが知っているため、意見の相違は決定で終わるということです。

バグを評価する方法

不明な点がある場合は、次の質問に答えてください。

重大度については、次のとおりです。

1. データの紛失や破損、あるいは個人情報の漏洩はありますか?
2. main 機能の動作が停止しますか?
3. 回避策はありますか?通常のユーザーはそれを見つけることができますか?
4. 機能のどの程度が影響を受けますか?

優先順位としては:

1. 何人のユーザーが影響を受けますか?またどのユーザーが影響を受けますか?
2. 費用がかかりますか? それとも法的リスクやコンプライアンスのリスクが生じますか?
3. リリース、デモ、またはセールが近づいていますか?
4. それはどの程度目立つのでしょうか?また、評判を傷つける可能性がありますか?
5. テストなどの他の作業が妨げられますか?

バグトリアージの実行

トリアージは、チームが新しいバグをレビューし、次に何を行うかを決定する定期的な会議です。単純な形式がうまく機能します。

1. 準備します。 テスターは、それぞれの新しいバグに明確な手順、証拠、提案された重大度があることを確認します。
2. 確認します。 複製可能であり、重複していないか確認してください。
3. 決定します。 重大度に同意し、優先順位を設定し、所有者を割り当てます。
4. ループを閉じます。 各バグを拒否、延期、またはスケジュールし、その理由を記録します。

短く、頻繁に伝えてください。リリース前の最後の数日間は、毎日 15 分間のトリアージが一般的です。重大度と優先度もリリースの決定に影響するため、終了基準の一部として、「リリース時に未解決の S1 または S2 バグがない」などのルールに事前に同意してください。

バグレポートの重大度と優先度

短く明確なエントリは、誰もが適切な決定を下すのに役立ちます。

Title:    Checkout returns error 500 when a coupon is applied
Severity: S1 - blocks purchase, no workaround
Priority: P1 proposed - sale starts Friday
Build:    2.14.0, production
Reach:    All customers using a coupon (around 30% of orders)
Steps:    1. Add an item  2. Apply SAVE10  3. Click Pay
Result:   Error 500 and no order is created
Expected: Order is created with the discount applied

これらの数値は一例です。実際のレポートでは、ログから測定された数値を使用し、その推論を説明します。詳細については、バグ レポートの書き方に関するガイドをご覧ください。また、エラー コードの意味を知るのにも役立ちます。HTTP ステータス コードのチートシートを手元に置いておいてください。

よくある間違い

• これらを同じフィールドとして扱います。 2 つが常に一致すると、有用な情報が失われます。
• 注意を引くために重大度を誇張する。 すべてが重要な場合は、何も重要ではなくなります。
• テスターに​​優先順位を単独で設定させる。テスターがビジネス全体像を把握していることはほとんどありません。
• バックログを決してレビューしない。 優先順位は古くなるため、古いバグを定期的に再チェックしてください。
• 定義が書かれていない。定義がないと、人によってラベルの付け方が異なり、言葉について議論することになる。
• 重大度の低いパイルアップを無視する。 50 個の小さな問題があると、たとえどれも重大なものではなくても、製品が壊れているように感じられることがあります。

まとめ

2 つの質問を分けて考えてください。それはどの程度悪いのか、そしてどれくらい早く修正する必要があるのか​​ということです。各レベルの書面による定義に同意し、誰が決定するかを明確にします。次のステップとして、トラッカー内の最も古い 10 個のバグを取り出し、上記の質問を使用してそれらを再評価します。おそらく、移動すべきものもいくつか、閉鎖すべきものもいくつか見つかるでしょう。

よくある質問

学び続ける