バグトラッキングのための10のヒント
Joelさんが言うには・・・
1.良いテスタは再現手順を最小限のステップに絞込む。
これはバグを見つけなければならないプログラマにとても助けとなる。
2.バグレポートを完了できるのはそれを公開した人だけだというのを覚えておくこと。
誰でもそれを解決はできるかもしれないが、見つけたバグがフィックスされたと本当に確認できるのは、
それをはじめに見つけた人だけだ。
3.バグを解決する方法はたくさんある。
FogBUGZはバグを修正済み(fixed)、修正しない(won't fix)、
延期(postponed)、再現せず(not repro)、
重複したエントリ(duplicate)、仕様(by design)に分類できる。
4.「再現せず」は誰もそのバグを再現できないことを意味する。
バグレポートに再現手順がない場合にプログラマはしばしばこれを使う。
5.あなたは注意深くバージョンを管理しておきたいと思うだろう。
テスタに渡すソフトウェアのビルドにはそれぞれビルドIDをつけておくべきで、
哀れなテスタがバグをフィックスしていないバージョンでバグのテストをするようなことがないようにする。
6.あなたがプログラマで、テスタにバグデータベースを使ってもえらずに困っているのなら、
他の手段によるバグレポートの受け取りを拒めばよい。
テスタがバグレポートをemailで送ってよこすなら、
「emailを整理しきれないのでバグデータベースのほうに入れてください」という簡単なメッセージとともに送り返せばよい。
7.あなたがテスタで、プログラマにバグデータベースを使わせることができないなら、
バグについて直接彼らに教えないで、それをバグデータベースに入れ、バグデータベースからemailで通知が行くようにすればよい。
8.あなたがプログラマで、ほんの一部の同僚しかバグデータベースを使っていないなら、
ただデータベースのバグレポートを彼らに割り当て始めればよい。
彼らもいつかはヒントに気づくだろう。
9.あなたがマネージャで、あなたが大枚はたいてインストールしたバグデータベースを誰も使っていないようなら、
新機能の開発をバグレポートを使って割り当てればよい。
バグデータベースは優れた「未実装機能」データベースでもあるのだ。
10.バグデータベースに新しいフィールドを追加するという誘惑を排除すること。
毎月、誰かがデータベースに入れる新しいフィールドのアイディアを考え出すだろう。
たとえばバグが見つかったファイルを記録するとか、
バグが何%の確率で再現するかとか、
バグが何回起こったかとか、
正確にどのバージョンのどのDLL がバグの起きたマシンにインストールされているかといった、
あらゆる種類の気の利いたアイディアを得るだろう。
重要なのはこれらのアイディアを聞き入れないということだ。
もしそれをやると、あなたの新しいバグレポート入力画面は、
設定しなければならない何千ものフィールドでいっぱいになり、
もはや誰もバグレポートを入力したがらなくなるだろう。
バグデータベースが機能するためには、
誰でもそれを使える必要があり、
もし公式にバグレポートを入力するのに手間がかかりすぎるなら、
みんなバグデータベースを避けるようになる。