ここまでの状況

テスト実行も終わり、最後の仕事としてテスト報告を求められた中山君。二時間ほどで報告書を仕上げて大塚先輩のところに持っていくと、あえなく却下されてしまいました。大塚先輩が言うにはこれはテスト報告書ではないとのこと。また、本来この報告書を書く前にやるべき作業を行っていないと指摘されました。

中山君は席に戻り一生懸命考えてみましたが、何が悪いのかさっぱりわかりません。

小一時間悩んでいると、その様子が気になった小川君が席にやってきました。

テスト報告書は誰のために作るのか

小川君：

中山さん、どうしたんですか？　なんだか悩んでるみたいですが。

中山君：

あぁ、小川君か…。
実はね、大塚先輩のところにテスト報告書を持って行ったんだけど却下されちゃって…。

小川君：

なるほど、ちょっと見せてもらってもいいですか？

小川君は中山君からテスト報告書を受け取るとパラパラとめくってみました。

小川君：

なるほど、確かにこれをテスト報告書というところもありますね。

中山君：

うん、大塚先輩は何でこれを駄目だっていうんだろう。

小川君：

でも、普通はテスト報告書とは言いませんね。

中山君：

えっ、どういうこと？

小川君：

これはテスト実行結果ログの表紙を変えただけですよね。テスト実行結果ログそのもで、報告内容がありません。

テスト実行結果は報告書ではない。

テスト実行結果に「テスト報告書」という表紙を付けて終わりにするところもあります。しかし、報告はさまざまな情報を収集し、整理し、分析して、客観的事実を提示しつつ、場合によって見解を述べるものです。

ですから、分析も何もせずに実行結果を報告だというのはあまりに乱暴ですし不適切です。もし、このようなスタイルがまかり通っている場合、ひょっとするとテスト活動を評価するという文化がない可能性があり、それはテストの継続的な向上に大きく支障をきたします。

テスト実行結果ログだけで報告を考えない

テスト実行だけがテスト活動のすべてではありません。テスト計画で作成したテスト計画書に基づいてプロジェクトがすすめられたわけですから、その計画に対して実績がどうであるかを比較する必要があります。また、各工程での問題点などもあるでしょうし、それこそバグの分析結果であるとか、リソースの消費状況なども報告内容になるかもしれません。さまざまな情報を今一度再整理して評価する必要があるのです。報告するのはテストケース消化状況のみではありません。

誰に報告するのか

テスト計画の回でも触れましたが、報告書を作る際には「誰に報告するのか」を明確に意識しなければなりません。今回の場合、大塚先輩は「柏田マネージャに」と言っています。ですから、柏田マネージャが読むことを意識して、内容を吟味する必要があります。

さらに、最終的にはお客様に対して説明しますので、納品物としての品質が保つように意識しなければなりません。

報告内容を吟味しよう

「誰に」が決まったところで、次は「何を」です。報告先によって報告してもらいたい情報は異なるはずです。報告書を作るに当たっては報告内容を報告先にヒアリングするなどして定義する必要があります。報告相手が望んでいない内容は報告でないことを理解してください。

開発プロセスや標準が定義されている場合、たいていの場合テスト報告書のフォーマットは決まっているはずです。まずはそれを探しましょう。ただ、その場合でも、そのフォーマットを使った報告で問題ないかは報告先に確認を取りましょう。

もし社内標準がなく、一から作らなければならない場合は、「⁠IEEE std. 829-1998」を利用するという手があります。IEEE std. 829-1998を参考にカスタマイズした目次例を以下に示します（※⁠）⁠。

この目次を元にさらに個別の記述内容を決めていきますが、それは本稿の範囲を超えますので、『⁠マインドマップから始めるソフトウェアテスト』のChapter 9などを参考にしてください。

※）

現在IEEE std. 829 は2008年版となるIEEE std. 829-2008が出ていますが、本稿では日本語での情報が多い1998年版のIEEE std. 829-1998で解説しています。

次回のテスト実行に対する教訓をまとめよう

今回のテスト実行では、小さいながらもさまざまなトラブルが発生しました。その時々で適切な対応が取られたために、大きな問題になることもありませんでした。しかし、このままで終わりにしてしまいますと、毎回同じようなトラブルを起こしてしまう可能性があります。

リーダとして、どんなトラブルがあり、どんな対処を行ったのか、次回のテスト実行にはどんな対策が必要なのかをまとめておく必要があります。

報告する前にレビューしよう

テスト報告書が出来上がったとしてもそれは作成者の独断が入っているかもしれません。テスト報告書だけの話ではありませんが、文書ができあがった場合は関係者を集めてレビューを行ってください。

今回の場合だと、大塚先輩や小川君、千秋ちゃんなどテストプロジェクトのメンバのほか、設計部門の設計担当者などです。テスト報告書を作成する場合に設計担当者の目を入れるというのは、案外忘れがちなので気を付けてください。なお、もちろんのことプロジェクトの作り方によってはマネージャや営業担当など、さらに多くのメンバを加えます。

テスト活動を評価の整理と評価を行う

中山君と小川君が議論をしているところに、千秋ちゃんがやってきました。

千秋：

テスト終わったのに、なにそんな難しい顔してるのよ。

小川君：

いや、かくかくしかじかで…

千秋：

中山クンまた怒られたんだ。相変わらずね。

中山君：

うぅ、面目ない

千秋：

で、本来行うべき作業が何って話ね？

小川君：

そうなんだ、報告書が良くないということは想像がつくんだけど、それ以外に何かあるかなぁ

千秋：

そんなの決まってるじゃない。打ち上げよ。テストが終わったのに、打ち上げの日程も決まってないのはおかしいじゃない。

小川君：

そんなふざけてないで……。いや、ちょっとまてよ。そうか、そういうことか。

中山君：

何？　何か思いついたの？

小川君：

はい。きっと大塚先輩が言っているのは「振り返り」のことだと思います。

振り返りミーティングを実施する

ここでは「振り返り」と言っていますが、テストウェアの整理や各種書類の取りまとめだけではなく、それらを関係者で評価する場が必要となります。

振り返りはプロジェクトの終了時に行うものとされていますが、マイルストーンごとに振り返りを行っても問題ありませんし、むしろ行うべきです。とくにテスト実装、テスト実行は作業量やかかわる人数も多く、それだけに流れる情報量も当然多くなります。さらに問題点や改善点の情報も多いはずです。

ですから、今回のテスト実行に関する情報を共有し、それらがはたしてどうであったかをディスカッションする場を設ける必要があります。

振り返りミーティングの技法としては「ポストモーテム」や「落ち穂拾い」等があります。これらの技法を活用するとよいでしょう。

テストウェアの整理とパッケージ化（凍結）

振り返りによって、情報や活動の整理と評価が行われます。その振り返りでの材料に利用するため、また振り返りの生活物として、これまでに作成したテスト関連のドキュメントを整理し、パッケージ化（凍結）する必要があります。また、ドキュメントだけではなくテストツールなどについても整理を行います。それに加えて、文書化されていない各メンバの感想や見解、意見といったものも整理する必要があります。いわゆるテストウェアと呼ばれるものを整理する必要があります。

結末は…

中山君は小川君と千秋ちゃんの指摘から、テスト報告書を作成するための何をすべきかの見当をつけることができました。早速二人に協力してもらい、テストウェアの整理や振り返りミーティングを行い、社内標準にあるテスト報告フォーマットを利用してテスト報告書を作成しなおしました。確信はありませんでしたが、ひとまずできあがったものを大塚先輩のところに持って行きました。

心配そうな顔をしている中山君の前で、大塚先輩は今度は最後まで目を通してくれました。

大塚先輩：

よし、やるべきことはわかったようだね。でも内容はまだまだだ。とても柏田さんのところには持っていけない。俺も付き合うから頑張って仕上げよう

中山君：

はい！ありがとうございます！！！

それから中山君は大塚先輩の力も借り、レビューを重ねながらテスト報告書を完成させることができました。実に1週間がかりの作業となりました。

テスト報告書を作るということは簡単なことではないのです。でも、それだけに達成感もひとしおです。もちろん、メンバもそれは同じで、その日は千秋ちゃんが行きたがっていた打ち上げを中打ち上げとして出かけることになりました。全員が協力して何かを達成したときその打ち上げで笑顔が見られるのはコミュニケーションの醸成ができているということです。中山君はそれには気が付いていませんが、プロジェクトやチームを運営するに当たってもっとも大切な事柄のひとつです。大塚先輩はメンバが盛り上がる様子を眺めながら安心した表情で酒をすすめたのでした。

次回は、いよいよ最終回。次回の公開までに、今一度第1話から読み直していただければと思います。