PR

プログラマとテストエンジニアにバトル勃発!正しいバグ票の書き方とは?

2012年7月11日(水)
森崎 修司

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

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

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

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

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

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

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

図3:Bさんの作成したバグレポートの問題点(クリックで拡大)

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

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

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

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

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

静岡大学

2001年、奈良先端科学技術大学院大学 情報科学研究科 博士後期課程修了。情報通信企業において、サービス開発やシステムインテグレーションに従事し、企画、設計、実装、開発管理、品質向上を実践する。奈良先端科学技術大学院大学 情報科学研究科 助教などを経て、2011年4月より現職。不具合情報の分析、ソフトウエアレビュー、ソフトウェア計測、実証的ソフトウエア工学を研究の柱としている。
研究グループのWeb:http://ese.inf.shizuoka.ac.jp

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています