究極のバグレポート第1回

バグレポートを書くことはバグ修正の会話をスタートすること

バグレポートを書く際に忘れがちなのが、バグレポートを書くことはテストエンジニアがプログラマに対して会話をはじめることを意味するということです。

報告書の形になっているので、同じテストエンジニア側のリーダや管理者のことを意識して自身の知識や経験をアピールする場に捉えてしまうことがありますが、最終的にバグレポートを受け取り、バグを修正するのはプログラマです。スムーズな会話の開始はそれ以降のやりとりもスムーズにします。

そして、プログラマが修正したものを確認するのは、テストエンジニアです。その間に、上司、管理職、発注者がいることもあります。これらの人が重要であることは確かなのですが、バグ修正という目的において最も大事なことはバグを検出するテストエンジニアとプログラマの双方がバグ修正に取り組むという姿勢です。そして、開発関係者全員がバグ修正に取り組むという姿勢を持つことが大切です。

詳細は連載第2回で紹介することとして、今回は、最も大事なポイントを2つ紹介します。

1.「バグ対我々」という構図をイメージする

ここでバグ修正時の問題を表す図を紹介します。

図4：間違った対決の構図（上図）と正しい対決の構図（下図）

前のページで示したような問題のあるバグレポートが作成されてしまう理由は、図の上半分のような誤った状態に陥っているからです。プログラマとテストエンジニアがバグ修正という本来の目的を意識しながら、連携しつつバグ修正を進めていくことが必要なのです。ユーザにとって不利益になるバグをテストエンジニアとプログラマが手を組んで検出して修正しようとしているはずなのに、両者でいさかいが起きてしまうことはよくあります。その原因はバグレポートの書き方によるものであることが多いのです。

バグ修正をスムーズに進めるためには、バグレポートを書く時点で「バグ対我々」という構図を意識できているかどうかという点が最も重要です。意識するだけで文面が変わってきます。もちろん、バグレポートを読んで対応するプログラマにも同じ意識が必要です。返答においても「バグ対我々」という構図がなければ、すぐに問題のあるバグレポートに変わってしまいます。

2. 口頭で言いづらいことは文章にしない

電子メールにも同じことが言えますが、口頭では躊躇してしまうような厳しい内容を文章にして伝えるというのは、得策ではありません。バグレポートも同様です。特にバグレポートは書く人（起票する人）にとっては、電子メールよりも報告の意味が強い文書なので、口頭で指摘するよりも厳しい口調になってしまう場合が多い傾向にあります。

しかし、バグ修正を対応する人にとっては、単なる報告と解釈できにくい文書です。自分や自分のチームが作成したプログラムの問題を指摘されるのですから、そもそもあまりいい気分ではありません。プログラムに露骨にけちを付ければ、バグレポートの文言にけちを付け返されてしまい、本来の目的であるバグ修正を妨げてしまいます。

文書は口頭での話と異なり、何度も読み返すことができます。読み返す回数は書き手の意志では決められず、読み手の意志で決まります。軽い気持ちで書いた文章が何度も読み直され、意図せず怒りを大きくすることもあります。