この記事は、「架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late）」の記事の一部です。
テスト結果報告書の概要
テスト結果報告書は、その名の通り実施したテストの結果をまとめたものになります。
| 項目 | 内容 |
|---|---|
| 作成目的 | 各種テスト結果を報告する |
| 記述すべき内容 | 各テストの実施内容（サマリ）、実施エビデンス |
| 作成タイミング | テスト終了後（リリース判定前） |
| 対象者 | プロジェクトメンバー（非技術者、技術者） |
| ファイル形式 | パワーポイント、Excel、Word |
| 備考 | 判定基準と一緒にする場合もあるみたいです |
一般的にはどうなのか？が気になる人は後半にある「一般的には（参考）」に先に目を通してもらったほうがいいかもしれません。
サンプルダウンロード
サンプルのダウンロードはこちらから。
作成してみる
では、作成していきましょう。
作成方針・ポイント
内容としては、まずテストのサマリを報告し、必要に応じてそれぞれのテストの詳細やエビデンスを記載するのが一般的かなと思います。
構成（目次）を考える
今回は下記のような項目を記述してみました。
- テスト結果 全体サマリ
- 機能テスト：単体テスト結果サマリ
- 機能テスト：結合テスト結果サマリ
- 非機能テスト：全体サマリ
- エビデンス（各テスト）
記述例（サンプルから抜粋）
では、サンプルの主要なページについて少し解説したいと思います。
表紙
特に補足はありません。
目次
こんな感じ。
テスト結果 全体サマリ
まず、テスト計画で実施を定義したテスト全体の結果をサマリで記述しています。
あとは必要に応じて各テストについて個別に說明していくだけです。
機能テスト：単体テスト結果サマリ
単体テストのサマリ。通常は何百項目にも及ぶので単体テストのみでサマリを記述したりします。
機能テスト：結合テスト結果サマリ
結合テストのサマリ。単体テスト同様、通常は何百項目にも及ぶので結合テストのみでサマリを記述したりします。
非機能テスト：全体サマリ
非機能テストのサマリ。必要に応じて各テストの内容を說明しますが、サンプルでは割愛しています。
テスト結果 各種エビデンス
提出の有無に関係なく、エビデンスは取得しておいたほうが何かと無難です。
まあ、エビデンスと言っても実施時の結果画面キャプチャ（場合により動画）とかが中心です。
（機能テスト：単体テスト）
テストツールが吐くログをキャプチャ。
（機能テスト：結合テスト）
テストツールが吐くログをキャプチャ。
（非機能テスト：可用性テスト）
クラウドサービスの可用性のみ確認。
（非機能テスト：性能テスト）
独自開発ツールが吐くログをキャプチャ。
（非機能テスト：セキュリティーテスト）
テストツールが吐くログをキャプチャ。
（非機能テスト：留意事項１）
動作確認ログをキャプチャ。
（非機能テスト：留意事項２）
動作確認ログをキャプチャ。
一般的には（参考）
実践ガイドブックでは？
残念ながら実践ガイドブックにはテスト結果報告書のテンプレートはありません。
ただ、テストシナリオの各項目がどうだったかを○・✗で記述すればいいのでテストシナリオや計画書がきっちり書けていれば結果の準備はそんなに大変ではないのかなと（サマリ資料を作るくらい）。
その他：結果の評価
テンプレートではありませんが実践ガイドブックの本文の中にテスト結果の評価に関して有益な情報があったので紹介しておきます。現場でテストをし、結果を報告していると、
- 「これでテスト（品質）は大丈夫なのか？（ダメだったらお前が責任取れよ）」
と言われることがあります。テストの性質としてどこまで対応しても「絶対OK！」と言えないというのはテスト計画（たぶん）でも紹介しましたが、テストの結果を評価するいくつかの指標がありますので、知っておくといいでしょう。
信頼度成長曲線（第3編7章 設計・開発 P38）
テストが順調に実施され（青線）、それにともない累積のバグ数（オレンジ線）が増え、同時に解決数も増え（緑線）、そしてバグの累積数の伸び率が鈍化し、フラットになりつつある（バグは収束しつつある）というのが理想です。
実践ガイドブックには悪い例も乗っているので確認してください。
テストが消化されてない、バグが収束しない（フラットにならない）、解決が追いつかないなどあればダメな例です。
テスト密度/不良密度（第3編7章 設計・開発 P43）
バグ密度は、「バグは10個しかありませんでした！」と言われても、
- コード量が100行のソフトで10個と
- コード量が1万行のソフトの10個
では意味が違いますよね？
- 何行（何機能）のソフトに対して、何個テストをしたか？が、テスト密度。
- 何行（何機能）のソフトに対して、何個バグが出たか？が、不良（バグ）密度。
単純に言えばテスト密度が高く、バグ密度が低いのが理論的には良いということになるのですが
- 無駄にテストしすぎ（コストかけ過ぎ）
- うまくバグが検知されてないのでは？
とかの問題も０ではないので、１つの指標です。
あとは、フレームワークとか自動生成されたコードを含めてバグ密度を計測すると意図的に（バグ）密度を低くしたりもできるので、内容はちゃんとレビューする必要があります。
