バグの重大度（クリティカル/高/低など）をどのように定義しますか？
組織のバグの評価に関与していると仮定すると、それらのバグの重大度のさまざまなレベルをどのように定義しますか？
より具体的には、「重大度」に使用するさまざまな値は何ですか？バグに値を割り当てるために使用する基準は何ですか？
明確化：私はここで症状について話しているだけです。優先順位付けに影響を与える他のものを脇に置いておきましょう：バグを修正するのにかかる時間、チームの議題にある他のタスクなど。
会社はそれぞれ異なります。ここには5つのレベルがあります
- ブロッカー
- クリティカル
- メジャー
- マイナー
- ささいな
ほとんどの場合、ビジネステスターは問題の重大度を定義します。彼らはテストを行い、バグに遭遇すると、これが顧客と潜在的なリリースにどのように影響するかを判断し、それに応じて優先順位を割り当てます。最も厳しい項目を確認し、ビジネスがそれらを作成しているのと同じくらい深刻かどうかを確認します。ビジネステスターが「ブロッカー」のバグを何度か報告したことがありますが、詳しく調べたところ、それほど重要ではないことがわかりました。
まとめると、Blockerのバグはすぐに修正する必要があるバグです。これらは、その状態でリリースされた場合に製品が機能しなくなるバグです。
重大なバグは依然としてバグですが、通常はリリース後に適用できる回避策またはクイックフィックスがあります。
大きなバグには回避策があり、アプリケーションの機能に影響を与えることなく延期できます。
マイナーおよび些細な問題は、通常、拡張機能または「Nice to have」に予約されています。
これが物事を明確にするのに役立つことを願っています。
私は多くの企業で働いており、それらのほとんどには4つのレベルの重大度がありました（ただし、重大度と優先度を混同しないでください）。特定のバグ/欠陥がテスト中のシステムに与える影響のレベルとして重大度を考慮してください。常に次のコンテキストを考慮して影響を測定する必要があります。ユーザー数、ミッションクリティカルなシステム（原子炉、航空電子機器、医療機器）、金銭的損失または評判など。また、欠陥分類法を使用して支援することもできます（例：システムクラッシュかセキュリティの脆弱性か、表面的な問題か）
通常、ほとんどの企業は4つのレベルを使用します。5つ見ましたが、私の経験では、より複雑なものは適切に実装することがより困難であると私はお勧めします（3つは推奨されます）。 ）。
ここにリストがあります：
- S1-重大-影響が大きく、回避策はありません（システムクラッシュ、機能の不足など）
- S2-高/大-影響が大きく、回避策があります（たとえば、機能が別のブラウザーで機能しない）
- S3-中-中程度の影響（例：エラーメッセージは適切ではありません）
- S4-低/通常-低影響（例：表面的な問題、タイプミス、配置など）
私はそれがうまくいくことを願っています
これには基本的に2つのものが必要です。
- 重大度：これは重大なバグですか？または、表面的なエラーのように、それほど重要ではありません。
- 優先度：修正の緊急度はどのくらいですか？
これらの2つを考慮に入れると、最初に修正する必要のある素敵なリストが表示されます。
たとえば、重大度の低いバグは優先度が高くなる可能性があります。
お金について言えば、それは重要です。
それはそれが多くのことに依存する回数に依存します：
解決する時間
他の従業員の生産性をどのように変えるか
契約（バグが契約を破った場合、それは重要です）
データベースに不正なデータが入力/選択された場合、それは重大である可能性があります
それはまたあなたのビジネスに依存します。