プログラマとテストエンジニアにバトル勃発！正しいバグ票の書き方とは？［2ページ目］

具体的に前のページのバグレポートの内容を見ていきましょう。

1点目の問題は表題です。「ユーザに不親切」というのはバグレポートのタイトルとしては不適切です。タイトルでだいたいの症状と場所が推測できるようにします。「ユーザに不親切」というだけでは、症状や場所を推測することができません。また、バグですので、基本的には「迷惑」や「不親切」な内容になります。それらの言葉は個々のバグを説明する上ではあまり意味を持ちません。

2点目の問題は、「あるべき姿」欄に「わざわざ」、「一切」といった表現が出てくる点です。これらは、本当に必要でしょうか。

「なぜ半角とわかっているものをわざわざユーザに入力し直させようとするのか一切理解できない」

「なぜ半角とわかっているものをユーザに入力し直させようとするのか理解できない」

この2つでは、バグ修正に必要な情報は増えていません。「プログラマにはこれくらいわかっておいてほしい」という気持ちはわかりますが、「一切」「わざわざ」と文章に含めることで本当にバグ修正がスムーズに進むかどうかを判断した上で、これらの単語を使わなければなりません。

3点目の問題は、「原因」欄にある「そのくらい知っておいてもらいたいです」です。まず「XXフレームワークのデフォルトの動作です」までは「原因」といえますが、それ以降は「原因」ではありませんので、不適切です。プログラマ、テストエンジニアの双方にとって知っておいてほしい知識や持っておいてほしいスキルは、もちろんあるとは思いますが、バグレポート以外の場所で伝えるほうが効果的に伝わるでしょう。

プラットフォーム、ミドルウェア、ライブラリ、フレームワークによる制約があることはそれほど珍しいことではありません。特に顧客指定のものであったり、歴史的経緯で最初から決まっていたりする事情があれば、仕方なく従っていることも少なくないでしょう。

4点目は、「対処方法」欄の「バグのつもりで、バグレポートで指摘しているようですが」という部分です。この部分も2点目と同様に、なかったとしてもバグ修正の作業を進めていくことはできます。この部分はプログラマの推測であり、本当にテストエンジニアにそのつもりがあるかどうかは調べてみないとわかりません。

5点目は「直す気はありません」という部分です。プロジェクトの体制にもよりますが、プログラマ自身の方針や考えなのか、全体方針や顧客の方針として決まっているのかでは、今後取れる対策が異なります。まだ変更の余地があるのか、それとももう変更の余地はないのかをテストエンジニアに知らせておきます。もし変更の余地があり、時間やコスト等の条件が揃えば、修正できる可能性もあります。

少し意地悪なバグレポートを例に挙げましたが、程度の差こそあれ、このようなバグレポートを目にする機会はあるのではないでしょうか。また、上で挙げた5点以外にも問題点はあると思います。

では、どのようなことに気を付ければ、このようなバグレポートを作成することを防げるのでしょうか？次のページで紹介したいと思います。