【テンプレあり】英語テスト計画書の書き方｜ITプロジェクトで使える日英フォーマット付き

「グローバルプロジェクトでテスト計画書を英語で書かなければいけない。何を盛り込めばいい？」QAフェーズ前に計画書を準備しようとして、構成に迷う人は多い。

この記事では、ITプロジェクトで実際に使えるテスト計画書（Test Plan）の日英テンプレートをそのまま提供する。テスト範囲・種別・合格基準・役割の書き方と、QAフェーズで使える英語表現もセットで解説する。

この記事を読めば、英語テスト計画書の構成と書き方が身につき、コピーして即日使えるテンプレートが手に入る。

結論から言う。テスト計画書に必要なのは8つのセクションだ。なかでも「合格基準・終了基準（Entry/Exit Criteria）」と「テスト種別・アプローチ（Test Types）」の2つが、リリース判断の根拠と品質保証の実効性を決める最重要パートになる。

英語テスト計画書が日本語と異なる3つのポイント
テスト計画書の8つの必須セクション（日英対訳）
テンプレートをダウンロード（Word）
日本語版テンプレート（コピペOK）
英語版テンプレート（コピペOK）
テスト計画書で使える英語表現15選
テスト計画書を書くときの3つのコツ
まとめ：8つのセクションで英語テスト計画書が完成する

英語テスト計画書が日本語と異なる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)

日本語版テンプレート（コピペ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]

テスト計画書で使える英語表現15選

テスト計画書を書くときや会議で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.（現在のテスト結果に基づき、リリースへの移行を推奨する）

テスト計画書をもとにしたQA議論・バグトリアージのフレーズは、【例文あり】エンジニアの英語テスト・QA議論術｜テスト計画・バグトリアージフレーズ30選も参考にしてほしい。