テストにおける重大度と優先度の違い(例)
重大度 vs. 優先順位: 両者の違い
- 優先度は開発者が欠陥を解決する順序であり、重大度は欠陥が製品の動作に与える影響の度合いです。
- 優先度は低、中、高の XNUMX 種類に分類され、重大度は重大、重大、中程度、軽度、外観の XNUMX 種類に分類されます。
- 優先度はスケジュールに関連付けられ、重大度は機能または標準に関連付けられます。
- 優先度はバグをどれだけ早く修正する必要があるかを示し、重大度は製品機能上の欠陥の深刻さを示します。
- 欠陥の優先順位はマネージャー/クライアントと相談して決定され、欠陥の重大度レベルは QA エンジニアによって決定されます。
- 優先度はビジネス価値によって決定され、重要度は機能によって決定されます。
- 優先度の値は主観的であり、プロジェクトの状況の変化に応じて一定期間にわたって変化する可能性がありますが、重大度の値は客観的であり、変化する可能性は低くなります。
- 優先度が高く重大度が低いステータスは、欠陥を即時に修正する必要があるがアプリケーションには影響しないことを示し、重大度が高く優先度が低いステータスは、欠陥を修正する必要があるが即時ではないことを示します。
- 優先度ステータスは顧客の要件に基づいており、重大度ステータスは製品の技術的側面に基づいています。
バグの重大度とは何ですか
バグの重大度 テストにおける欠陥重大度は、バグまたは問題の影響の程度です。 欠陥 テスト対象のソフトウェア アプリケーション上にあります。 システム機能に対するバグ/欠陥の影響が大きいほど、重大度レベルも高くなります。 あ 品質管理 通常、エンジニアはバグ/欠陥の重大度レベルを決定します。
優先順位とは何ですか?
優先順位は、欠陥を修正する必要がある順序として定義されます。 優先度が高いほど、欠陥をより早く解決する必要があります。
ソフトウェア システムを使用不能にする欠陥は、ソフトウェアの小さな機能の障害を引き起こす欠陥よりも優先されます。
重大度の種類
In ソフトウェアテストバグ/欠陥の重大度の種類は、次の部分に分類できます。
- クリティカル: この欠陥はプロセスが完全にシャットダウンしたことを示しており、それ以上進むことはできません。
- 主要な:システムを崩壊させる非常に重大な欠陥です。 ただし、システムの特定の部分は引き続き機能します
- M: いくつかの望ましくない動作が発生しますが、システムはまだ機能しています
- ロー:システムに重大な障害を引き起こすことはありません
優先順位の種類
バグ/欠陥の優先度の種類は、次の XNUMX つの部分に分類できます。
- 低: 欠陥は刺激的ですが、より深刻な欠陥が修正されれば修復可能です
- 媒体: 開発活動の通常の過程で欠陥は解決されるはずです。 新しいバージョンが作成されるまで待つことができます
- 高: この欠陥はシステムに重大な影響を及ぼし、修正されるまで使用できないため、できるだけ早く解決する必要があります。
欠陥の重大度を判断するためのヒント
- 発生頻度を決定する: コード内で軽微な欠陥が頻繁に発生する場合、場合によっては、その欠陥がさらに深刻になる可能性があります。 したがって、ユーザーの観点からすると、たとえ軽微な欠陥であっても、それはより深刻です。
- 欠陥を分離する: 欠陥を分離すると、その影響の深刻度を確認するのに役立ちます。
テストにおける重大度と優先度の違い
優先 | 重大度 |
---|---|
欠陥の優先順位は、開発者が欠陥を解決する必要がある順序を定義します。 | 欠陥の重大度は、欠陥が製品の動作に与える影響の度合いとして定義されます。 |
優先順位はスケジュールに関連付けられます | 重大度は機能または標準に関連付けられています |
優先度はバグをどれだけ早く修正する必要があるかを示します | 重大度は、製品の機能上の欠陥の重大さを示します。 |
欠陥の優先順位はマネージャー/クライアントと相談して決定されます | QA エンジニアが欠陥の重大度レベルを判断します |
優先順位はビジネス価値によって決まります | 重大度は機能によって決まります |
その値は主観的なものであり、プロジェクトの状況の変化に応じて時間の経過とともに変化する可能性があります。 | その値は客観的であり、変更される可能性は低いです |
優先度が高く重大度が低いステータスは、欠陥を即時に修正する必要があるが、アプリケーションには影響しないことを示します。 | 重大度が高く、優先度が低いステータスは、欠陥を修正する必要があるが、即時に修正する必要はないことを示します。 |
優先ステータスは顧客の要件に基づいて決定されます | 重大度ステータスは製品の技術的側面に基づいています |
UAT 中に、開発チームは優先順位に基づいて欠陥を修正します。 | SIT 中に、開発チームは重大度、優先順位に基づいて欠陥を修正します。 |
優先度はXNUMX種類に分類される
|
重症度はXNUMXつのタイプに分類されます
|
欠陥の重大度と優先度の例
重大度が低く優先度が高い、またはその逆の例を見てみましょう。
- 重大度が非常に低く、優先度が高い: 出荷 Web サイトのロゴ エラー。Web サイトの機能には影響しないため、重大度は低くなりますが、これ以上出荷を続行したくないため、優先度は高くなります。間違ったロゴで。
-
重大度が非常に高いが優先度が低い: 同様に、航空運航 Web サイトの場合、予約機能の欠陥は重大度が高い可能性がありますが、次のサイクルでリリースするようにスケジュールできるため、優先度は低くなる可能性があります。
欠陥のトリアージ
欠陥トリアージは、テスト チームが利用可能なリソースが限られているという問題に直面した場合に、プロセスの再バランスを試みるプロセスです。 したがって、欠陥の数が多く、それらを検証するテスターが限られている場合、欠陥トリアージは、重大度や優先度などの欠陥パラメータに基づいて、できるだけ多くの欠陥を解決しようとするのに役立ちます。
欠陥トリアージを決定する方法:
ほとんどのシステムは、欠陥を評価するための主な基準として優先度を使用します。 ただし、適切なトリアージ プロセスでは、重症度も考慮されます。
トリアージプロセスには以下のステップが含まれます
- Revチームによって拒否された欠陥を含むすべての欠陥を表示する
- 欠陥の初期評価は、その内容とそれぞれの優先順位および重大度の設定に基づいて行われます。
- 入力に基づいて欠陥に優先順位を付ける
- プロダクトマネージャーが欠陥を正しいリリースに割り当てます。
- さらなるアクションのために、欠陥を正しい所有者/チームにリダイレクトします。
重大度を選択する前にすべてのテスターが考慮すべきガイドライン
重大度パラメータはテスターによって評価されますが、優先度パラメータはプロダクト マネージャーまたはトリアージ チームによって評価されます。 欠陥に優先順位を付けるには、テスターが開発チームとの混乱を避けるために適切な重大度を選択することが不可欠です。
- 優先度と重大度の概念をよく理解する
- 問題の優先度に影響するため、常に問題の種類に基づいて重大度レベルを割り当ててください。
- 特定のシナリオや テストケース エンドユーザーに影響を与える可能性がある
- 欠陥の複雑さと検証時間に基づいて、欠陥を修正するのにどれくらいの時間がかかるかを考慮する必要があります。
まとめ:
In ソフトウエアエンジニアリング, 欠陥に間違った重大度を割り当てると、 STLC プロセスが変化し、チームの全体的なパフォーマンスに劇的な影響を与える可能性があります。 したがって、責任者は、欠陥を割り当てる際に正確かつ正確である必要があります。