やさしいバグトラッキング を読んだ

memo

Joelさんの文章は読んでて普通に面白い(もちろん翻訳だけど)。すばらしいことだ。


バグトラッキングシステムは、PJに導入したり、自分で使ったりしたことがある。
うまくいったこともあったし、うまくいかなかったこともある。
「やさしいバグトラッキング」を読んで、なんとなく原因が分かった気がした。


良いバグレポートのルールはとても当たり前のことだけど、こうやって明確に書いてあるとわかりやすい。

良いバグレポートのルールを覚えるのは簡単だ。すべての良いバグレポートに必要なものは正確に3つだ。

  1. 再現する手順、
  2. 期待されること、そして
  3. その代わりに観察されたこと。
やさしいバグトラッキング

たしかにこれら書いてあれば、バグを直すのがかなり楽になると思う。
書いていないことが、それなりにあるということだけど。
こういうことを、会社の新人とかに教えてあげれば、お互いわかりやすくていいと思った。


そしてすごく共感したのは以下の文章。ちょっと長いけど、そのまま引用する。

バグデータベースに新しいフィールドを追加するという誘惑を排除すること。毎月、誰かがデータベースに入れる新しいフィールドのアイディアを考え出すだろう。たとえばバグが見つかったファイルを記録するとか、バグが何%の確率で再現するかとか、バグが何回起こったかとか、正確にどのバージョンのどのDLLがバグの起きたマシンにインストールされているかといった、あらゆる種類の気の利いたアイディアを得るだろう。重要なのはこれらのアイディアを聞き入れないということだ。もしそれをやると、あなたの新しいバグレポート入力画面は、設定しなければならない何千ものフィールドでいっぱいになり、もはや誰もバグレポートを入力したがらなくなるだろう。バグデータベースが機能するためには、誰でもそれを使える必要があり、もし公式にバグレポートを入力するのに手間がかかりすぎるなら、みんなバグデータベースを避けるようになる。

やさしいバグトラッキング

これだよ、これだよ。面倒だと、嫌になる。
面倒だと、みんなバグデータベースを避けるようになる。
当たり前だし、その通りだ。
でも諸般の事情により、「新しいフィールドのアイディア」がどうしても必要なることがある。それも大量に。


もちろん項目を最低限にできればいいのだが、なにかいい方法ないかな。
よくある原因については、ある程度まとめて1セットにして、ボタン1つで入力できるとか。
これならJavaScriptだけで出来そうだし。


いちばんよいバグトラッキングシステムは、みんなが楽に使ってくれるシステムだと思う。