1．概要
IEEE829から学ぶテストドキュメントの最終第8回目として、テストサマリーレポートについて記載いたします。テストサマリーレポートを作成する目的は、
①テストが終了しても問題ないことを関係者に伝える
②次の案件をよりよくするための教訓にする
となります。
テスト完了後の終了結果をすべてまとめると膨大な量となることが多いので、テストサマリーレポートでは重要な部分を要約して記載します。また、テストが完了すると別のプロジェクトに移動する人が多いので、できる限りプロジェクトの期間中に作成することが求められます。（テストが完了してから作成していては遅い！）
2．IEEE829のテストサマリーレポートについて
- テストサマリーレポート識別番号
- テストの要約 ⇒②
- 計画との差異 ⇒②
- 総合評価 ⇒①
- 結果の要約 ⇒①
- 個別評価 ⇒①
- 活動の要約 ⇒②
- 承認
上記がIEEE829のテストサマリーレポートに記載する項目になります。また、テストサマリーレポートは「①テストが終了しても問題ないことを関係者に伝える」ために、以下の項目を記載します。
現状のテストの品質状況
- リリースしても問題ないか？（終了基準を満たしているか）
- 不具合は残っていないか？また、対応策はあるか？
報告資料としての項目
- テストの評価が数値で記載されているか？
- テストの結果が要約されているか？
- テストの分析結果（不具合分析など）が記載されているか？
「②次の案件をよりよくするための教訓にする」のために記載する項目は以下となります。（振り返るために、「何を行ったか」を明確にする）
対象システムの情報
- ソフトウェア名
- バージョン名
- 動作環境…など
テストの活動
- 行ったタスク（テスト計画、テスト設計、テスト実施など）
- テストタイプ（機能テスト、ユーザビリティテストまど）
- テストレベル（単体テスト、結合テスト、システムテスト）
- 使用したテストの技法
学んだ教訓
- ベストプラクティス
- 計画との差異（初期の考えとどこがずれたのか）
3．サマリーレポートの項目の詳細
- テストの要約
②に該当。どんなソフトウェアをどんな環境でテストしたのか、を記載する。
- 計画との差異
②に該当。問題が起きた点はどこか、計画とのずれはどうして起きたのか（テストの終了基準と比較する）、などを記載する。
- 総合評価
①に該当。テスト中に収集したメトリクス等も記載する。リリースしても問題ないか一言で記載（不具合が残っているのか、直っているのか記載する）。
- 結果の要約
①に該当。テストの消化数や不具合の発見数などを時系列で記載する。未解決な不具合もすべて列挙し、その対応方法を記載。また、不具合全体の分析結果があれば記載する。（できれば図にするとわかりやすい）
- 個別評価
①に該当。各テストタイプやテストレベルごとの評価を記載する。（ここにベストプラクティスや教訓があってもいい）
- 活動の要約
②に該当。どんなテスト活動（テスト計画、テスト設計、テスト実施、テスト管理…など）を行ったのか記載する。また、テスト活動中に作成した成果物も記載する。
4．サマリーレポート作成前に実施すること
サマリーレポートを作成する前に案件中に起きた出来事をまとめるため、振り返りを実施しておいた方がいいと言えます。KPIやYWTなどの手法を用いて実施することで、レポートに記載すべきベストプラクティスや教訓などを集めます。
レポートの記載内容を充実させるために、外部の専門家を招くのも1つの方法です。その時、TPI等の改善技法でプロセス診断を実施するのもいいと思います。
また、案件終了前に収集すべきメトリクスを集めて、最終的な結果を算出します。（収集するメトリクスは、テスト計画書作成時にまとめるべきです。）
この際に行ってはいけないことは、サマリーレポートを充実させるためにこの時点でメトリクスを決めることです。メトリクスを後出しで決めてしまった場合、個人個人の過去の記憶から数値を算出しなければならないため、数値の精度が非常に下がります。
また、算出した値が悪いためテストのやり直しをすることもあるので、メトリクスを収集する目的を早くから決めて実施すべきと思います。
5．まとめ
テストサマリーレポートは、①テストが終了しても問題ないことを関係者に伝える、②次の案件をよりよくするための教訓にするためのドキュメントです。そのため、関係者にわかりやすく伝えることを心がけ、次に活かせる教訓があれば問題ありません。
ただ、サマリーレポートを充実させるために、テスト完了間際にあれこれメトリクス等を追加すると、収集するのに時間がかかり、結果としてまとめることができなくなるので注意が必要です。