テスト計画書とは？書き方と記載項目、テスト仕様書との違いと終了基準の決め方

テスト計画書は、テストの範囲・体制・環境・日程と、いつテストを終えてよいかの基準を、テストを始める前に文書で合意するためのものです。本記事では、JSTQBのシラバスが挙げる典型的な記載項目を土台に、テスト仕様書やプロジェクト計画書との違い、範囲と体制の書き方、開始基準と終了基準を数値で書く例、三点見積りによる日程の根拠づけを順に整理します。後半では、発注者がテスト計画書を受入テストと検収につなげて読むときの確認観点まで扱います。

まとめ：テスト計画書は範囲と終了基準を実施前に固めて検収の争点を減らす文書

テスト計画書で一番効くのは、テストケースの数よりも「何をテストしないか」と「何が満たされたら終えるか」を先に書いておくことです。対象外と終了基準が空欄の計画書は、テスト工程の終盤で「まだ足りない」「もう十分」の言い合いを生みます。

記載項目は、テストの概要と範囲、前提と制約、体制、コミュニケーション、リスク、テストアプローチ（テストレベル・環境・データ・開始基準と終了基準）、予算とスケジュールの7系統でそろいます。発注者は全文を精読しなくても、終了基準が数値になっているか、対象外が明記されているか、発注者側の作業と期日が書かれているかの3点を確かめれば、検収で揉める芽を早い段階で摘めます。

テスト計画書とは何か｜テスト仕様書・プロジェクト計画書との違いと作る時期

テスト関連の文書は名前が似ていて、見積書の成果物欄でも混同されがちです。まず定義と、隣り合う文書との境目を押さえます。

テスト計画書の定義と役割｜JSTQBシラバスが挙げる4つの役割で理解する

JSTQBのFoundation Levelシラバス（V4.0・2023年4月12日版）は、5.1.1項でテスト計画書を「テストプロジェクトの目的、リソース、プロセスを表す」文書と定義しています。役割として挙がっているのは、目的を達成する手段とスケジュールの文書化、実施したテストが確立した基準を満たすことの保証、チームとステークホルダーの間のコミュニケーション手段、組織のテストポリシーやテスト戦略への準拠（逸脱する場合はその理由）の4つです。

見落とされやすいのは3つ目です。テスト計画書は開発会社の内部手順書ではなく、発注者を含む関係者に「この範囲を、この体制で、この基準まで確かめます」と約束する文書として読まれます。

テスト仕様書・プロジェクト計画書・テスト報告書との違いと作成の順番

役割と作るタイミングで並べると、次のように分かれます。

テスト計画書は「どこまでやるか」、テスト仕様書は「1件ごとにどう確かめるか」を受け持ちます。テストケースの列構成や期待結果の書き方はテスト仕様書とは？書き方とテストケースの項目・発注者がレビューで見る観点で扱っています。開発全体の計画との関係はプロジェクト計画書の書き方：システム開発で書く項目とテンプレート、発注者と受託側の分担を参照してください。プロジェクト計画書の品質方針を、テストの言葉で具体化したものがテスト計画書だと捉えると位置関係がはっきりします。

全体のテスト計画とテストレベル別の計画書｜規模に応じた作成単位の分け方

中規模以上の案件では、テスト工程全体の方針をまとめた計画書を1冊作り、結合テスト・システムテスト・受入テストごとに詳細な計画書を分けるのが一般的です。全体の計画書には工程の区切りと各工程の終了基準を、レベル別の計画書には担当者・環境・日程の細部を書きます。

画面数が20程度までの小規模案件なら、1冊にまとめて工程ごとの章で書き分ければ十分です。単体テストから受入テストまでの工程の流れ自体はシステム開発のテスト工程とは？種類・流れとV字モデル・発注者が見る判断軸で解説しています。

テスト計画書に書く記載項目｜範囲・体制・環境・データと日程の書き方

項目の名前はテンプレートごとに違いますが、中身はJSTQBシラバスの典型内容にほぼ収まります。

テスト計画書の記載項目7系統｜JSTQBの典型内容と現場の章立ての対応表

シラバス5.1.1項が挙げる典型的な内容と、国内の現場でよく使う章の名前を対応させると次のとおりです。

シラバスは、テスト計画書の内容の詳細はISO/IEC/IEEE 29119-3標準で確認できると述べています。テンプレートを一から作るより、この7系統を目次の骨組みにして、自社の案件に不要な章を削る方が漏れは出ません。

テスト範囲と対象外の書き方｜機能一覧と非機能要件を1枚の表で区切る

範囲の章は、要件定義書の機能一覧をそのまま行に並べ、テストする・しない・別工程で確認する、の3つの区分を列で付けるのが確実です。文章で「主要機能をテストする」と書くと、何が主要なのかで解釈が割れます。

対象外に入りやすいのは、既存システム側の不具合、外部サービスの障害時の挙動、旧データの移行結果、帳票の印字位置などです。性能やセキュリティなどの非機能要件は、要件定義の段階で数値になっていないとテストのしようがありません。IPAが公開している非機能要求グレード2018の利用ガイド第2版（2019年3月28日公開）は、非機能要求の定義漏れを防ぐための道具として作られています。項目の数値化の手順は非機能要件とは？6大項目の数値化とk6での閾値テストまで実装目線で解説が詳しく扱います。

体制と役割分担の書き方｜テストの実施者と合否の判定者を別に書く理由

体制の章で外せないのは、テストを実施する人と、合否を判定する人を別の欄に書くことです。同じ人が実施と判定を兼ねると、不具合の重大度を低く付けて終了基準を満たした形にできてしまいます。

受入テストでは発注者側の業務担当が実施者になるため、氏名と、業務を何日分テストに割けるかまで書きます。テスト期間中に通常業務が詰まって受入テストが進まない遅延は、計画書に担当者の稼働日数を書いた時点で多くが見えるものです。テストデータの提供日や本番相当の環境を用意する日のように、発注者が担う作業にも期日を置きます。

テスト環境とテストデータの書き方｜本番との差分と個人情報の扱いを決める

環境の章には、テスト環境のURL、サーバー構成、対応ブラウザとその版、テスト用アカウントの発行方法を書きます。加えて、本番環境と違う点を表で書き出しておくと、テストで出なかった不具合が本番で出たときの原因の切り分けが早くなります。メール送信先の差し替え、決済サービスのテストモード、外部APIのスタブ化などが典型的な差分です。

テストデータは、本番データを使うか、作成したダミーデータを使うかを決めます。本番の顧客データを使う場合は、氏名・電話番号・メールアドレスのマスキング方法と、テスト後の削除期限まで書いておかないと、テスト環境が個人情報の持ち出し経路になります。

開始基準と終了基準の決め方｜数値で書く合否ラインと時間切れの扱い

テスト計画書の中で、検収と直接つながるのがこの章です。シラバス5.1.3項は、開始基準と終了基準をテストレベルごとに定義すべきだとしています。

開始基準の書き方｜スモークテスト合格と環境・データの準備完了条件

開始基準は、その工程を始めてよい前提条件です。シラバスは典型例として、人・ツール・環境・テストデータ・予算・時間といったリソースが使えること、テストベースやテストケースがそろっていること、テスト対象の初期品質（すべてのスモークテストが合格など）を挙げています。

開始基準を書かずに受入テストへ入ると、ログインや主要画面の表示でつまずく状態のまま発注者の担当者が時間を使うことになります。「システムテストの終了基準を満たし、テスト報告書が提出されていること」を受入テストの開始基準に入れておくと、工程の受け渡しが明確になります。

終了基準を数値で書く例｜要件カバレッジ・未解決欠陥・重大度別の上限

シラバスは終了基準の典型として、達成したカバレッジ、未解決欠陥の数、欠陥密度、不合格のテストケースの数といった測定値と、計画したテストの実行完了などを挙げています。システムテストの終了基準を書くと、たとえば次のようになります。

• 要件IDのすべてに1件以上のテストケースがあり、すべて実施済みである
• 重大度「致命」「高」の未解決欠陥が0件である
• 重大度「中」の未解決欠陥は5件以下で、回避策と修正予定日が記録されている
• 修正した欠陥の再テストと、影響範囲の回帰テストが完了している

数値そのものは案件によって変わります。大事なのは「おおむね問題がないこと」のような判定者の主観に寄った書き方を残さないことです。重大度の定義（致命は業務が止まる、高は回避策がないなど）も、計画書の中で一緒に決めておきます。

時間切れで終える判断｜残存リスクを発注者が受け入れた記録を残す手順

シラバスは、時間切れや予算切れも終了基準として妥当とみなすことがあると書いています。ただし条件付きです。ほかの終了基準を満たしていなくても、ステークホルダーがテストをこれ以上行わずに本稼働させるリスクをレビューし、受け入れた場合に限られます。

実務に置き換えると、リリース日を優先して未解決欠陥を残す判断は、発注者の決裁者が残存欠陥の一覧を見たうえで承認し、その記録を残すということです。計画書に「終了基準を満たさずに終える場合は、残存欠陥一覧を添えて発注者の承認を得る」と1行書いておけば、後から「聞いていない」と揉める事態を防げます。

テスト工数と日程の見積り｜比率と三点見積りで計画書の日程に根拠を示す

スケジュールの章は、根拠のない日付を並べるとすぐに形骸化します。シラバス5.1.4項は見積り技法として、比率に基づく見積り・外挿・ワイドバンドデルファイ・三点見積りの4つを挙げています。

比率に基づく見積り｜開発工数とテスト工数の過去比率から全体量を出す

比率に基づく見積りは、組織内の過去プロジェクトの実績比率を新しい案件に当てはめる方法です。シラバスの例では、前のプロジェクトで開発工数とテスト工数の比率が3対2で、今回の開発工数が600人日と予想される場合、テスト工数を400人日と見積もっています。

この方法が使えるのは、自社に工程別の実績工数が残っている場合だけです。発注者の立場では、見積書のテスト工数が開発工数に比べて極端に小さいときに、どの比率を根拠にしたのかを開発会社に尋ねると、計画の厚みを確かめる材料になります。

三点見積りの計算例｜楽観値・最可能値・悲観値から日程の幅を出す

三点見積りは、専門家が楽観値a・最可能値m・悲観値bの3つを出し、E＝（a＋4m＋b）÷6で見積り値を、SD＝（b−a）÷6で誤差の目安を計算する方法です。シラバスの例では、a＝6・m＝9・b＝18人時のとき、E＝10、SD＝2となり、見積りは10±2人時（8〜12人時）と表せます。

受入テストの日程を引くときに、この幅は役に立ちます。業務担当者の稼働が読みにくい受入テストこそ、1点の日付ではなく幅で計画し、悲観値側に再テストの期間を確保しておくと、検査期間の中で確認を終えられる見込みが立ちます。

リスクの大きさでテストの厚みを変える｜可能性と影響の2軸で優先順位

シラバスはリスクを、顕在化する可能性と、顕在化したときの影響の2つで特徴づけ、この2つがリスクレベルを表すとしています。テスト計画書のリスクの章には、機能ごとにこの2軸を付けて、レベルの高い機能から厚くテストする方針を書きます。

受発注システムなら、金額計算・在庫引当・権限制御は影響が大きく、画面の文言変更は小さい部類です。リスクレベルの高い機能にテスト工数の多くを割き、その配分を計画書で示しておくと、日程が詰まったときに削る順番も合意済みになります。

発注者がテスト計画書で確認する観点｜受入テストと検収につなげる読み方

ここからは発注者の立場の話です。テスト計画書を開発会社の内部資料として承認だけ済ませると、合格の基準を相手に預けたまま検収を迎えることになります。

モデル契約が定める検査仕様書と検査期間｜受入テストの計画は発注者が主導

IPAと経済産業省がまとめた情報システム・モデル取引・契約書（第二版）は、第27条で、発注者（甲）が開発会社（乙）と協議のうえ、テスト項目・テストデータ・テスト方法・テスト期間などを定めた検査仕様書を作成し、乙が点検して承認する流れを定めています。第28条では、甲が検査期間内に書面で具体的な理由を示して異議を述べなければ、検査に合格したものとみなされます。

この条文に照らすと、受入テストの計画が薄いまま検査期間に入るのは発注者にとって不利です。受入テストの範囲・担当者・日程・合否の基準は、システムテストが始まる前に計画書の形で固めておきます。受入テストそのものの進め方は受入テスト（UAT）とは？進め方と合否基準・システムテストとの違いを発注者向けに解説、検収日の扱いは検収とは？検収日の意味と受入検査との違いで解説しています。

発注者のレビュー観点4つ｜終了基準・対象外・発注者の作業・報告頻度

開発会社から受け取ったテスト計画書は、次の4点を優先して読みます。

1. 終了基準が数値で書かれ、重大度の定義が付いているか
2. 対象外の機能と、その理由が明記されているか
3. テストデータの提供や受入テストの実施など、発注者の作業に担当者と期日があるか
4. 進捗と欠陥の報告がどの形式で、週何回届くか

4つのうち最初に見るべきは1です。終了基準が曖昧なまま承認すると、ほかの項目がどれだけ整っていても、テストの終わりを判断する物差しがありません。社内に計画書を評価できる担当者がいない場合は、要件定義の段階から発注者側に立って受入基準づくりを支える体制を用意する方法があります。一創の要件定義・RFP作成・PMO支援は、要件定義書の整備から受入基準とテスト計画のレビューまでを、発注者の側に立って支援するサービスです。開発会社とは別の会社にテストそのものを任せる選択肢は第三者検証とは：開発会社のテストとの役割分担・費用の決まり方・発注のタイミングで比較しています。

テスト計画書を作り込みすぎる失敗｜小規模案件は数ページに絞る判断

反対方向の失敗もあります。テンプレートの全章を埋めることが目的になり、数十ページの計画書を作ったものの、仕様変更のたびに更新されず、実態と合わない文書だけが残るパターンです。

判断ははっきりさせておきます。開発期間が3か月未満、画面数が20程度までの案件なら、テスト計画書はA4で数ページに収め、範囲（対象外を含む）・体制・日程・開始基準と終了基準の4項目に絞ります。リスクレジスターや詳細な見積り根拠まで独立した章にするのは、複数社が関わる案件や、業務停止の影響が大きい基幹系に限って構いません。

テスト計画書の作成者・作成時期・テンプレートについてよくある質問

テスト計画書の作り方と扱いについて、発注者と開発担当の双方から寄せられやすい質問に回答します。

テスト計画書は誰が作成するのですか？

単体・結合・システムテストの計画書は、開発会社のテスト責任者かプロジェクトマネージャーが作成するのが通常です。受入テストの計画は、IPAのモデル契約では検査仕様書を発注者が作成し開発会社が承認する形になっており、作成の支援を開発会社に委託することもできます。実務では開発会社が叩き台を出し、発注者が範囲・担当者・終了基準を確認して承認する流れが多く、承認者を誰にするかは契約時に決めておきます。

テスト計画書はいつ作成すればよいですか？

全体の計画書は、要件定義が固まる時期に作り始めます。テストの範囲と終了基準は要件から決まるため、要件定義書の承認と同じ頃に骨組みができていれば、見積りと日程の根拠にも転用が可能です。工程別の詳細な計画書は、その工程が始まる前までに作成します。受入テストの計画は、発注者の業務担当の稼働を押さえる必要があるので、システムテストの開始前には承認まで済ませておくのが目安です。

テスト計画書のテンプレートはどこで手に入りますか？

国際規格としては、JSTQBシラバスがテスト計画書の詳細の参照先に挙げるISO/IEC/IEEE 29119-3があり、テスト文書のテンプレートを定めています（規格本文は有償です）。無料で目次の骨組みを作るなら、シラバス5.1.1項の典型内容（概要・前提と制約・ステークホルダー・コミュニケーション・リスク・テストアプローチ・予算とスケジュール）をそのまま章立てに使う方法が手軽です。社内の過去案件の計画書があれば、それを土台にする方が書式の説明が要りません。

テスト計画書は途中で変更してもよいですか？

変更して構いません。仕様変更や日程の遅れが起きたのに計画書を据え置くと、終了基準や範囲が実態と合わなくなります。JSTQBシラバスでも、テスト計画書からの逸脱はテスト進捗レポートで報告する事項という位置づけです。変更するときは版番号を上げ、変更箇所・理由・承認者を改訂履歴に残し、範囲や終了基準を緩める変更は発注者の承認を得てから反映します。

アジャイル開発でもテスト計画書は必要ですか？

分厚い計画書を最初に1冊作る形はとりませんが、計画そのものは必要です。JSTQBシラバスは、アジャイル開発では終了基準を「完了（done）の定義」、作業を始めるための開始基準を「準備完了（Ready）の定義」と呼ぶことが多いと説明しています。リリース計画の段階でテスト方針と完了の定義を文書にし、イテレーションごとに更新する運用にすると、請負契約でも検収の基準を示せます。

関連記事

• 総合テスト（システムテスト）とは？結合テストとの境目と観点・発注者が見る成果物：テスト計画書で区切った工程のうち、システムテストの観点と成果物を解説しています。
• テストマトリクスとは？作り方・サンプル表・観点とパターン削減：計画書で決めた範囲を、観点と組み合わせの表に落とす方法です。
• WBSとは？作り方5ステップとシステム開発の例、ガントチャートとの違い：テスト工程の作業分解と日程表を作るときの基本です。
• システム開発の品質管理とは？工程別レビュー・テスト管理とメトリクス判定の手順：終了基準で使うメトリクスの判定方法を含む、品質管理全体の進め方です。