Joel on softwareより、バグレポートにもよい物と悪い物があるというお話。
私の場合、お仕事では平均すると一日あたり一件以上バグレポートをいただいています。過去に何度か書いたことがあるけれど、送ってくる内容も様々だけれど、ほとんどのバグレポートは。
- 具体性に欠ける(おちたとか、そういう一言)
- 再現手順がない
- 何を期待しているのかわからない
よいレポートとは上記の要素がないものです。
- 現象の説明と背景が明確
- 再現手順
- 期待している動作
もちろん、エンドユーザに上記の三点を要求するのはお門違いで、それはお客様と直接対峙している現地のエンジニアのお仕事。根気よく、確認したものをレポートに書いてもらえるととても助かります。
もちろんお仕事なので対応はするのですが、ログや手順がないものであれば必然的に優先度は下がります(システム停止に陥るような特急物件は別ですが)。こちらも人間ですしね、やる気を起こさせてくれるようなレポートをいただければ必然的に対応も丁寧になって、いいアドバイスもできようという物です。
都合でソースを開示している人たちの場合は、ソースのパッチも送ってもらえるとなおうれしい(^^;。
それにしても、バグト
ラッキングもほんとうにいろいろありますね。「これができなきゃだめだ」とかみんないろいろ要件があると思います。私も理想のバグト
ラッキングシステムが欲しいのですが...そもそも
Windowsで動くと言うところでまずは大きな隔たりがあります(主に
unix系が多いので)。
