QAの成果物の一つに、不具合報告書があります。

QAのスタッフの多くは、不具合報告書を渡すことはあっても、受け取ったことは無いと思います。受け取り手(つまりプログラマやプランナー)の目線に立ってみて、改めて不具合報告書を見つめ直してみようじゃありませんか！

なお、下記内容は個人の意見です。
「ソフトウェアテストの常識」というわけではないので、そこのところを踏まえてお読みいただけると幸いです。

報告書は何のために書くのか？

ところで、不具合報告書に限らず、報告書って何のために書くのでしょうか。
「報告するために決っとるやろ！」と思ったそこのあなた！
そんなあなたに質問しますが、例えば、天気予報は何のためにあるのでしょうか。
天気を予報するためですか？
ちがいますね、未来の天気を知ることで、その後の行動の参考にするためです(傘を持ってくとか、ピクニックに出かけるとか)

報告書も同じです。読んだ人が次の行動の参考にできるのが、良い報告書なのです。

例をあげましょう。
私は子どもを保育園に預けているのですが、保育士と保護者の間で、毎日、子供の様子をドキュメントでやり取りをします。ここでは、良いドキュメントと悪いドキュメントを紹介します。まず悪い例から。

今日、息子は体温がいつもよりも高いです。

はい。状況を報告しただけですね。これを読んだ保育士は、何をすればよいかわかりません(親が何を期待しているかわからない)。おそらく、現場の保育士さん達は混乱するでしょう。続いて良い例。

良い例：
今日、息子は体温がいつもよりも高いですが、
季節の変わり目にはよくあることなので、登園させました。
ただ、大事をとって、水遊びは控えていただけますでしょうか。
それ以外はいつも通りで大丈夫です。
もし、体温が37.5度を超えるようでしたら、両親までご連絡ください。

どうでしょうか。
これを読んだ保育士は、迷わずに行動に移せますね。これが良い報告書です。

さて、話を不具合報告書に戻しましょう。不具合報告書はなんのために書くのでしょうか。
「不具合を報告するために決っとるやろ！」と言う人はもういませんね？
そう、不具合報告書は、「開発者にバグを直してもらうため」に存在するのです。
では、どうすれば直してもらえるでしょうか。

開発者の手元で現象を再現させ、そしてその現象がバグだと認識してもらえば、直してもらえる気がしますね。したがって、大事なポイントは以下のふたつです。
・再現させる
・バグと認識させる

再現手順

不具合報告書には様々な情報がありますね。ざっと上げると
要約、詳細、再現手順、期待値、環境、再現率、といったところでしょうか
これらの情報で大事なものはなんでしょうか。
私の中での優先度は以下の通りです。

再現手順 > 期待値 > 環境 > それ以外

テスターなら、誰もが一度は開発者から「私の手元では発生しませんね。もう一回確認お願いできますか？」という返事をもらったことがあるでしょう。
では、なぜこの返事が帰ってきてしまうのでしょうか。理由は主に3つです。
手順が伝わってない、期待値がズレている、環境依存

バグ報告書を受け取った開発者は何をするでしょうか。
おそらく、自分自身が所持している端末で再現を試みることでしょう。
したがって、まずは、誰が読んでも同じ手順を踏むような再現手順を書くことが大切です。
エンジニアのAさん、プランナーのBさん、QAのCさん、CSのDさん、パン屋のEさん、全員が同じ手順になるような再現手順を書きましょう。

抽象的な表現は極力避け、なるべく具体的に詳細に書くことをオススメします。
再現してもらえなければ、その時点で、「私の手元では発生しない」のコメントとともに、バグ報告書はテスターに帰ってきてしまいます。
何はなくとも、エンジニアにバグを再現してもらうことを、最優先にしましょう！

期待値を示す

「再現手順」で現象を再現してもらうことはできました。
次は、その現象が不具合であるということを認識してもらう必要があります。

クラッシュバグのような分かりやすい不具合なら、再現手順だけでも十分ですが、仕様書との相違のような、一見、不具合かどうか判断しずらい症状のときは、期待値をしっかりと書くようにしましょう。
期待値欄に仕様書のURLだけをペタっと貼るケースが散見されますが、あまりオススメしません。
それは期待値ではなく、期待値が書いてある場所、でしかないです。

サボらずに「Aという仕様書のBの項目にCという期待値が書いてあるが、再現手順を踏むとDという挙動をしている」くらい、詳細に書くことをオススメします。

##環境
スマホアプリやWebページの実行環境は、無限のパターンが存在するので、環境の明記は重要です。
たとえば、下記３つのパターンだと、エンジニアが取る行動は、それぞれ異なるでしょう。

1.iOSとAndroid両方で発生する。
2.iOSとAndroid両方で検証した結果、iOSのみで発生する。
3.iOSではバグを確認したけどAndroidは未検証。

1の場合、ロジックの不具合だと予想できるので、コードを見直すはずです。
2の場合、iOSの環境依存だとあたりをつけてデバッグを行なうでしょう。
3の場合、ロジックのバグなのか環境依存なのかを切り分けたいので、テスターに「Androidだとどうなるか確認してほしい」というリクエストが来るでしょう。
環境の情報のひとつとっても、次の行動にこれだけ差が生まれます。

おわりに

誰かが言ってましたが、良い不具合報告書とはブーメランのようなものです。
手を離れると(バグチケットを担当者にアサインすると)、獲物を仕留めて(不具合を修正してもらって)、手元に帰ってきます(報告者にアサインが帰ってくる)。
これが、テスターと開発者で何度もやり取りが発生するようだと(延々とコメントでやり取りが行われるようだと)、良い不具合報告書とは言えません。
バグ報告書は現状を伝えるだけではなく、問題を解決する道具であるべきです。その意識の差があるだけで、ドキュメントの質は変わってくるでしょう。
それでは！