「困った」バグレポートの数々から得た「正しい」レポートのための教訓とは

今回は、バグレポートの典型的な問題パターンを紹介します。ここで紹介するパターンは、バグ票ワーストプラクティス検討プロジェクトが収集中の「困った」バグレポートとして挙げられたものを参考にしています。プロジェクトは継続して困ったバグレポートを収集していますので、こちらのアンケートフォームから情報をお寄せください。

それでは、具体例を交えて問題のあるパターンの典型例を見てみましょう。

このバグレポートはいったい何を言いたいのか

システムテストの開始直後

テストエンジニアA：
このシステムでは、連携システムXからの日時のデータのタイムゾーンが他のサブシステムのタイムゾーンと違っていて、ここにバグがよく起こるんだよな・・。今回もそうかもしれないから、まずは、ここをテストしてみよう。

連携システムXを含めたテストの実施中

テストエンジニアA：
ほら、やっぱり。連携システムXからの送信データが過去日付だってエラーが出る。実際にはほぼ同じ時刻なのに・・。今回もこの考慮を忘れてるじゃないか。こういうのを何回もやらされるこっちの身にもなれよ。レポート書くか・・。

テストエンジニアA：
これくらい書いとけば少しは反省するだろう。タイムゾーンが統一されていないなんて、恥ずかしいことに気づいてくれればいいんだけど。

一方、バグレポートを見たプログラマBは・・

プログラマB：
なんだこのバグレポートは・・。結局、どの部分を修正したらこのバグレポートを「対応完了」としたらいいんだろう。いろいろ書いてあるけど、最初の連携システムXのところかな？？

問題の起こりやすいパターンを意識しよう

困ったバグレポートを大別すると、以下のような4つのパターンに分類できました。

• バグレポートによってプログラマの反省を促そうとする（冒頭のバグレポートの例）
• 説明が不十分
• モチベーションを下げる
• 必要のない情報が多い

これらのパターンに気をつけるだけで、不適切なバグレポートを書いていないかを簡単にチェックできます。

個別の紹介に入る前に、全体として重要な考え方を示しておきたいと思います。

バグを発見することと報告することは別の作業であり、両方が必要

最初に意識すべきことは、バグを発見することと報告することは別の作業であり、どちらかのスキルがあるからといってもう片方も同じように上手になるわけではありません。発見しにくい致命的なバグを発見できるスキルや経験が身についたからといって、うまく伝えられるようになるかといえば、必ずしもそうではないでしょう。

同様に、うまく伝えられるようになったからといって、バグをやすやすと見つけられるようになるかというと必ずしもそうではありません。バグを報告するにもスキルが必要であり、学ぶことによって改善していくことがあるという意識を持つことが大切です。

では、続いて「説明が不十分」のパターンから具体例を交えて順番に見ていきましょう。