
419
重複したバグレポートの価値
者がバグレポートの不完全な情報のために苦しめられたとコメントしました。ある開発者のコメントで
す。
「遅れの最大の原因は情報が間違っていることではなくて、情報が全くないことだ。」
スパムがあまり無いのは、
Bugzilla
と
Jira
では報告者はバグ報告を提出する前に登録を行わなくて
はならず、その登録がうまくスパムを防いでいるので、意外ではありません。最後に、スタックトレー
スの間違いはそう頻繁には起きないでしょう。バグレポートにコピーペーストするだけだからというの
が理由ですが、もしこの間違いが本当に起きたときには、手痛い問題になり得ます。
他の大きな問題点は、テストケースと観察された振舞いの間違いです。非常に興味深い観察は、少し
前の研究では開発者たちがバグの重複で苦しむことが問題としていたのに[
Anvik et al. 2005
]、今回
はそれほど問題でないという結果だったこと
です。おそらく開発者たちには容易に重複だと分かり、場
合によってはバグについての複数の記述があることが助けにさえなっているのかもしれません。次節で
は、重複するバグ報告について集中的に考察を行います。
重複したバグレポートの価値
重複したバグレポートを良くないものとする通常の議論は、それがバグ追跡システムを溢れさせて、
図
24-4
「開発者にとって最も役立ったもの」対「報告者が最も頻繁に提供したもの」
再現手順(83%)
スタックトレ ース(57%)
テストケース(51%)
観察された振舞い(33%)