テストにおけるバグレポートの書き方

あるプロジェクトで「テスト工程の管理全般」が大きなミッションとしてありました。

具体的には、テスターが起票したバグレポートを確認し、「する/しない」「するのであれば、いつまでにどのチームがやるか」などをスケジュールやリソースの状況を見て判断することです。

それらのバグレポートを管理するツールとしてRedmine(使い方はこちら)を使っていました。

そのバグレポートの書き方、テスターとしてのTipsのようなものを少し書いてみます。
＃再現手順、発生したソースのリビジョン、可能であればエラーログやスタックトレースを書くなどは当たり前の前提です。

1：実装者の感情面を理解して書く

その機能のプログラマとテスターが異なる場合、何度か同じようなバグに遭遇しているとレポートには「同様の機能でも同じバグが出ていました。きちんと内容の再チェックをお願いします。」などと書きたくなったりします。

実際には正しい行為なのかもしれませんが、重箱の隅をつつくようなバグを見つけ、バグレポートを無慈悲に起票するテスターの存在はプログラマーにとって気持ちの良い存在で無いと感じる人も多いようです。
正確な比喩ではありませんが、(例えそれが正当な内容であっても)自分の作品に「ケチ」をつけられるわけですから。

忙しかったりするとついテスターに向かって「テストのやり方が間違っているんじゃないの？もう一度確認してみてよ！」と感情的に答えたりして、テスターも「(品質の)いい加減なプログラムだからバグになるんでしょ」と応酬が始まってしまいます。こうなると品質の維持、担保などできません。

なので以下を参考にしたりして配慮した書き方をしてみませんか？という提案です。

2：技術面では客観性と主観を混ぜずに書く

1や3に通じるのですが、テストをしていると「あれ？自分の理解ではAと思うが、Bになるな」ということがあります。
そのような場合、バグレポートに客観的に書く部分と主観の部分が混じってしまうことがあります。

管理者としては、客観的な事実(テスト結果)を過不足なく知りたいわけです。
それを読み取れにくくなる主観と客観が入り混じったバグレポートは「テスターへの確認」という余計な時間が取られる存在になります。

もちろん「こう思う」とか「これでテストケースが失敗しているのだから、類似の機能も見た方が良いと思う」という主観を気づきとして書くのは非常に良いことで、問題なのはその書き方です。

3：本来どうあるべきかも書く

テストケースには「～となること」と合格条件が記述しており、「本来どうあるべきか」が明確になっています。

テストフェーズ中では(偶然にせよ)テストケースにない操作の結果、明らかにおかしかったり、「これは仕様と違うのでは？」という動きを見つけることもあります。
その時のバグレポートに「これこれが発生」という事象だけではなく、「本来は～であるべき」とあるのが良い書き方だと考えています。
その根拠となる設計書などドキュメントへのポインタがあればより良いです。