【無料】テスト計画書のサンプル・テンプレート｜手順を標準化する書き方・運用方法

 
システム開発において、品質を確保するために欠かせないのがテスト計画書です。

しかし、「担当者が替わるたびにテストの進め方がばらつく」「新しいメンバーへの手順の引き継ぎをOJTや口頭説明に頼っている」という問題は珍しくありません。テスト計画書を「プロジェクト管理の資料」としてではなく、「誰が担当しても同じ手順でテストを再現できる業務マニュアル」として作成・運用することで、こうした課題を解決できます。

本記事では、テスト計画書のサンプルテンプレートと記入例を紹介し、業務手順書として機能させるための各項目の書き方・運用・改訂管理のポイントまで解説します。テスト担当者の教育コストを下げ、担当者が替わっても作業品質がばらつかない状態をつくりたい教育担当・テストリーダー・プロジェクト管理者の方は参考にしてください。

 

 

テスト計画書とは：手順を文書化してテスト品質を均一化する業務マニュアル

テスト計画書とは、テストの目的・手順・役割分担・判断基準を文書化し、担当者が替わっても同じ品質でテストを再現できるようにするための業務マニュアルです。テストの目的や実施スケジュール、リソース、リスク管理などを網羅的に記載する点はプロジェクト管理の資料としての側面ですが本質的な価値は、誰が読んでも同じ手順でテストを開始・実施・完了できる作業標準書として機能することです。

テスト計画書は全体テスト計画書と個別テスト計画書の2種類で構成されます。全体は方針・体制・改訂管理のルールを定め、個別は単体・結合・システム・受入の各フェーズで誰がどの手順を担うかを具体化します。どちらも担当者が替わっても同じ手順でテストを再現できる業務マニュアルとして機能させることが目的です。

なお、個々のテストケースや具体的な手順を記載するテスト仕様書とは別の文書ですが、本記事ではテスト計画書に絞って解説します。

 

 

テスト計画書を作成する目的：OJT依存を脱し、手順のばらつきをなくす

テスト計画書を作成する目的は、テスト手順を文書化して作業標準書として機能させることにあります。担当者ごとの手順のばらつきを防ぎ、新しいメンバーが着任したときにOJTや口頭説明に頼らず、この文書を読むだけでテストを開始できる状態をつくることが本質的なゴールです。

具体的には、テスト計画書を作成・運用することで以下の効果が得られます。

担当者が替わっても同じ品質でテストを再現できる

開始基準・終了基準・役割分担・承認フローを文書として定めておくことで、担当者の交代やフェーズ移行があっても手順がぶれない作業標準書として機能します。

新メンバーの立ち上がりを短縮できる

テスト手順・判断基準・環境情報が一か所に集約されているため、新しいメンバーが着任した初日から参照して作業を開始できます。

教育コストを削減できる

テストリーダーが毎回口頭で説明する手間が省け、手順書の更新によって最新の情報をチーム全体に一斉に展開できます。

チーム全体の手順ばらつきを防ぐ作業標準書として機能する

「チーム全体で共通認識を持つ」という従来の目的は、担当者ごとの手順のばらつきを防ぐ作業標準書として機能するという観点で達成されます。担当者が替わっても、文書に沿って一定の品質でテストを進められます。

テスト計画書のサンプルと例文

テスト計画書のサンプルは、記入して終わりにせず業務マニュアルとして運用することを前提に使用してください。担当者が替わるたびにテスト手順が口頭で引き継がれ、フェーズごとに進め方がばらつくという問題は、この文書の必要項目を記入し、チームで共有する場所に保管することで防げます。

プロジェクトマネージャーや教育担当者が新メンバーにテスト作業を割り当てる際も、この計画書を参照するだけで作業の開始・終了基準・役割分担・承認フローが把握できる状態にしておくことを目指します。

テスト環境の変更や担当者の交代が生じた際は、改訂履歴（版番号・変更内容・変更者・変更日）を残して更新し、チーム全体が常に最新の手順書を参照できるよう管理してください。

OJTや口頭説明に頼らずこの文書だけで同じ品質のテストを再現できる状態をつくることが、教育コストの削減と作業ミスの防止につながります。

なお、ここで紹介するサンプルは基本形のため、自社プロジェクトの手順・役割・判断基準に合わせてカスタマイズして使用してください。

テスト計画書のサンプル

＞サンプルをNotePMで使ってみる（無料）

テスト計画書の例文

以下の記入例は、実際の業務でテスト計画書を業務手順書として機能させるために、各項目に何をどう書くかを示したサンプルです。

特に「人員配置と教育計画」「組織体制と進行計画」「テスト進行基準」の各項目は、担当者が入れ替わったときに新しいメンバーがOJTに頼らずテスト作業を開始できるかどうかを左右します。

記入例を参考に、自社のプロジェクトに合わせた手順・役割・判断基準を具体的に書き込み、「担当者名」ではなく「テストリーダー」「担当者A」のように役割名で記載しておくと、引き継ぎ時にそのまま使える作業標準書になります。

作成後は社内の共有スペースに保管し、仕様変更・担当者交代・テスト環境の更新があるたびに改訂履歴を残して更新することで、チーム全体の品質均一化と新人の立ち上がり短縮を実現できます。

 

テスト計画書の各項目の書き方：業務手順書として機能させるための記載ポイント

テスト計画書の各項目を適切に記入することで、担当者が入れ替わったときも口頭の引き継ぎに頼らずテスト作業を再現できる業務手順書として機能します。

以下では14項目それぞれの書き方のポイントを解説します。

特に「人員配置と教育計画」「承認フロー」「モニタリングと管理」の3項目は、手順の標準化と改訂管理の観点で重要度が高いため、詳しく説明します。

プロジェクト情報

プロジェクト情報は、テスト計画書の冒頭に記載します。テストが実施されるプロジェクトの基本的な概要を書きましょう。たとえば、以下の内容を記載すると情報がまとまります。

• 対象となるシステムやソフトウェアの名称
• プロジェクトの概要
• バージョン
• 作成日や作成者
• プロジェクトの規模や目的

テスト計画書のバージョン管理や更新履歴も記載し、関係者がどのバージョンを参照しているかを明確にすることも重要です。

テストの目的

テストの目的では、テストを実施する理由や期待される結果を記載します。たとえば、以下の内容を書いておくとわかりやすいです。

• バグの検出
• 新機能の動作確認
• 既存のソフトウェアに対する影響の確認

テストによって得られるべき成果を設定することで、テストチームが具体的なゴールに向けて作業を進められるようになります。

テストレベルの定義

テストレベルの定義は、テストがどの段階でどの範囲で行われるかを決定する項目です。一般的には、単体テスト、結合テスト、システムテスト、受入テストと段階があり、以下のように表を用いて記載されることが多いです。

テスト要求事項	テストレベル
	単体テスト	結合テスト	システムテスト	受け入れテスト
利用環境	…	…	…	…
テスト対象	…	…	…	…
テストタイプ	…	…	…	…
テスト手法	…	…	…	…
テストデータセット	…	…	…	…
テスト実施方法	…	…	…	…

それぞれのテストレベルにおいて、テストの対象や範囲などを明確にします。

テストの範囲

テストの範囲では、テストの対象となるシステムや機能などを記載します。システムのどの部分をテストするのか、どの機能が重要か、どの機能をテスト対象外にするのか、具体的に定義することが重要です。

具体性が高ければ関係者間でテスト対象についての誤解がなくなり、効率的にテストを進められるでしょう。

テストの方向性と戦略

テストの方向性と戦略では、テストをどのように進めるかの全体的なアプローチを定義します。たとえば、手動テストと自動テストのどちらを重視するのか、特定のツールを使用するのかなど、具体的に記載しましょう。

テスト実行環境

テスト実行環境では、テストを実施する環境を具体的に定義します。記載する項目は主に以下の通りです。

• 使用するハードウェアやソフトウェア
• OSのバージョン
• ネットワーク環境
• 必要なデータベースの設定

実際の運用環境に近い条件を記載しておくことで、より信頼性の高い結果を得られます。複数の環境でテストを実施する場合、それぞれの環境についても記載しておきましょう。

テスト進行基準

テスト進行基準では、テストがいつ開始されるべきか、どのような条件で中断・再開するのか、いつ終了と見なすのか、以下のように具体的に定義します。

• 全機能の80％が合格すれば終了
• 重大なバグが発見された場合は中断し、修正後再開

テストの開始、中断、再開、終了条件を明確にすることで、テストの進行が計画的に管理され、予期せぬトラブルにも迅速に対応できるようになります。

テストの作業項目

テストの作業項目では、テストプロセスを遂行するために必要な具体的な作業をリストアップします。たとえば、以下のような項目を記載しておくとわかりやすいです。

• テストケースの作成
• テストデータの準備
• テストの実施
• 結果の記録
• レポート作成

それぞれの作業に対して担当者や締め切りを決めておくことで、作業が円滑に進行するでしょう。

モニタリングと管理

この項目には、誰がどの手順の進捗を管理するかを明示します。

「テストリーダーが週次会議で進捗を確認し、担当者Aが結果を所定のシートに記録する」というように役割と頻度を具体的に書いておくことで、担当者が替わっても管理作業が止まらない仕組みになります。

特定のツール名に依存した書き方は避け、「進捗管理：週次報告／レポート提出：毎週月曜日」のように手順として読めるかたちで記載してください。

テストの成果物

テストの成果物には、テスト実施後に作成される各種報告書や記録が含まれます。代表例は以下の通りです。

• テストレポート
• バグレポート
• テストカバレッジレポート

これらの成果物は、テスト結果を文書として保存し、関係者に進捗や結果を共有するための重要な資料です。

リスク管理と対応策

リスク管理と対応策では、テスト中に発生する可能性のあるリスクを洗い出し、それに対する予防策や対応策を事前に計画します。たとえば、システムダウンやテスト環境の不具合などに対する対処法を事前に決めておくことで、問題発生時にスムーズに対応できます。

人員配置と教育計画

このサンプルの「人員配置と教育計画」欄は、新しいメンバーが着任したときにOJTに頼らずテスト作業を開始できるかどうかを左右する項目です。「テストリーダー：進捗管理・報告書作成」「担当者A：単体テスト実施・結果記録」のように、担当者名ではなく役割名と担当範囲を具体的に書いておくと、人が替わってもそのまま引き継ぎ資料として使えます。

また、新しいツールや手順の習得が必要な場合は、トレーニングの実施時期・対象者・習得目標を併記しておくことで、教育コストの見積もりと実施管理を文書上で進めやすくなります。

組織体制と進行計画

組織体制と進行計画では、テストチームの体制とテストスケジュールを明確にします。各フェーズにおける担当者やリソースの配分、進行中のチェックポイントなどを設定し、プロジェクト全体のテストが効率的に進むよう基盤を整えておきましょう。予期せぬ遅延やリソース不足に対するバックアップ計画も含めることが重要です。

承認フロー

承認フローは、テスト計画書を改訂するたびに誰がどの版を確認・承認したかを記録に残す仕組みです。

「レビュー者：テストリーダー／承認者：プロジェクトマネージャー」という形で役割を固定しておくと、担当者が交代しても承認ルートが変わらず、手順書としての信頼性が保たれます。

計画段階・テスト完了後・修正後のそれぞれで承認者を明示しておくことで、どの版がどの時点で承認されたかが記録に残り、後から過去の版を確認できる改訂管理の基盤になります。

テスト計画書を手順書として定着させる：作成後の運用・改訂管理のポイント

テスト計画書は、作成した時点で完成するドキュメントではありません。フェーズの移行・担当者の交代・仕様変更・テスト環境の更新が生じるたびに内容を見直し、改訂を重ねることで初めて「誰が担当しても同じ手順でテストを再現できる業務手順書」として機能します。

改訂が必要なタイミングと履歴の残し方

以下のいずれかが発生した場合は、テスト計画書の該当箇所を更新してください。

• テストフェーズの移行（単体→結合→システム→受入）
• テスト担当者・テストリーダーの交代
• 対象システムの仕様変更・追加
• テスト環境（OS・ブラウザ・ハードウェア）の変更

改訂の際は、必ず改訂履歴として以下の情報を文書内に記録してください。

• 版番号（例：v1.0→v1.1→v2.0）
• 変更内容（例：「担当者Aを担当者Bに変更」「テスト環境をChrome 116.0→120.0に更新」）
• 変更者（役割名で記載。例：テストリーダー）
• 変更日

版番号の運用目安として、軽微な修正（担当者・役割分担の変更、日付の更新）はマイナーバージョン（v1.0→v1.1）、テスト範囲や戦略の変更はメジャーバージョン（v1.0→v2.0）で管理すると、後から変更の重大度を判断しやすくなります。

担当者交代時に文書だけで作業を再現できるようにするコツ

引き継ぎを受けた新しい担当者がテスト計画書を読んで作業を開始できる状態にするために、以下の点を意識して記載してください。

• 「担当者名」ではなく「テストリーダー」「担当者A」のように役割名で記載する（人が替わってもそのまま使える）
• 開始基準・終了基準・判断基準を具体的に書く（「優先度高のバグが0件であること」など、口頭確認なしで判断できるレベルで記載する）
• 例外処理や中断条件を明記する（「重大なバグが発見された場合は進捗をテストリーダーに報告し、修正完了を確認してから再開する」など）

保管場所と検索性の確保

テスト計画書は、チームメンバー全員がいつでも最新版にたどり着ける場所に保管してください。

個人のPC・ローカルフォルダ・チャットに添付したままにすると、担当者が替わったときに「最新版がどこにあるか分からない」という状態が再発します。

チーム共有のドキュメント管理スペースに格納し、ファイル名に版番号と更新日を含めておくと（例：テスト計画書_v1.2_20241015.docx）、新しいメンバーでも検索だけで最新版を参照できます。

テスト計画書を効率的に作成するならツールの使用がおすすめ

 

テスト計画書は複数の資料で構成されるため、資料ごとにゼロから作成するとなると時間も労力も必要です。そのため、複数のサンプルやテンプレートを事前に準備しておくことをおすすめします。テスト計画書を効率的に作成する方法として、ドキュメント管理ツールを導入するのもひとつの方法です。

たとえば『NotePM』なら、ドキュメントの作成・共有・管理をすべてひとつのツールで行えます。作成者も使用者も使い勝手がよく、プロジェクト全体のドキュメント作成工程を大幅に効率化できるでしょう。

NotePMの特徴

• マニュアルを含むドキュメントの作成が簡単
• PDFやExcelの中身も全文検索できる強力な検索機能
• 社内FAQ・質問箱、社内ポータルとしても活用可能
• 銀行や大学も導入している高度なセキュリティが魅力

 

＞関連記事：NotePMの評判まとめ｜メリット・デメリットや料金など網羅的に解説

サンプルを活用してテスト計画書を簡単に作成しよう

テスト計画書の作成は、ゼロから取り組むと時間と労力がかかり非効率です。サンプルを活用することで、効率よくテスト計画書を作成できるようになります。サンプルを持っていない方は、本記事で紹介したサンプルと例文を参考にしてみてください。

テスト計画書は複数の書類で構成されるため、サンプルの準備や管理が難しいと感じるかもしれません。サンプルを用いたドキュメント作成を効率化したい方には、マニュアル作成・ナレッジ管理ツール『NotePM』がおすすめです。ドキュメントの作成が簡単なうえに、サンプルの保管も可能なため、テスト計画書を効率的に作成する際に役立ちます。

NotePMでは、30日間無料でお試しできる期間を設けています。テスト計画書を含むドキュメントの作成・管理を効率化したい方は、選択肢のひとつとしてツールの導入を検討してみてください。