「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の１９日目です。
[blogcard url=”http://qiita.com/advent-calendar/2015/mmtest”]
今回の記事は，第II部最後となるChapter９「テスト報告 ～報告書を作成しよう～」を取り上げます。いつものように読む上で注目して欲しいポイントと補足をします。
※ご注意：本Advent Calendar はあくまで池田の個人企画です。
■テスト実施結果リストはテスト報告書ではない
このChapter9で伝えたいことは、テスト実施結果リストはテスト報告書ではないということです。よく見かける例として「テストケースリスト（表）に実施日と担当者，合否結果を記入したものの表紙をテスト報告書とする」があります。テストケースリスト（表）に実施日と担当者，合否結果を記入したものは単なる劣化テストログであって，決してレポートではありません。なぜならば，報告の要素が一つも入っていないからです。
■テストにおける報告はそれほど普及していない
おそらくですが，国内においてテスト報告はあまりきちんと実施されていないのではないかと思います。テストケースをすべて実行したら終了といったようなルールがあるくらいで，スケジュール優先のテスト計画がないプロジェクトだとその傾向は顕著に思えます。
また，これまでテスト分析設計とならんでテスト報告についても言葉としてあまり一般化はしていませんでした。ですので，テスト計画にはそれなりに取り組んでいるもののテスト報告は不十分だったり，作業やドキュメントがきちんと整理されていなかったというところもあるでしょう。
■テスト報告書はテスト計画書の内容に対応する
テスト報告書のテンプレートがないことを前提にして，どのようなテスト計画書の項目が必要であるかについては，IEEE829を参考にした例を本文に示しました。ここで注意してほしいのですが，暗黙的に書かなかったことですが，テスト報告書はテスト計画書に対応するものであるということです。ですから，もしテスト計画書の項目をIEEE829を参考にしなかった場合は，当然ながら報告書もIEEE829を参考にするのは妥当ではありません。
テスト報告書はテスト計画書に対応した内容であり，それをプロジェクトマネージャやテストマネージャ，お客様などのステークホルダが「判断」するために作成されなければなりません。ですから，それはテスト実行の結果を分析し，テスト計画等に定めた様々なことと照らしてどうであるかを見極め，ステークホルダーが必要な情報を付加したうえで，理解しやすいような形にまとめ上げます。テスト報告書もまたその中身は設計が必要であるし，表紙を挿げ替えただけで成立するほど簡単ものではないということをきちんと理解するべきなのです。
■テスト報告書を設計するタイミング
テスト報告書を設計するタイミングについては脚注として示しています。
「報告書のテンプレートは通常，テスト計画を検討する工程で作成します。」「テスト報告」の章で説明していますので，テスト実行が終わってから取り組むものと勘違いをされるかもしれませんが，注意してください。」
（引用：マインドマップから始めるソフトウェアテスト p.175）
■おわりに
今回はテスト報告について取り上げました。テスト報告の内容検討については本文では触れていませんが，様々な分析技法やメトリクスといった技術が利用可能です。興味がある方はそれらについても勉強するとよいでしょう。
