バグレベルを定義する
「第2回：紙か？ Wordか？ Excelか？ BTSか？」では、バグ管理におけるバグ情報を集約する重要性について解説した。
管理者のもとに集められたバグは、「バグかどうかの確認」を行い、バグと認められたものについて「バグ対応の優先順位付け（バグのレベル定義）」を行う。
バグかどうかの確認
報告されたバグは、まずバグ票の記載に従い再現するかどうかの確認を行う。もし、この再現性の確認で、バグ票に記載されている動作が再現しなければ、そのバグはステータスを「再現待ち」もしくは「VOID」にしておく。
バグ情報の整理
ここでバグ票の内容が再現されても、バグとして判断されない場合がある。それは「確認した環境に問題があった」「データに問題があった」「仕様であった」のようなパターンである。
確認した環境に問題があった
バグの発見者の利用PCや接続先のサーバの設定が、本来あるべき設定ではなかった場合に、アプリケーションが想定外の動作をし、バグとして報告されるパターンだ。利用PCのproxyの設定やhostの設定、ネットワークの設定を確認する必要がある。
またWebアプリケーションの場合は、テスターが利用していたWebブラウザがテストで指定したものでなかったり、テスターが独自の設定を行ったりしていることもあるので、確認する必要がある。
データに問題があった
テスト用の不正なデータがデータベースに登録されており、それがアプリケーションのバグとして報告されるパターンだ。バグを引き起こす異常なデータがアプリケーションから作成されていたとしたら、それはデータを作成する部分のバグである可能性がある。
仕様であった
報告された内容がアプリケーションの仕様であったというパターンだ。仕様を知らないテスターをテストの期間だけ集めてきた場合によく発生する。テストの規模が大きくなったり、アプリケーションの動作に不可思議な部分が多い場合、このパターンのバグ報告が多くなる。
このようなケースでは、バグの確認作業およびテスターへのアプリケーションの仕様説明に想定以上に手間がかかる可能性があるので注意が必要だ。
また、このようなバグはここでバグとは判断しなくても、ユーザとして利用したときに「なんだかおかしい」と感じてあげられた内容であるので、後で仕様変更として対応できるようリスト化しておくとよいだろう。
バグ票の記載内容をチェックする
先ほど述べたように、バグ票の記載にしたがって再現性の確認を行うので、バグ票にはバグを再現できる具体的な動作手順が記載されていなければならない。再現する手順として、発見者の口頭での補足や発見者自らの操作が必要であるといった特殊なものは、バグ票として必要条件を満たしていないのである。
スケジュール的に余裕がなくなってくると、このバグ票の記載が甘くなる傾向になるので注意が必要だ。割れ窓理論ではないが、一度その状態を許してしまうとなし崩し的にバグ票に記載せずバグを修正するなどの行為が当たり前になってきてしまい、実質バグ管理ができない状態になってしまう。管理者はしっかりとチェックする必要があろう（参考「割れ窓理論 - Wikipedia」）。
次に、バグとして判断されたものについてバグ修正の優先順位を決める。 
次のページ
