オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 >

計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

実際にあった怖いバグ票(バグレポート)

»

困ったバグレポートを収集し、アンチパターンとして名前をつけておけば、典型的な問題を解消できるのではないかという推測のもと、バグ票ワーストプラクティス収集プロジェクトというプロジェクトのメンバをやっています。プロジェクトのサイトはこちら

ThinkITの記事として、これまで集めた困ったバグレポートのうち、典型的なパターンを4つ紹介しています。もう少しだけありますが、レポートの内容としてはこの4つのパターンに収斂されました。引き続き困ったバグレポートの事例は収集していきますので、これら以外のパターンも出てくると思います。

  1. バグレポートによってプログラマの反省を促そうとする。
  2. バグの説明が不十分である。
  3. プログラマのモチベーションを下げる。
  4. 必要のない情報が多い。

1は、バグ報告にかこつけて、いろいろと難癖をつけるものです。2は再現方法の記述が不十分であったり、肝心な前提が抜けていたりします。3は立場の差等を利用して、やる気をそぐような表現や少し意地悪な表現を含むバグ報告です。4は、バグ修正や再現に関係のない情報が多く含まれているものです。

2と4が組合わさっているものはテストに携わると一度は目にしたことがあるのではないでしょうか。

記事はこちら。怖い、困ったバグレポートを知っているという方は、こちらから事例収集にぜひご協力ください。

Comment(0)