テスト計画書の書き方と項目一覧｜開始基準・終了基準のテンプレート

テスト計画書とは、何を・どこまで・誰が・いつ・どの基準でテストするかを、テストを始める前に合意するための文書です。 個々のテストケースを書くテスト仕様書とは役割が違い、範囲・方針・体制・日程・基準といった「テスト全体の進め方」を決めます。

この記事では、テスト文書の国際規格 ISO/IEC/IEEE 29119-3:2021 のテスト計画の見出しに沿った項目一覧と、コピーして使える Markdown のテンプレート全文、架空の「会議室の予約受付システム」での記入例を載せます。さらに、開始基準・中断基準・再開基準・終了基準をテストレベル別の早見表にして数値例を入れ、集計値が終了基準を満たすかを判定する Python コードを実行結果つきで示します。

確認環境：Ubuntu 24.04、Python 3.11.15（判定コードはこの環境で実行した出力を掲載）。規格の見出しは、公開されている ISO/IEC/IEEE 29119-3:2021 の目次で確認しました。

テスト計画書の項目早見表

ISO/IEC/IEEE 29119-3:2021 の「7.2 Test plan」には、概要（7.2.1）に続いて次の9つの見出しがあります。日本語の項目名と「書くこと」は、この記事での整理です。

基準の4種類は次のとおりです。

テスト計画書とテスト仕様書の違い

規模が大きいときは、全体をまとめた計画書（全体テスト計画）と、テストレベルごとの計画書（システムテスト計画など）に分けます。小さな開発では1つにまとめ、基準の表だけをレベル別に書く形で足ります。

テスト計画書のテンプレート（Markdown全文）

次のブロックをそのままコピーして使えます。{ } の部分を書き換えてください。

# {システム名} {テストレベル}テスト計画書

| 項目 | 内容 |
|---|---|
| 文書番号 | {TP-001} |
| 版 | {1.0} |
| 作成日 | {YYYY-MM-DD} |
| 作成者 | {氏名} |
| 承認者 | {氏名} |

## 改訂履歴

| 版 | 日付 | 変更箇所 | 理由 | 変更者 |
|---|---|---|---|---|
| 1.0 | {YYYY-MM-DD} | 新規作成 | - | {氏名} |

## 1. テストの背景と範囲

### 1.1 目的
{このテストで確かめたいことを1〜3文で}

### 1.2 対象
| 項目 | 内容 |
|---|---|
| 対象システム | {名称と版} |
| テストレベル | {単体 / 結合 / システム / 受け入れ} |
| 参照する文書 | {要件定義書 版、基本設計書 版} |

### 1.3 テストする範囲
| 番号 | 機能・特性 | 対応する要件 |
|---|---|---|
| 1 | {機能名} | {要件番号} |

### 1.4 テストしない範囲と理由
| 番号 | 機能・特性 | 理由 |
|---|---|---|
| 1 | {機能名} | {理由。別の計画で扱う場合はその文書名} |

## 2. 前提と制約
- 前提: {例: 結合テストが終了基準を満たしている}
- 制約: {例: 検証環境は平日 9:00〜20:00 のみ使える}

## 3. 関係者
| 役割 | 氏名・部門 | 関わり方 |
|---|---|---|
| 計画の承認 | {氏名} | 計画と終了判定を承認 |
| 結果の受け取り | {部門} | 報告を受け、受け入れを判断 |
| 協力 | {部門} | 環境・データ・仕様の質問に対応 |

## 4. 連絡と報告
| 種類 | 頻度 | 形式 | 宛先 |
|---|---|---|---|
| 進み具合の報告 | {毎日 / 週1回} | {消化率・合格率・不具合件数の表} | {宛先} |
| 不具合の連絡 | 見つけた当日 | {不具合票} | {開発の担当} |
| 中断・再開の判断 | 発生時 | {連絡手段} | {テスト責任者} |
| 終了の報告 | 終了時 | テスト完了報告書 | {承認者} |

## 5. リスク一覧
| 番号 | 種類 | リスク | 影響 | 起こりやすさ | 対策 |
|---|---|---|---|---|---|
| 1 | {製品 / 進行} | {内容} | {大/中/小} | {高/中/低} | {対策} |

## 6. テスト戦略

### 6.1 テストの種類と技法
| テストの種類 | 目的 | 使う技法 | ケース数の見込み |
|---|---|---|---|
| {機能テスト} | {目的} | {同値分割・境界値分析 など} | {件数} |

### 6.2 成果物
| 成果物 | 作成者 | 完成の時期 |
|---|---|---|
| テスト仕様書 | {氏名} | {日付} |
| 不具合票 | 実行者 | 随時 |
| テスト完了報告書 | {氏名} | {日付} |

### 6.3 テスト環境
| 項目 | 内容 |
|---|---|
| サーバー | {構成} |
| クライアント | {OS・ブラウザーと版} |
| 連携先 | {本物 / 代わりのスタブ} |

### 6.4 テストデータ
{用意する方法、件数、個人を特定できる情報の扱い}

### 6.5 開始基準
- {例: 前の工程の終了基準を満たしている}
- {例: テストケースのレビューが完了している}

### 6.6 中断基準と再開基準
| 中断する状態 | 再開する状態 |
|---|---|
| {例: 残りケースの30%以上が実行できない} | {例: 原因の修正を確認し、再テストの範囲を決めた} |

### 6.7 終了基準
| 指標 | 基準 |
|---|---|
| 消化率（実行済み ÷ 計画） | {100%} |
| 合格率（合格 ÷ 実行済み） | {98%以上} |
| 未解決の不具合（重大） | {0件} |
| 未解決の不具合（中） | {0件} |
| 未解決の不具合（軽微） | {5件以下。対応時期が合意済みであること} |
| 要件カバレッジ | {100%} |

### 6.8 再テストと回帰テスト
{修正の確認方法、回帰テストの範囲の決め方}

### 6.9 集める数値
{消化率、合格率、不具合の件数（重要度別・原因別）、ケースあたりの実行時間 など}

## 7. 作業と見積もり
| 番号 | 作業 | 成果 | 見積もり（人日） |
|---|---|---|---|
| 1 | テスト設計 | テスト仕様書 | {日数} |
| 2 | 環境とデータの準備 | 環境の確認記録 | {日数} |
| 3 | テスト実行 | 実行結果、不具合票 | {日数} |
| 4 | 再テスト・回帰テスト | 実行結果 | {日数} |
| 5 | 報告 | テスト完了報告書 | {日数} |

## 8. 体制
| 役割 | 担当 | 人数 | 主な作業 |
|---|---|---|---|
| テスト責任者 | {氏名} | 1 | 計画、進み具合の管理、終了判定の提案 |
| テスト設計者 | {氏名} | {人数} | テスト仕様書の作成 |
| テスト実行者 | {氏名} | {人数} | 実行、不具合票の起票 |

必要な教育: {例: 業務の流れの説明会、不具合票の書き方}

## 9. 日程
| 作業 | 開始日 | 終了日 | 節目 |
|---|---|---|---|
| テスト設計 | {日付} | {日付} | 仕様書レビュー完了 |
| テスト実行 | {日付} | {日付} | 開始判定 / 終了判定 |

記入例：会議室の予約受付システム（システムテスト）

架空の社内向けシステムを題材に、判断が分かれやすい章を中心に記入した例です。

# 会議室予約受付システム システムテスト計画書

| 項目 | 内容 |
|---|---|
| 文書番号 | TP-ST-001 |
| 版 | 1.0 |
| 作成日 | 2026-09-24 |

## 1. テストの背景と範囲

### 1.1 目的
結合テストを終えた会議室予約受付システム 1.0 が、要件定義書の機能要件42件と
応答時間・同時利用の要件を満たすことを、利用時と同じ構成の検証環境で確かめる。

### 1.3 テストする範囲
| 番号 | 機能・特性 | 対応する要件 |
|---|---|---|
| 1 | 予約の登録・変更・取消 | F-01〜F-12 |
| 2 | 空き状況の検索と一覧表示 | F-13〜F-20 |
| 3 | 通知メール（登録・前日・取消） | F-21〜F-27 |
| 4 | 管理者機能（会議室マスタ、利用状況の出力） | F-28〜F-42 |
| 5 | 応答時間（検索 2秒以内） | N-01 |
| 6 | 同時利用（100人が同時に操作） | N-02 |

### 1.4 テストしない範囲と理由
| 番号 | 機能・特性 | 理由 |
|---|---|---|
| 1 | 社員マスタ管理システム側の動き | 相手先のテスト計画で扱う。本計画では連携の結果だけを確かめる |
| 2 | スマートフォン向け画面 | 1.1 で提供予定のため |

## 2. 前提と制約
- 前提: 結合テストの終了基準（合格率 100%、未解決の重大・中の不具合 0 件）を満たしている
- 前提: 社員マスタ連携は、相手先の検証環境に接続できる
- 制約: 検証環境は平日 9:00〜20:00 に使える。負荷をかけるテストは 18:00 以降に行う
- 制約: 利用開始は 2026-11-02。終了判定は 2026-10-23 までに行う

## 5. リスク一覧
| 番号 | 種類 | リスク | 影響 | 起こりやすさ | 対策 |
|---|---|---|---|---|---|
| 1 | 製品 | 同じ会議室の同じ時間帯に予約が二重に入る | 大 | 中 | 同時操作のケースを20件用意し、最初の週に実行 |
| 2 | 製品 | 前日通知が休日をまたぐと届かない | 中 | 中 | 日付を変えた環境で休日前後を確認 |
| 3 | 進行 | 相手先の検証環境が使えない日がある | 中 | 高 | 利用できる日を事前に確認し、連携のケースを前半に置く |
| 4 | 進行 | 不具合の修正が遅れ、再テストが後半に集中する | 大 | 中 | 重大・中は起票から2営業日以内に修正版を受け取る取り決めにする |

## 6. テスト戦略

### 6.1 テストの種類と技法
| テストの種類 | 目的 | 使う技法 | ケース数の見込み |
|---|---|---|---|
| 機能テスト | 要件どおりに動くことの確認 | 同値分割、境界値分析、デシジョンテーブル | 180 |
| 業務の流れのテスト | 登録から利用、取消までを通す | シナリオテスト | 30 |
| 性能テスト | 応答時間と同時利用の確認 | 負荷をかけた計測 | 10 |
| 権限のテスト | 役割ごとに操作できる範囲の確認 | 権限表の全組み合わせ | 20 |
| 合計 | | | 240 |

### 6.5 開始基準
- 結合テストの完了報告書が承認されている
- テスト仕様書 240 件のレビューが完了し、重要度「高」「中」の指摘がすべて反映されている
- 検証環境で、ログイン・予約登録・通知メールの3点の疎通を確認済み
- テストデータ（会議室 30 室、社員 500 人、予約 5,000 件）の投入が完了している

### 6.6 中断基準と再開基準
| 中断する状態 | 再開する状態 |
|---|---|
| 重大な不具合で、残りケースの 30% 以上が実行できない | 修正版で不具合の解消を確認し、再テストの範囲を決めた |
| 検証環境が連続4時間以上使えない | 環境の復旧後、疎通確認の3点が合格した |
| 1日に見つかった不具合が 15 件を超えた | 原因を分析し、開発側の確認を終えた修正版を受け取った |

### 6.7 終了基準
| 指標 | 基準 |
|---|---|
| 消化率（実行済み ÷ 計画） | 100% |
| 合格率（合格 ÷ 実行済み） | 98% 以上 |
| 未解決の不具合（重大） | 0 件 |
| 未解決の不具合（中） | 0 件 |
| 未解決の不具合（軽微） | 5 件以下。対応時期が合意済みであること |
| 要件カバレッジ | 100%（42件すべてに合格したケースがある） |

## 7. 作業と見積もり
| 番号 | 作業 | 成果 | 見積もり（人日） |
|---|---|---|---|
| 1 | テスト設計 | テスト仕様書 240 件 | 12 |
| 2 | 環境とデータの準備 | 環境の確認記録 | 3 |
| 3 | テスト実行 | 実行結果、不具合票 | 16 |
| 4 | 再テスト・回帰テスト | 実行結果 | 6 |
| 5 | 報告 | テスト完了報告書 | 2 |
| | 合計 | | 39 |

## 9. 日程
| 作業 | 開始日 | 終了日 | 節目 |
|---|---|---|---|
| テスト設計 | 2026-09-24 | 2026-10-02 | 10-02 仕様書レビュー完了 |
| 環境とデータの準備 | 2026-10-01 | 2026-10-05 | 10-05 開始判定 |
| テスト実行 | 2026-10-06 | 2026-10-16 | 10-16 中間の判定 |
| 再テスト・回帰テスト | 2026-10-19 | 2026-10-22 | |
| 報告 | 2026-10-23 | 2026-10-23 | 10-23 終了判定 |

記入のポイントは次の3つです。

• 範囲は要件番号で書く：「予約機能」だけでは境界が伝わりません。要件番号を並べると、要件カバレッジをそのまま数えられます。
• テストしない範囲に理由を添える：あとから「なぜ対象に入っていないのか」を問われたとき、合意の記録になります。
• 基準は数えられる形にする：「十分にテストした」ではなく、消化率・合格率・件数で書くと、判定がその場で終わります。

開始基準・中断基準・再開基準・終了基準のテストレベル別早見表

数値は、規模や求められる品質に合わせて調整するための出発点です。そのまま使うのではなく、関係者と合意した値に書き換えてください。

表計算ソフトに貼る場合は、次のタブ区切りを使えます。

テストレベル  開始基準    中断基準    再開基準    終了基準
単体テスト   詳細設計書のレビュー完了。コードが静的解析で警告 0 件。ビルドが通る ビルドが通らない。共通部品の不具合で対象の 50% 以上が実行できない ビルドが通り、原因の修正を確認 消化率 100%、合格率 100%、命令網羅 80% 以上・分岐網羅 70% 以上、未解決の不具合 0 件
結合テスト   単体テストの終了基準を達成。インターフェース仕様が確定。結合する相手またはスタブが用意済み   連携の不具合で残りケースの 30% 以上が実行できない 修正版で連携の疎通を確認    消化率 100%、合格率 100%、インターフェースの全項目を1回以上確認、未解決は重大 0 件・中 0 件
システムテスト 結合テストの終了基準を達成。テストケースのレビュー完了 100%。検証環境の疎通確認が完了。テストデータの投入が完了  重大な不具合で残りケースの 30% 以上が実行できない。環境が連続4時間以上使えない。1日の不具合が 15 件超    修正の確認と、再テスト範囲の確定    消化率 100%、合格率 98% 以上、要件カバレッジ 100%、未解決は重大 0 件・中 0 件・軽微 5 件以下
受け入れテスト システムテストの完了報告が承認済み。利用部門の担当者と日程が確定。操作手順書が配布済み 主要な業務の流れが最後まで通らない   修正版で主要な業務の流れを通しで確認  業務シナリオの消化率 100%、合格率 100%、未解決は重大 0 件・中 0 件、軽微は対応時期を合意、利用部門の責任者が承認

指標の計算式は、計画書の中で定義しておきます。

終了基準を満たすかをPythonで判定する

集計した件数を JSON に書き、終了基準と比べて判定するコードです。標準ライブラリだけで動きます。基準の値は、計画書の「6.7 終了基準」と同じにします。

"""テストの集計値が終了基準を満たすかを判定する。"""
import json
import sys

# 終了基準（テスト計画書の「終了基準」と同じ値を書く）
CRITERIA = {
    "消化率": (">=", 100.0),          # 実行済み ÷ 計画
    "合格率": (">=", 98.0),           # 合格 ÷ 実行済み
    "未解決の不具合（重大）": ("<=", 0),
    "未解決の不具合（中）": ("<=", 0),
    "未解決の不具合（軽微）": ("<=", 5),
    "要件カバレッジ": (">=", 100.0),  # テスト済みの要件 ÷ 全要件
}


def measure(d):
    """集計した件数から、基準と比べる値を作る。"""
    return {
        "消化率": d["executed"] / d["planned"] * 100,
        "合格率": d["passed"] / d["executed"] * 100 if d["executed"] else 0.0,
        "未解決の不具合（重大）": d["open_defects"]["critical"],
        "未解決の不具合（中）": d["open_defects"]["major"],
        "未解決の不具合（軽微）": d["open_defects"]["minor"],
        "要件カバレッジ": d["requirements_tested"] / d["requirements_total"] * 100,
    }


def judge(d):
    values = measure(d)
    all_ok = True
    print(f"== {d['name']} ==")
    for key, (op, limit) in CRITERIA.items():
        v = values[key]
        ok = v >= limit if op == ">=" else v <= limit
        all_ok = all_ok and ok
        shown = f"{v:.1f}%" if isinstance(limit, float) else f"{v}件"
        target = f"{limit:.0f}%" if isinstance(limit, float) else f"{limit}件"
        mark = "OK" if ok else "NG"
        print(f"  [{mark}] {key}: {shown}（基準 {op} {target}）")
    print("  判定:", "終了基準を満たす" if all_ok else "終了基準に届いていない")
    print()
    return all_ok


if __name__ == "__main__":
    with open(sys.argv[1] if len(sys.argv) > 1 else "summary.json", encoding="utf-8") as f:
        results = [judge(d) for d in json.load(f)]
    sys.exit(0 if all(results) else 1)

入力（summary.json）。記入例のシステムテストで、中間の判定日と終了判定日の2時点を入れています。

[
  {
    "name": "システムテスト 10月16日時点",
    "planned": 240, "executed": 228, "passed": 219,
    "open_defects": {"critical": 0, "major": 2, "minor": 6},
    "requirements_total": 42, "requirements_tested": 40
  },
  {
    "name": "システムテスト 10月23日時点",
    "planned": 240, "executed": 240, "passed": 237,
    "open_defects": {"critical": 0, "major": 0, "minor": 3},
    "requirements_total": 42, "requirements_tested": 42
  }
]

実行結果：

$ python3 exit_check.py summary.json
== システムテスト 10月16日時点 ==
  [NG] 消化率: 95.0%（基準 >= 100%）
  [NG] 合格率: 96.1%（基準 >= 98%）
  [OK] 未解決の不具合（重大）: 0件（基準 <= 0件）
  [NG] 未解決の不具合（中）: 2件（基準 <= 0件）
  [NG] 未解決の不具合（軽微）: 6件（基準 <= 5件）
  [NG] 要件カバレッジ: 95.2%（基準 >= 100%）
  判定: 終了基準に届いていない

== システムテスト 10月23日時点 ==
  [OK] 消化率: 100.0%（基準 >= 100%）
  [OK] 合格率: 98.8%（基準 >= 98%）
  [OK] 未解決の不具合（重大）: 0件（基準 <= 0件）
  [OK] 未解決の不具合（中）: 0件（基準 <= 0件）
  [OK] 未解決の不具合（軽微）: 3件（基準 <= 5件）
  [OK] 要件カバレッジ: 100.0%（基準 >= 100%）
  判定: 終了基準を満たす
$ echo $?
1

10月16日時点では、消化率 95.0%（228 ÷ 240）、合格率 96.1%（219 ÷ 228）などが基準に届かず、判定は「終了基準に届いていない」です。10月23日時点では6つの指標がすべて基準内に入り、「終了基準を満たす」になりました。どの指標があとどれだけ足りないかが1行ずつ出るので、残りの作業の見通しを立てやすくなります。

終了コードは、1時点でも基準に届いていなければ 1 を返します。最新の1時点だけを JSON に入れて実行すれば、自動化した処理の中で「基準を満たしたら次へ進む」という条件に使えます。

書くときに押さえたいポイント

よくある質問

Q. テスト計画書は、どの時点で作りますか？ A. 要件が固まり、テスト設計を始める前に作ります。全体の計画は要件定義から基本設計の間、テストレベルごとの計画はそのレベルのテスト設計を始める前が目安です。

Q. 小さな開発でも、9項目すべてを書く必要がありますか？ A. 項目は残し、内容を短くするのがおすすめです。「関係者」「連絡と報告」は表1つ、「リスク一覧」は3行でも、合意の記録として役に立ちます。当てはまらない項目は「該当なし」と理由を書きます。

Q. 合格率は 100% にすべきですか？ A. 単体・結合テストは 100% を基準にすることが多く、システムテストでは軽微な不具合を残す条件を決めたうえで 98% 以上のように置く例があります。値そのものより、残す不具合の重要度と対応時期を合意しておくことが大切です。

Q. 終了基準に届かないまま期日が来たら、どうしますか？ A. 届いていない指標と理由、残した場合の影響、追加で必要な日数を並べて、計画の承認者に判断を仰ぎます。基準を変える場合は計画書の版を上げ、変更の理由を改訂履歴に残します。

まとめ

• テスト計画書は、範囲・方針・体制・日程・基準を、テストを始める前に合意する文書
• 項目は ISO/IEC/IEEE 29119-3:2021 のテスト計画の9つの見出し（背景と範囲、前提と制約、関係者、連絡と報告、リスク一覧、テスト戦略、作業と見積もり、体制、日程）に沿って並べる
• 開始・中断・再開・終了の4つの基準はテスト戦略の中に書き、数えられる値にする
• 終了基準は消化率・合格率・未解決の不具合件数・要件カバレッジを組み合わせ、軽微な不具合の扱いまで決める
• 基準はテストレベルごとに変える（単体・結合は合格率 100%、システムテストは 98% 以上と残す条件、受け入れは責任者の承認）
• 集計値を入れて基準と比べるコードを用意しておくと、判定と残り作業の把握が早くなる

参考・出典

• ISO/IEC/IEEE 29119-3:2021 Software and systems engineering — Software testing — Part 3: Test documentation（公開されている目次で 7.2 Test plan の見出しを確認）

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