テスト完了報告書の書き方｜テンプレートと品質の評価の書き方

テスト完了報告書は、テストの結果を数字で示し、「終了基準を満たしたか」「残ったリスクは何か」「リリースしてよいか」を判断する人に渡す文書です。 結果を並べるだけでなく、数字から品質をどう評価したかと、判断に要る残課題を書くのが中心です。

確認環境：数値の計算は Python 3.11・NumPy 2.4.6・SciPy 1.17.1 で実際に行いました。項目は、IEEE 829 のテストサマリー報告書の構成、公開されている ISO/IEC/IEEE 29119-3 の概要資料のテスト完了報告書の見出し、JSTQB（ISTQB）のシラバスの用語をもとに整理しています。図は mermaid-cli 11.14.0 で描画できることを確かめました（確認日 2026年10月13日）。

規格の項目との対応

テスト完了報告書の項目は、国際規格の構成をもとにすると、抜けが減ります。 IEEE 829（1998年版）の「テストサマリー報告書」と、それを置き換えた ISO/IEC/IEEE 29119-3 の「テスト完了報告書」の項目を、この記事の章と対応させました。

IEEE 829 は 2008年版のあと、ISO/IEC/IEEE 29119-3 に置き換えられています。 2008年版では、テストレベルごとの「Level Test Report」と、全体の「Master Test Report」に分かれました。29119-3 では、テストの記録を残す文書として「テスト完了報告書（Test Completion Report）」の名前で決められていて、「再利用できるテスト資産」「教訓（Lessons learned）」の項目があるのが特徴です。次のテストで使えるものと、うまくいかなかったことを残します。

JSTQB（ISTQB）のシラバスでも、テストの終わりに「テスト完了レポート」を作り、関係者に伝えることが、テスト完了の活動として書かれています。

コピペ用テンプレート（Markdown）

そのまま貼って、（ ） を埋めて使えます。 表の数字は、テスト進捗管理表と不具合管理表から転記します。

# テスト完了報告書（○○システム 結合テスト）

| 項目 | 内容 |
|---|---|
| 文書番号 / 版 | （TR-IT-001 / 1.0） |
| 作成日 / 作成者 | （2026-10-13 / ○○） |
| 対象 | （○○システム v1.2.0、コミット abc1234） |
| テスト期間 | （2026-09-14 〜 2026-10-09、20営業日） |
| 関連文書 | （テスト計画書 TP-001 v1.1、テスト仕様書 TS-IT-001〜004、不具合管理表） |

## 1. 結論
- リリース可否の判断（案）：（条件付きで可 / 可 / 否）
- 理由：（終了基準 6 項目中 5 項目を満たした。未達の 1 項目は〜のため、〜を条件とする）

## 2. 目的・範囲
- 目的：（結合テストの終了基準を満たし、システムテストに進めるかを判断する）
- 範囲：（機能 A〜F の画面・API・バッチの結合）
- 対象外：（性能・負荷はシステムテストで実施。外部決済はモックで代替）

## 3. 実施結果
| 区分 | 件数 | 割合 |
|---|---|---|
| 予定 | （ ） | 100% |
| 実施 | （ ） | （ ） |
| 　合格 | （ ） | （ ） |
| 　不合格 | （ ） | （ ） |
| 　保留（前提が整わず判定できない） | （ ） | （ ） |
| 未実施 | （ ） | （ ） |

## 4. 消化率
- 消化率（実施 ÷ 予定）：（ ）%
- 未実施の内訳と理由：（ ）

## 5. 不具合の集計
### 5.1 重大度別
| 重大度 | 見つかった | 直した | 未解決 |
|---|---|---|---|
| 重大 | | | |
| 高 | | | |
| 中 | | | |
| 低 | | | |
| 計 | | | |

### 5.2 原因別・機能別
| 原因 | 件数 | 主な例 |
|---|---|---|
| 仕様の誤り・もれ | | |
| 設計の誤り | | |
| 実装の誤り | | |
| テストの誤り（不具合ではない） | | |

### 5.3 密度
| 指標 | 値 | 目標・過去の値 | 判定 |
|---|---|---|---|
| テスト密度（件/KLOC） | | | |
| バグ密度（件/KLOC） | | | |

## 6. 計画との差異
| 計画 | 実際 | 理由 | 影響 |
|---|---|---|---|
| | | | |

## 7. 品質の評価
### 7.1 終了基準ごとの判定
| 終了基準（テスト計画書より） | 結果 | 判定 |
|---|---|---|
| | | |

### 7.2 バグ曲線
- （累積の見つかった件数・直した件数のグラフ）
- 収束の判断：（ ）

### 7.3 総合評価
- （数字から言えること、弱い機能、追加で行ったテスト）

## 8. 残課題・リスク
| No | 内容 | 影響 | 対応 | 期限 | 担当 |
|---|---|---|---|---|---|
| | | | | | |

## 9. リリース可否の判断
- 判断：（ ）
- 条件：（ ）
- 承認：（品質管理責任者 ○○ / 日付）、（プロジェクト責任者 ○○ / 日付）

## 付録
- 教訓（次に生かすこと）：（ ）
- 再利用できるテスト資産：（自動テスト、テストデータ、手順書）

数値の書き方と計算

報告書の数字は、定義（何を何で割ったか）を必ず書きます。 同じ「合格率」でも、分母を「実施した件数」にするか「予定の件数」にするかで値が変わるためです。

計算に使う式

KLOC は千行（Kilo Lines Of Code）です。 規模の数え方（コメント・空行を含むか、自動生成のコードを含むか）は、比べる相手（過去のプロジェクト・社内の基準）とそろえます。指標の一覧と式は、関連記事「品質管理の指標一覧（システム開発）｜バグ密度・レビュー指摘密度の計算式」で扱っています。

Python で計算した例

結合テストの例のデータ（規模 24.5 KLOC、テストケース 520件、20営業日）で計算しました。

"""テスト完了報告書の数値を計算する（結合テストの例）"""
import numpy as np
from scipy.optimize import curve_fit

# ---- 入力（テスト進捗管理表・不具合管理表から転記） ----
ksloc = 24.5                      # 対象の規模（千行、コメント・空行を除く）
planned, executed = 520, 512      # 予定・実施したテストケース数
passed, failed, blocked = 498, 9, 5   # 実施 512 件の内訳（blocked は実施したが前提が整わず判定できない）
# 日ごとの不具合の「見つかった件数」と「直した件数」（20営業日）
found  = [3, 5, 8, 9, 7, 8, 6, 5, 4, 4, 3, 2, 3, 1, 2, 1, 0, 1, 0, 0]
closed = [0, 2, 4, 6, 7, 8, 7, 6, 5, 5, 4, 3, 3, 2, 2, 1, 1, 1, 1, 0]
severity = {"重大": 2, "高": 9, "中": 31, "低": 30}   # 見つかった不具合の重大度別

# ---- 消化率・合格率 ----
print(f"消化率（実施 ÷ 予定）        {executed / planned:6.1%}  ({executed}/{planned})")
print(f"合格率（合格 ÷ 実施）        {passed / executed:6.1%}  ({passed}/{executed})")
print(f"合格率（合格 ÷ 予定）        {passed / planned:6.1%}  ({passed}/{planned})")

# ---- 密度 ----
total_bugs = sum(found)
assert total_bugs == sum(severity.values())
print(f"テスト密度                   {planned / ksloc:6.1f} 件/KLOC")
print(f"バグ密度                     {total_bugs / ksloc:6.2f} 件/KLOC  ({total_bugs} 件)")
print(f"テスト1件あたりの不具合      {total_bugs / executed:6.3f} 件")

# ---- 未解決 ----
cum_found, cum_closed = np.cumsum(found), np.cumsum(closed)
print(f"未解決（見つかった − 直した） {cum_found[-1] - cum_closed[-1]} 件")

# ---- 収束の判断（直近5日） ----
last5 = sum(found[-5:])
print(f"直近5日の新規               {last5} 件（全体の {last5 / total_bugs:.1%}）")

# ---- 信頼度成長曲線（ゴンペルツ曲線）で、最終的な不具合の数を推定 ----
def gompertz(t, a, b, c):
    return a * np.exp(-b * np.exp(-c * t))

t = np.arange(1, len(found) + 1)
(a, b, c), _ = curve_fit(gompertz, t, cum_found, p0=(cum_found[-1] * 1.1, 5, 0.2), maxfev=10000)
print(f"ゴンペルツ曲線の a（収束値）  {a:.1f} 件 → 今の累積 {cum_found[-1]} 件は推定の {cum_found[-1] / a:.1%}")
print(f"推定の残り                   {a - cum_found[-1]:.1f} 件")
for day in (10, 15, 20):
    print(f"  {day:>2}日目  実際 {cum_found[day - 1]:>2} 件 / 曲線 {gompertz(day, a, b, c):5.1f} 件")

print("累積（見つかった）", cum_found.tolist())
print("累積（直した）    ", cum_closed.tolist())

消化率（実施 ÷ 予定）         98.5%  (512/520)
合格率（合格 ÷ 実施）         97.3%  (498/512)
合格率（合格 ÷ 予定）         95.8%  (498/520)
テスト密度                     21.2 件/KLOC
バグ密度                       2.94 件/KLOC  (72 件)
テスト1件あたりの不具合       0.141 件
未解決（見つかった − 直した） 4 件
直近5日の新規               2 件（全体の 2.8%）
ゴンペルツ曲線の a（収束値）  72.6 件 → 今の累積 72 件は推定の 99.2%
推定の残り                   0.6 件
  10日目  実際 59 件 / 曲線  59.9 件
  15日目  実際 70 件 / 曲線  69.5 件
  20日目  実際 72 件 / 曲線  71.9 件
累積（見つかった） [3, 8, 16, 25, 32, 40, 46, 51, 55, 59, 62, 64, 67, 68, 70, 71, 71, 72, 72, 72]
累積（直した）     [0, 2, 6, 12, 19, 27, 34, 40, 45, 50, 54, 57, 60, 62, 64, 65, 66, 67, 68, 68]

バグ密度は、高くても低くても理由を書きます。 高いなら「どの機能に集中したか」、低いなら「テストが足りなかったのではないか（テスト密度・観点の抜け）」を確かめた結果を書きます。数字だけ書いて「問題なし」とすると、レビューで必ず聞かれます。

バグ曲線の収束の判断

バグ曲線は、累積の「見つかった件数」と「直した件数」を日ごとに並べたグラフです。 見つかった件数の線が寝てきて（新しく見つからなくなり）、直した件数の線が追いついていれば、収束に近づいています。

xychart-beta
    title "バグ曲線（累積）"
    x-axis "営業日" [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]
    y-axis "件数" 0 --> 80
    line [3, 8, 16, 25, 32, 40, 46, 51, 55, 59, 62, 64, 67, 68, 70, 71, 71, 72, 72, 72]
    line [0, 2, 6, 12, 19, 27, 34, 40, 45, 50, 54, 57, 60, 62, 64, 65, 66, 67, 68, 68]

上の線が見つかった件数、下の線が直した件数です。この例では、16日目以降はほとんど増えず、20日目で 72件・68件です。

収束の判断は、1つの指標ではなく、次の表を組み合わせて書きます。

「見つからなくなった」のは、テストを流しきったからか、テストが止まっていたからかを分けて書きます。 消化率と並べると区別できます。進み具合の管理とバグ曲線の読み方は、関連記事「テスト進捗管理表テンプレート｜消化率の計算とバグ曲線の読み方」で扱っています。

信頼度成長曲線（ゴンペルツ曲線）を使うときの注意

信頼度成長曲線は、累積の不具合の数を S 字の曲線に当てはめ、最終的に見つかる数（収束値）を推定する方法です。 上の計算では、ゴンペルツ曲線の収束値は 72.6件で、今の累積 72件は推定の 99.2% でした。

ただし、終盤まで不具合が見つかり続けているデータでも、曲線は「ほぼ収束」に見えることがあります。 終盤の 5日で 20件見つかり続けたデータで同じ計算をしました。

found = [3, 5, 8, 9, 7, 8, 6, 5, 4, 4, 3, 2, 3, 4, 5, 3, 4, 5, 4, 4]   # 終盤も見つかり続ける

見つかり続けている例でも、20日目の「累積 ÷ 推定」は 96.1% になりました。 一方で、推定の収束値は 3日で 83.4件から 99.9件に動いています。曲線を使うときは、推定の値が日を追って安定しているかも一緒に見て、直近の新規の件数と合わせて判断します。

記入例

上の計算の数字で、主な章を埋めた例です。

## 1. 結論
- リリース可否の判断（案）：**条件付きで、システムテストへ進めてよい**
- 理由：終了基準 6 項目中 5 項目を満たした。未達の「全件消化」は、外部連携の 8 件が
  連携先の環境の都合で実施できなかったため。システムテストの初週に実施することを条件とする。

## 3. 実施結果
| 区分 | 件数 | 割合 |
|---|---|---|
| 予定 | 520 | 100% |
| 実施 | 512 | 98.5% |
| 　合格 | 498 | 95.8%（予定比）/ 97.3%（実施比） |
| 　不合格 | 9 | 1.8%（実施比） |
| 　保留 | 5 | 1.0%（実施比） |
| 未実施 | 8 | 1.5% |

## 5.1 重大度別
| 重大度 | 見つかった | 直した | 未解決 |
|---|---|---|---|
| 重大 | 2 | 2 | 0 |
| 高 | 9 | 9 | 0 |
| 中 | 31 | 29 | 2 |
| 低 | 30 | 28 | 2 |
| 計 | 72 | 68 | 4 |

## 5.3 密度
| 指標 | 値 | 目標・過去の値 | 判定 |
|---|---|---|---|
| テスト密度 | 21.2 件/KLOC | 目標 20 以上 | 満たす |
| バグ密度 | 2.94 件/KLOC | 過去 3 案件 2.1〜3.4 | 範囲内 |

## 7.1 終了基準ごとの判定
| 終了基準（テスト計画書 TP-001 4.2 節） | 結果 | 判定 |
|---|---|---|
| 予定のテストケースを全件消化 | 98.5%（未実施 8 件） | **未達**（条件付きで可） |
| 重大・高の未解決が 0 件 | 0 件 | 満たす |
| 中・低の未解決は対応方針が決まっている | 4 件すべて方針あり | 満たす |
| 直近 5 日の新規が 3 件以下 | 2 件（いずれも低） | 満たす |
| テスト密度が 20 件/KLOC 以上 | 21.2 | 満たす |
| バグ密度が過去の範囲内 | 2.94（範囲 2.1〜3.4） | 満たす |

## 7.3 総合評価
- 不具合 72 件のうち 28 件（39%）が機能 C（請求計算）に集中した。
  原因は仕様の読み違い（端数処理）で、機能 C は観点を追加して 36 件のテストを追加実施し、
  追加分で新たな不具合は見つかっていない。
- 16 日目以降の新規は 2 件で、いずれも重大度「低」（画面の文言）。

## 8. 残課題・リスク
| No | 内容 | 影響 | 対応 | 期限 | 担当 |
|---|---|---|---|---|---|
| 1 | 外部連携 8 件が未実施 | 連携の不具合が残る可能性 | システムテスト初週に実施 | 10/16 | 佐藤 |
| 2 | 未解決の中 2 件（BUG-061, 066） | 一覧画面の並び順が一部違う | リリース前に修正 | 10/20 | 田中 |
| 3 | 未解決の低 2 件（BUG-070, 072） | 文言の誤り | 次の版で修正（利用者へ周知） | 11/30 | 田中 |

「総合評価」には、数字から読み取ったこと（どこに集中したか、なぜか、何をしたか）を書きます。 「品質は良好と判断する」だけでは、読む人が判断の根拠を確かめられません。

レビューでよく指摘される点

計画書に書いた終了基準と、報告書の判定の表が1対1で対応しているかを、最後に見比べます。計画書の終了基準の書き方は、関連記事「テスト計画書の書き方と項目一覧｜開始基準・終了基準のテンプレート」で扱っています。

よくある質問

Q. テスト完了報告書とテスト結果報告書は違うものですか？ A. 呼び方の違いで、中身はほぼ同じです。IEEE 829 では「テストサマリー報告書（Test Summary Report）」、ISO/IEC/IEEE 29119-3 や JSTQB では「テスト完了報告書（テスト完了レポート）」と呼びます。テスト中に定期的に出すものは「テスト進捗報告書」で、別のものです。

Q. 終了基準を満たしていないと、リリースできませんか？ A. 判断するのは、報告書を受け取る人（品質管理の責任者・発注者など）です。報告書では、満たしていない基準・理由・影響・条件を示し、判断に要る材料をそろえます。「条件付きで可」とする場合は、条件と期限を書きます。

Q. 自動テストの結果はどう書きますか？ A. 手で行ったテストと分けて、件数・成功・失敗と、どの CI の実行の結果か（日時・コミット）を書きます。どこまでを自動テストで確かめたかを範囲の章に書くと、二重に数えずに済みます。

Q. 受入テストやシステムテストでも同じ形で使えますか？ A. 使えます。終了基準と、範囲（業務シナリオ・非機能）の書き方が変わります。システムテストの観点は、関連記事「システムテストとは｜結合テストとの違いと観点一覧」で、受入テストは「受入テストの観点チェックリストとUATシナリオの書き方」で扱っています。

まとめ

• テスト完了報告書は 「終了基準を満たしたか」「残ったリスク」「リリース可否」 を判断する人に渡す文書
• 項目は IEEE 829 のテストサマリー報告書・ISO/IEC/IEEE 29119-3 のテスト完了報告書と対応させると抜けが減る
• 結論は1章に。数字には式と分母を書く（例：合格 498 ÷ 実施 512 = 97.3%）
• バグ密度・テスト密度は、目標・過去の値と並べて、理由まで書く
• バグ曲線の収束は 直近の新規・未解決・重大度・消化率を組み合わせて判断する
• ゴンペルツ曲線は、見つかり続けているデータでも「96%」に見えることがある。推定の値が安定しているかも見る
• 残課題は 内容・影響・対応・期限・担当 の表にする

参考・出典

確認日はいずれも 2026年10月13日です。

• University of Otago「IEEE Software Test Documentation, a summary」（IEEE 829 のテストサマリー報告書の項目）：https://www.cs.otago.ac.nz/cosc345/lecs/lec22/testplan.htm
• Wikipedia「Software test documentation」（IEEE 829-2008 と ISO/IEC/IEEE 29119-3）：https://en.wikipedia.org/wiki/Software_test_documentation
• The University of Edinburgh「ISO 29119-3 Overview」（テスト完了報告書の見出し）：https://opencourse.inf.ed.ac.uk/sites/default/files/https/opencourse.inf.ed.ac.uk/st/2024/iso-29119-3-examples.pdf
• ANSI Webstore「ISO/IEC/IEEE 29119-3:2013 プレビュー」（目次）：https://webstore.ansi.org/preview-pages/ISO/preview_ISO+IEC+IEEE+29119-3-2013.pdf
• ISTQB「Certified Tester Foundation Level Syllabus v4.0.1」：https://istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_Syllabus_v4.0.1.pdf
• JSTQB「シラバス・用語集」：https://jstqb.jp/syllabus.html
• SciPy ドキュメント「scipy.optimize.curve_fit」：https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.curve_fit.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。