優先度の分類を補完するためにバグの重大度を分類する方法は？

私の現在の仕事では、優先度が低、中、高のバグがあります。

• 優先度の低いバグは、出荷を停止したり、ユーザーに深刻な問題を引き起こしたりしない小さなエラーです。
• 中優先度のバグは、一部の内部ユーザーに問題を引き起こしますが、既知の回避策があります。
• 優先度の高いバグとは、お客様が目にする問題、データの破損、システムのクラッシュを引き起こす可能性のある問題です。

優先度の分類を補完するためにバグの重大度を分類する方法は？

優先度と重大度の両方に応じて、バグと欠陥を分類します。

優先度レベルは、問題の修正/修正の緊急度（緊急、高、中、低、なし）に関する指標です。

重大度レベルは、欠陥によって引き起こされる損害の程度または種類を特定するのに役立ちます（危険/破壊的、劣化、回避策なし、影響を受けるが回避策は存在する、迷惑/化粧品、影響なし）。

通常、バグの危険性と破壊性が高いほど、優先度が高くなります。ただし、保証されません。その結果、時折バグが危険で破壊的なものとしてリストされることがありますが、状況の希少性、またはそれを修正するために必要な変更の量により、理論的にはその優先度は非常に低くなります。

厳しさは、あなたが作る製品の種類とあなたのビジネスにとって本当に主観的です。私の最後の仕事で、大型コンテナ船やクルーズ船の自動操縦を行ったため、深刻度は

• 非常に高い-Iceberg Ahead！ああ、待って、船の制御が失われるか、誰が制御するかを混乱させるかもしれません！誰かがこの船を好転させる方法を見つけます!!!
• 高-顧客受け入れの苦情、クルーズ船の回転が速すぎる、顧客が飲み物をこぼす。これが修正されるまで、あなたのものを使用することはできません！
• 中-顧客/フィールド技術者の使いやすさを向上させる機能。人々の時間を節約するもの。
• 低-化粧品

Webアプリを作成していて、ビジネスモデル/顧客ベースがまったく異なる場合、重大度/優先度のレベルは大幅に異なると思います。最終的には、顧客が何を期待しているのか、問題についてどの程度怒っているのかについてです:)

私が使用する重大度基準：

• ユーザーがプログラムから必要なものを取得できないようにしますか？
• ユーザーが一般的なタスクを実行する場合に表示されますか？
• 賢明な情報を明らかにしたり、不正な操作を実行したりすることはできますか？

特定のバグの重大度は、これらのポイントの組み合わせです。

迷惑要因によってバグを分類します。これにより、ソフトウェアの購入を阻止できます。出荷に影響を与えないか、ユーザーに実際のトラブルを引き起こすバグは、バグに遭遇するたびに私を悩ませます。そして、最終的にユーザーと収入の一部を失いました。

そのようなバグを、明確な理由もなく、ユーザーに目に見える利益もなしに変更されたユーザーインターフェイスと組み合わせると、ユーザーがソフトウェアを嫌う絶対的な勝者が得られます。

それが起こるのを許さないでください。****を提供しないと顧客に思わせるバグを同梱しないでください。