「グローバルプロジェクトでテスト計画書を英語で書かなければいけない。何を盛り込めばいい？」QAフェーズ前に計画書を準備しようとして、構成に迷う人は多い。
この記事では、ITプロジェクトで実際に使えるテスト計画書（Test Plan）の日英テンプレートをそのまま提供する。テスト範囲・種別・合格基準・役割の書き方と、QAフェーズで使える英語表現もセットで解説する。
この記事を読めば、英語テスト計画書の構成と書き方が身につき、コピーして即日使えるテンプレートが手に入る。
結論から言う。テスト計画書に必要なのは8つのセクションだ。なかでも「合格基準・終了基準（Entry/Exit Criteria）」と「テスト種別・アプローチ（Test Types）」の2つが、リリース判断の根拠と品質保証の実効性を決める最重要パートになる。
英語テスト計画書が日本語と異なる3つのポイント
英語スタイルのテスト計画書は、日本語のテスト仕様書とは求められる内容の構成が異なる。違いを押さえないと、グローバルチームとのQA認識がかみ合わない。
① Entry/Exit Criteriaでリリース判断を明文化する
テストを「いつ始めるか」（Entry Criteria）と「いつ終わるか」（Exit Criteria）を定義することが英語圏では標準だ。「テストが終わった」ではなく「Exit Criteriaを満たしたのでリリース可能」と言える状態にすることで、判断の根拠が明確になる。
② テスト種別ごとに実施者と時期を明確化する
単体・結合・システム・UAT・回帰テストのそれぞれについて、誰がいつ実施するかをテーブルで定義する。種別ごとの責任が曖昧だと、QAフェーズで「それは誰がやるの？」という混乱が起きやすい。
③ バグ優先度の定義をチームで統一する
Critical / High / Medium / Lowの4段階を定義し、何をもってリリース前にクローズ必須とするかを明記する。定義がないと「このバグはリリースブロッカーか？」の議論に時間がとられる。
テスト計画書の8つの必須セクション（日英対訳）
英語テスト計画書を構成する8つのセクションを日英対訳で解説する。
① テスト概要・目的（Test Overview & Objectives）
何のためのテストか・どのフェーズをカバーするかを2〜3文で記載する。スポンサーやビジネスオーナーがここを読んで、テスト活動の全体像を把握できるように書く。
② テスト範囲（Scope）
In Scope（テスト対象）とOut of Scope（テスト対象外）の両方を記載する。Out of Scopeに理由を添えることで「なぜテストしないのか」の説明責任が果たせる。
③ テスト種別・アプローチ（Test Types & Approach）
実施するテストの種別・目的・実施者・時期を表形式で定義する。主要なテスト種別の日英対訳は以下の通りだ。
| 日本語 | English |
| 単体テスト | Unit Test |
| 結合テスト | Integration Test |
| システムテスト | System Test |
| 性能テスト | Performance Test |
| ユーザー受け入れテスト | User Acceptance Test (UAT) |
| 回帰テスト | Regression Test |
④ テスト環境（Test Environment）
Dev / Test / Staging / Productionの各環境の用途・アクセス先・管理者を記載する。環境の役割を明確にしておくことで「どの環境でテストすべきか」の混乱を防げる。
⑤ スケジュール・マイルストーン（Test Schedule & Milestones）
テストケース作成・各テスト開始・UAT・サインオフ・リリースの日程を表形式で記載する。テストスケジュールが見えることで、開発側もバグ修正の期限を意識しやすくなる。
⑥ 役割・責任（Roles & Responsibilities）
テストマネージャー・QAエンジニア・開発チーム・ビジネスオーナーの役割と責任を記載する。UATのサインオフ権限が誰にあるかを明記しておくことが特に重要だ。
⑦ 合格基準・終了基準（Entry / Exit Criteria）
テスト開始条件（Entry）・テスト完了条件（Exit）・バグ優先度の定義を記載する。Exit Criteriaに「Critical/Highバグが全件クローズ済み」と明記することで、リリース可否の判断がスムーズになる。
⑧ リスク・前提条件（Risks & Assumptions）
テスト環境の遅延・バグ修正の長期化などのリスクと、テストデータ準備などの前提条件を記載する。リスク管理表と連動させることで、リスクが顕在化したときの対応が素早くなる。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word（空白版））
📥 Download English Template (Word – Blank)
📥 日本語サンプルをダウンロード（ECサイト ポイント機能追加）
📥 Download Sample in English (Loyalty Points Feature)
日本語版テンプレート（コピペOK）
以下をコピーして、プロジェクトのテスト計画書としてそのまま使える。
# テスト計画書（Test Plan）
**プロジェクト名：** 〇〇プロジェクト
**作成者：** 〇〇（役割：〇〇）
**作成日：** 2026年〇月〇日
---
## テスト概要・目的
〇〇システムのリリース前品質を保証するためのテスト活動を定義する。
〇〇フェーズから〇〇フェーズまでを対象とし、合格基準を満たすことでリリース判断を行う。
---
## テスト範囲
### テスト対象（In Scope）
- 〇〇機能の単体テスト・結合テスト
- 〇〇システムとの連携テスト
- ユーザー受け入れテスト（UAT）
### テスト対象外（Out of Scope）
- 〇〇システムの既存機能（変更なしのため対象外）
- セキュリティペネトレーションテスト（別途実施）
---
## テスト種別・アプローチ
| テスト種別 | 目的 | 実施者 | 時期 |
|-----------|------|--------|------|
| 単体テスト | モジュール動作確認 | 開発チーム | 開発完了後 |
| 結合テスト | システム間連携確認 | 開発チーム | 〇月〇日〜 |
| システムテスト | エンドツーエンド確認 | QAチーム | 〇月〇日〜 |
| UAT | ビジネス要件充足確認 | ビジネスオーナー | 〇月〇日〜 |
| 回帰テスト | 既存機能への影響確認 | QAチーム | リリース前 |
---
## テスト環境
| 環境 | 用途 | 管理者 |
|------|------|--------|
| 開発環境（Dev） | 開発中確認 | 開発チーム |
| テスト環境（QA） | QAテスト実施 | QAチーム |
| ステージング | UAT・最終確認 | インフラチーム |
---
## スケジュール・マイルストーン
| マイルストーン | 予定日 | 担当 |
|-------------|--------|------|
| テスト計画書承認 | 〇月〇日 | PM |
| テストケース作成完了 | 〇月〇日 | QAチーム |
| UAT開始 | 〇月〇日 | ビジネスオーナー |
| UAT完了・サインオフ | 〇月〇日 | ビジネスオーナー |
| 本番リリース | 〇月〇日 | 全チーム |
---
## 合格基準・終了基準
### テスト開始基準（Entry Criteria）
- 前フェーズのテストが完了していること
- テスト環境が利用可能な状態であること
### テスト終了基準（Exit Criteria）
- 計画テストケースの〇〇%以上を実行済みであること
- Critical/Highバグがすべてクローズされていること
- ビジネスオーナーのサインオフが取得されていること
### バグ優先度定義
| 優先度 | 定義 |
|--------|------|
| Critical | システム停止・データ破損など業務継続不可能 |
| High | 主要機能が動作しない。回避策なし。 |
| Medium | 機能は動作するが期待通りでない。回避策あり。 |
| Low | 軽微な表示崩れ・誤字など。業務影響なし。 |
---
作成者：〇〇 ｜ 作成日：〇月〇日英語版テンプレート（コピペOK）
英語テスト計画書はそのままグローバルチームやステークホルダーに共有できる。
# Test Plan
**Project:** [Project Name]
**Author:** [Name] ([Role])
**Date:** [Date]
---
## Test Overview & Objectives
This Test Plan defines the testing activities to ensure the quality of [system]
prior to release. Testing will cover [phase] through [phase], and a release
decision will be made upon achieving the defined exit criteria.
---
## Scope
### In Scope
- Unit and integration testing of [feature/module]
- End-to-end interface testing with [external system]
- User Acceptance Testing (UAT)
### Out of Scope
- Existing features of [system] (no changes; excluded from testing)
- Security penetration testing (conducted separately)
---
## Test Types & Approach
| Test Type | Objective | Responsible | Timing |
|-----------|-----------|-------------|--------|
| Unit Test | Verify individual module behavior | Dev Team | After development |
| Integration Test | Verify inter-system connectivity | Dev Team | From [Date] |
| System Test | End-to-end functional verification | QA Team | From [Date] |
| UAT | Confirm business requirements are met | Business Owner | From [Date] |
| Regression Test | Verify no impact on existing features | QA Team | Before release |
---
## Test Environment
| Environment | Purpose | Owner |
|-------------|---------|-------|
| Development (Dev) | Developer testing during build | Dev Team |
| Test / QA | QA test execution | QA Team |
| Staging | UAT and final verification | Infra Team |
---
## Test Schedule & Milestones
| Milestone | Target Date | Owner |
|-----------|-------------|-------|
| Test Plan approved | [Date] | PM |
| Test cases finalized | [Date] | QA Team |
| UAT begins | [Date] | Business Owner |
| UAT sign-off | [Date] | Business Owner |
| Production release | [Date] | All Teams |
---
## Entry & Exit Criteria
### Entry Criteria
- Testing from the previous phase is complete
- The test environment is available and stable
### Exit Criteria
- [X]% or more of planned test cases have been executed
- All Critical and High-priority defects are closed
- Business Owner sign-off has been obtained
### Defect Priority Definitions
| Priority | Definition |
|----------|------------|
| Critical | System crash or data corruption - operations cannot continue |
| High | Key functionality does not work; no workaround available |
| Medium | Feature works but not as expected; workaround exists |
| Low | Minor UI issue or typo; no business impact |
---
Prepared by: [Name] | Created: [Date] | Last updated: [Date]テスト計画書で使える英語表現20選
テスト計画書を書くときや会議でQA状況を報告するときに使える表現を場面別にまとめた。
テスト範囲・戦略を説明するとき
① The scope of this test plan covers ～（このテスト計画書のスコープは〜をカバーする）
② [X] is explicitly out of scope due to ～（〜のため〇〇は明示的にテスト対象外だ）
③ Our testing approach includes [X] types of testing.（今回のテストアプローチは〇〇種類のテストを含む）
④ UAT will be conducted by the Business Owner in the staging environment.（UATはビジネスオーナーがステージング環境で実施する）
⑤ Regression testing will be performed to ensure no existing features are impacted.（既存機能への影響がないことを確認するため回帰テストを実施する）
合格基準・品質を伝えるとき
⑥ Testing will begin once the entry criteria have been met.（テスト開始基準が満たされ次第、テストを開始する）
⑦ The exit criteria require that all Critical and High defects are closed.（終了基準はCritical/Highのバグが全件クローズされていることを求めている）
⑧ This defect is classified as High priority as it blocks the core workflow.（このバグはコアワークフローをブロックするためHigh優先度に分類される）
⑨ We have executed [X]% of the planned test cases as of today.（本日時点で計画テストケースの〇〇%を実行済みだ）
⑩ UAT sign-off has been obtained from the Business Owner.（ビジネスオーナーのUATサインオフを取得した）
リスク・課題を報告するとき
⑪ The test environment setup is delayed, which may shorten the testing window.（テスト環境の整備が遅延しており、テスト期間が短縮される可能性がある）
⑫ There are [X] open High-priority defects that must be resolved before release.（リリース前にクローズしなければならないHigh優先度のバグが〇件残っている）
⑬ We are requesting a [X]-day extension to the UAT period due to ～（〜のためUAT期間の〇日延長を依頼したい）
⑭ The defect fix has been verified in the staging environment.（バグ修正をステージング環境で確認した）
⑮ Based on current test results, we recommend proceeding with the release.（現在のテスト結果に基づき、リリースへの移行を推奨する）
変更管理・リリース承認を進めるとき
⑯ A formal change request has been submitted to the Change Advisory Board for approval.（変更管理委員会に正式な変更申請書を提出し、承認を依頼した）
⑰ The rollback plan has been reviewed and confirmed as part of the release approval process.（リリース承認プロセスの一環として、ロールバック計画をレビュー・確認した）
⑱ All test evidence has been documented and is available for post-release audit.（すべてのテストエビデンスが文書化され、リリース後の監査に対応できる状態だ）
⑲ The capacity of the production environment has been verified to support the expected load.（本番環境のキャパシティが想定負荷を処理できることを確認した）
⑳ We will monitor system performance for 24 hours post-release and report any anomalies immediately.（リリース後24時間はシステムのパフォーマンスを監視し、異常があれば即座に報告する）
テスト計画書をもとにしたQA議論・バグトリアージのフレーズは、【例文あり】エンジニアの英語テスト・QA議論術｜テスト計画・バグトリアージフレーズ30選も参考にしてほしい。
テスト計画書を書くときの3つのコツ
① Exit Criteriaは数値で定義する
「テストが十分に完了したら」では判断できない。「計画テストケースの95%以上を実行済み」「Critical/Highバグが全件クローズ」のように数値と条件を明記することで、リリース判断の場で迷いがなくなる。
② UATのサインオフ権限者を明記する
「ビジネスオーナーが承認する」だけでなく、具体的な担当者名と署名の取得方法（メール承認／書面など）を計画書に書いておく。権限者が不在の場合の代理者も定めておくと、クロージングが滞らない。
③ テスト計画書はキックオフ前に承認を取る
テスト開始後に「こんなテスト計画は聞いていない」となるのが最悪のパターンだ。キックオフ会議でテスト計画書の承認を議題に入れ、全ステークホルダーが合意した状態でテストフェーズに入ることが重要だ。
UATフェーズでのバグ報告・サインオフのフレーズは、【例文あり】エンジニアの英語UAT術｜テスト計画・バグ報告・サインオフフレーズ30選も合わせて活用してほしい。
テスト計画書と合わせて使えるUATテストケース管理表は、【テンプレあり】英語UATテストケース管理表の書き方｜ITプロジェクトで使える日英Excelフォーマット付きも参考にしてほしい。
テストフェーズ完了後に作成するテスト結果報告書のテンプレートは、【テンプレあり】英語テスト結果報告書の書き方｜ITプロジェクトで使える日英フォーマット付きも参考にしてほしい。
受入基準の定義方法は、【テンプレあり】英語受入仕様書の書き方｜ITプロジェクトで使える日英フォーマット付きも参考にしてほしい。
テスト後のシステム変更・本番適用の変更管理書の書き方は、【テンプレあり】英語変更管理書の書き方｜ITプロジェクトで使える日英フォーマット付きも参考にしてほしい。
テスト中に発生したインシデントの報告書作成は、【テンプレあり】英語インシデント報告書の書き方｜ITプロジェクトで使える日英フォーマット付きも参考にしてほしい。
リリース後のシステム負荷設計については、【テンプレあり】英語キャパシティ計画書の書き方｜ITプロジェクトで使える日英フォーマット付きも参考にしてほしい。
研修と合わせて使うトレーニング計画書のテンプレートは、【テンプレあり】英語トレーニング計画書の書き方｜ITプロジェクトで使える日英フォーマット付きも参考にしてほしい。
品質管理計画書のテンプレートは、英語品質管理計画書の書き方でも紹介しているので合わせて確認してほしい。
データ移行後の検証計画をドキュメント化する方法は、英語データ移行計画書の書き方でも紹介しているので合わせて確認してほしい。
バグ検出のためのテスト計画を英語で書く方法は、英語バグレポートの書き方でも紹介しているので参考にしてほしい。
テスト戦略書でプロジェクト全体の品質方針を定め、テスト計画書でスケジュール・担当者・テストケースに落とし込むことで、品質保証の全体像が完成する。英語テスト戦略書の書き方と合わせて整備してほしい。
まとめ：8つのセクションで英語テスト計画書が完成する
英語テスト計画書の構成と書き方をまとめる。
- 8つの必須セクション：概要目的・テスト範囲・テスト種別・テスト環境・スケジュール・役割責任・合格基準・リスク前提条件
- 英語スタイルの3つの特徴：Entry/Exit Criteriaの明文化・テスト種別ごとの責任定義・バグ優先度のチーム統一
- 20の英語表現：テスト範囲/戦略・合格基準/品質・リスク/課題・変更管理/リリース承認の場面ごとに使い分ける
- 3つのコツ：Exit Criteriaを数値定義・サインオフ権限者を明記・キックオフ前に承認取得
テンプレートは上記をコピーしてすぐ使える。プロジェクトの規模やテスト対象に合わせてテスト種別の行をカスタマイズしてほしい。
コメント