テスト計画書とは？記載すべき項目や書き方、よくある失敗と対策まで解説

テストを実施していたにもかかわらず、想定外の不具合が発覚し、リリース延期や緊急対応に追われる。多くの開発現場が経験するこうしたトラブルの背景には、計画段階で「何をどこまでテストするか」が曖昧になっているという問題があります。

このような問題を防ぐために重要な役割を果たすのが「テスト計画書」です。テストの目的や範囲、スケジュール、実施環境などについて計画段階で明文化し、共有することで、関係者間での認識をそろえ、抜け漏れのないテスト設計を実現できます。

本記事では、テスト計画書の定義や役割、記載すべき項目、書き方まで解説します。

第三者検証の重要性｜資料ダウンロード

テスト計画書とは

テスト計画書は、テスト工程全体の指針を示すドキュメントです。まずはその定義と役割を整理し、似ている文書との違いを明確にしておきましょう。

テスト計画書の定義と役割

テスト計画書とは、テストの目的や範囲、体制、スケジュールなどを整理したドキュメントです。「なぜテストするのか」「何をテストするのか」「どのようにテストするのか」「いつまでにテストするのか」「どの程度の品質を目指すのか」を明文化することで、プロジェクト全体の見通しを立て、チーム内で認識を統一できます。また、開発チームやクライアントに対してテスト工程の全体像を説明する資料としても活用できます。

一般的には、要件定義や基本設計フェーズで、QAリーダーやプロジェクトマネージャー、テストマネージャーが中心となって作成します。

テスト設計書やテスト仕様書との違い

テスト計画書と混同されやすいドキュメントとして、「テスト設計書」や「テスト仕様書」があります。それぞれの役割は以下の通りです。

テスト計画書
テスト全体の目的・範囲・体制・スケジュールを定める文書。「テスト工程全体をどのように進めるか」の方針を示す

テスト設計書
テストすべき観点や条件を設計する文書。同値分割、境界値分析、デシジョンテーブルなど、「どのような技法でテストするか」を整理する

テスト仕様書
テストケースを具体的に記述する文書。入力値・操作手順・期待結果などを明記し、実際のテストで使用する

設計書や仕様書が「テストの中身」を細かく記述するのに対し、計画書は「テスト全体の方向性」を表し、限られたリソースのなかで効果的にテストを進めるための指針として機能します。

テスト計画書に記載する項目

テスト計画書に必ず含めるべき要素として、以下の4つがあります。これらの要素を具体的に記述することで、後工程を効率的に進めながらソフトウェアの品質を確保できます。

目的・対象範囲
テストの目的や背景を明確化し、関係者全員が同じゴールを意識して作業を進められるようにする。テスト対象の機能や範囲だけでなく、対象外事項も併せて記載することで、誤解や漏れも防止する

体制・役割分担・スケジュール
誰がどの役割を担うのかを明確にし、責任範囲を明確化する。また、各工程のスケジュールと成果物を具体的に示すことで、進捗を正しく管理できるようにする

環境・利用ツール
テスト対象となるソフトウェアや機能、使用するテスト環境・端末を整理する。使用予定のテスト支援ツール（バグ管理、CI/CDなど）も併せて記載し、チーム全体で環境を統一できるように

評価基準・完了条件
合格・不合格の基準や品質目標を明示する。例えば「バグ件数」「テストケースの消化率」「カバレッジ率」など、定量的な指標を設定することで、曖昧さを排除し、客観的な完了判断が可能に

テスト計画書の書き方と作成例

テスト計画書は、目的や範囲を整理したうえで、体制・環境・評価基準を明確にしていく流れで作成します。ここでは、初めて作成する人でもイメージしやすいように、5つのステップに分けて解説します。

1. 要件を確認し、テストの目的と範囲を定める

まずは、要件定義書や基本設計書などをもとに、テストの目的を整理します。ここでは、読み手によって解釈が変わらないように、「どこまで確認するか」「何をゴールとするか」を明確にするのがポイントとなります。

例のように対象外の項目も併せて記載しておくことで、後から生じる認識のずれを回避できます。

2. 体制・スケジュールを設計し、役割と時期を明確にする

次に、役割分担とスケジュールを書いていきます。各人の業務範囲を明確に定める思考法の1つとして、ここでは「RACIマトリクス」を紹介します。

RACIマトリクスでは、タスクごとに以下の4つの役割を設定します。

• Responsible（実行責任者）：実際に作業を行う担当者
• Accountable（説明責任者）：最終的な責任を負い、承認権限を持つ担当者
• Consulted（相談先）：作業前に意見を求める担当者
• Informed（報告先）：作業結果の報告を受ける担当者

以下の表は、RACIマトリクスに基づいた役割分担の記載例です。

3. テスト環境と利用ツールを整理する

「どの環境でテストするか」を曖昧にしたままテストを行うと、実際の利用シーンとの食い違いが発生しやすくなります。環境を統一したうえでテストを実施するため、テスト計画書には、使用端末・OS・ブラウザの組み合わせを一覧で記入します。

また、テスト管理ツールやバグトラッキングツールも明記し、チーム全体で共通のツールを使用できるようにします。

4. 評価基準と完了条件を設定する

バグ件数、重要度、テストケースの消化率など定量的に示します。「この基準を満たせば次工程に進める」という条件まで書くことで、実施フェーズでの意思決定に活用できるようにします。

項目	基準
テストケース実行率	95%以上
致命的バグ	0件
重要バグ	2件以下
軽微なバグ	制限なし（修正は次版で対応可）
完了条件	上記基準をすべて満たし、テストマネージャーが承認

5. 完成した計画書のレビューを行い、継続的に改善する

作成後は、別の担当者やステークホルダーによるレビューを行い、抜け漏れを補正します。目的・範囲・体制が一貫しているか、用語の認識にズレがないかを重点的にチェックしましょう。レビューで発見された課題は計画書に反映し、最終版として関係者に共有します。

テスト計画書にありがちな失敗と対策

テスト計画書は、品質保証プロセスを滞りなく進めるために欠かせないドキュメントですが、一方で、不備のある計画書はかえってプロジェクトの混乱を招くこともあります。

ここでは、特に起こりやすい3つの失敗パターンと、それぞれの対策について解説します。

範囲が曖昧で抜け漏れが発生

テスト対象を明確にしないまま進めると、一部の仕様が未検証のまま残ってしまいます。その結果、リリース後に重大な不具合が発覚し、手戻りやコスト増大につながるおそれがあります。

このような問題を回避するためには、機能一覧や画面設計書と照らし合わせて網羅性を確保し、さらに「対象外事項」を計画書に明記することが有効です。「ここはテストしない」という認識を共有することで、誤解や漏れを防げます。

役割分担が不明瞭で作業の重複や漏れが発生

誰がどのタスクを担当するかが明文化されていないと、作業の重複や抜けが発生しやすくなります。特定のメンバーに負担が集中し、不満や進捗遅延の原因になることも少なくありません。

こうした問題を回避するためには、役割分担表やRACIマトリクスを活用し、各メンバーの責任範囲を明確にすることが効果的です。役割をドキュメントで残しておくことで、報告や連絡の流れを整理でき、効率的な進行につながります。

目的と評価基準がずれていて、完了判断がつかない

「何をもって合格とするか」が不明確なままテストを進めると、関係者間で認識がずれ、テスト工程が長期化したり、完了判断を巡って議論が発生したりします。

このような問題を防ぐには、バグ件数、テストケース消化率、カバレッジ率などの定量的な基準をあらかじめ定めておくことが不可欠です。テストの目的に応じて測定可能な指標を設定し、明確な合格ラインを引くことで、客観的かつスムーズな完了判断が可能になります。

テスト計画書の完成度が、プロダクトの品質を左右する

テスト計画書は、テスト工程全体の基盤となるドキュメントです。計画段階でテストの範囲や役割分担、実施環境まで明確に示すことで、関係者間の認識を統一し、抜け漏れのない品質保証活動を実現できます。

社内でのテスト計画書の作成に不安がある場合には、外部のテスト専門会社を活用することも有効です。自社だけでは気づけない記載の抜け漏れや計画の問題点は、専門知識を持った外部機関のレビューで可視化されやすくなります。

AGESTでは、テスト計画書の作成からレビューまで一貫したサポートを提供しています。豊富な実績を持つテスト専門のエンジニアが、お客様のリソース状況やプロダクトの性質に応じて、実現可能なテスト計画の策定を支援します。

品質向上とプロジェクト効率化の両立を目指す方は、ぜひ一度ご相談ください。

ソフトウェアテスト サービス詳細ページ

TFACT (AIテストツール)

関連コンテンツ