バグの優先順位を付ける
優先順位を決めるといっても、バグ1つずつに修正する順番を付けるのではなく、「高」「中」「低」の3段階程度に分類する。では、どのようなバグを優先的に修正するのがよいのだろうか。
必要な項目としては「影響範囲」「データ更新の有無」「発生頻度」「関連バグの数」がある。また、これらの項目はシステムによって追加・削除されるので、プロジェクトによって適宜変更する。
| |
優先度低 |
優先度中 |
優先度高 |
| 影響範囲 |
- 1画面／1機能に閉じている
- エンドユーザの利用への影響が少ない
|
|
- システム全体に影響を与える
- エンドユーザの利用への影響が大きい
|
データ更新の
有無 |
|
|
|
| 発生頻度 |
- 特定の条件でないと発生しない
- バグが発生する画面／ 機能の利用回数が少ない
|
- 特定の条件（Webブラウザ／ユーザなど）だと毎回発生する
|
|
関連する
バグの数 |
|
|
|
バグの優先順位チェック表
影響範囲
影響範囲とは、そのバグが影響を与える画面／機能数である。ある画面内だけで完結するバグから、そのシステム全体の挙動に影響を与えるバグまで、一言でバグといっても与える影響範囲はさまざまだ。当然、影響範囲が大きい（広い）バグの優先順位が高くなる。
例えば、ある画面のあるボタンのラベル文字の漢字が間違っている、というのは優先順位が低いといえる。しかし、複数の画面から呼び出されている共通コンポーネントの計算ロジックが間違っている、というのは優先順位が高い。また、エンドユーザにとって重要な情報が画面上に表示されないといったエンドユーザのシステム利用に影響を及ぼすものは優先順位が高い。
データ更新の有無
データ更新の有無とは、そのバグによって不正なデータがデータベースやファイルに書き込まれるか否かである。
不正なデータが発生する場合、そのデータを参照する他の機能もバグの影響を受けることになる。そのため実際の運用中にこの手のバグが発覚したら、蓄積されている不正なデータ量を早急に見積もる必要があろう。
アプリケーション修正後、SQL1つで修正可能な程度のバグであればよいが、データ量が多いとSQLの実行速度にも影響を与える可能性が出てくる。また、後でまとめて対応しようとすると、データ修正が発生することになり、修正工数が大きくなるので注意が必要だ。
発生頻度
発生頻度は文字通り、システムを使っていると毎回発生するバグなのか、それとも特定のレアな条件のときに発生するバグなのかである。
特定のWebブラウザのヴァージョンで、かつ画面遷移がある特定のパターンのときに発生する、というような非常にレアな不具合は優先順位を低くしてもよい。
ただし、発生「頻度」なので、発生する確率が低くても、実行される回数が多い機能については、その分も考慮して優先順位を考える必要がある。例えば、同じ1,000分の1の確率で発生するバグだとしても、1日の利用回数が100回程度の機能と、100,000回程度の機能とでは当然後者の方が優先順位を高くなる。
関連バグの数
これはそのバグに関連するバグの数である。同じ原因で複数のバグが確認されている場合は、1箇所修正すればその他報告されている多くのバグが解決する。そのようなバグは優先度を高くする。
これら踏まえて作成したのが、バグの優先順位を決める際に参照するチェック表である（上図参照）。では、このチェック表を使って実際にバグの優先順位を決める手順を解説していこう。 
次のページ
