テスト計画とは
テスト計画は、テスト活動の戦略、目的、リソース、スケジュール、範囲を概説する詳細なドキュメントです。QA フェーズ全体の青写真であり、誰が何を、どのように、いつテストするのか、「完了」がどのようなものかという問いに答えます。
テスト計画を、QA チーム、開発者、ステークホルダー間の契約と捉えてください。期待値を設定し、責任を定義し、テスト実行のロードマップを提供します。小さなウェブサイトでも大規模なエンタープライズアプリケーションでも、優れたテスト計画は全員の足並みを揃えます。
この記事では、実際の事例を交えた、コピー＆ペーストですぐ使える無料のテスト計画テンプレートを提供します。数分で独自のテスト計画を作成できます。
テスト計画テンプレート（コピー＆ペースト対応）
以下は包括的なテスト計画テンプレートです。ドキュメント、スプレッドシート、またはプロジェクト管理ツールにコピーし、プロジェクトに合わせてカスタマイズしてください。
Test Plan
=========
### 1. Introduction（はじめに）
1.1 Purpose（目的）
[このテスト計画が存在する理由の簡単な説明]
1.2 Scope（範囲）
[テスト対象 — 機能、モジュール、システムを含む]
1.3 Out of Scope（範囲外）
[テスト対象外 — 明確に明記する]
1.4 References（参照）
[要件ドキュメント、設計仕様、ユーザーストーリーへのリンク]
### 2. Test Objectives（テスト目的）
[テストで達成したいこと。例:]
- すべての重要なビジネスワークフローが正しく機能することを検証
- クロスブラウザ互換性（Chrome、Firefox、Safari、Edge）を確保
- すべての CRUD 操作にわたるデータ整合性を検証
- サインオフ前に95%以上の問題ケース合格率を達成
### 3. Test Strategy（テスト戦略）
3.1 Testing Levels（テストレベル）
[ ] Unit Testing（単体テスト）
[ ] Integration Testing（SIT、統合テスト）
[ ] System Testing（システムテスト）
[ ] User Acceptance Testing（UAT、ユーザー受け入れテスト）
3.2 Testing Types（テストタイプ）
[ ] Functional Testing（機能テスト）
[ ] Regression Testing（リグレッションテスト）
[ ] Performance Testing（パフォーマンステスト）
[ ] Security Testing（セキュリティテスト）
[ ] Usability Testing（ユーザビリティテスト）
[ ] Accessibility Testing（アクセシビリティテスト）
3.3 Test Environment（テスト環境）
- Staging URL: [https://staging.example.com]
- Database: [PostgreSQL 15, staging replica]
- Browser targets: [Chrome 125+, Firefox 125+, Safari 17+, Edge 125+]
- Mobile targets: [iOS 17+, Android 14+]
- Test tools: [BugCapturer, Lighthouse, axe DevTools]
### 4. Test Deliverables（テスト成果物）
[ ] Test Plan Document (this document)
[ ] Test Case Specifications（テストケース仕様）
[ ] Test Data（ダミーアカウント、サンプルコンテンツ）
[ ] Bug Reports（実行中に記録されたバグレポート）
[ ] Test Execution Report（合格・不合格のサマリー）
[ ] UAT Sign-Off Document（UAT サインオフドキュメント）
### 5. Test Schedule（テストスケジュール）
| Phase | Start Date | End Date | Duration |
|-------|------------|----------|----------|
| Test Planning | [日付] | [日付] | [X日] |
| Test Case Preparation | [日付] | [日付] | [X日] |
| Test Execution (Round 1) | [日付] | [日付] | [X日] |
| Bug Fixing | [日付] | [日付] | [X日] |
| Test Execution (Round 2) | [日付] | [日付] | [X日] |
| UAT | [日付] | [日付] | [X日] |
| Sign-Off | [日付] | [日付] | [X日] |
### 6. Roles & Responsibilities（役割と責任）
| Role | Name | Responsibilities |
|------|------|-----------------|
| Test Manager | [名前] | 計画、調整、報告 |
| QA Engineer | [名前] | テストケース作成、テスト実行、バグ記録 |
| Developer | [名前] | バグ修正、トラブルシューティングの支援 |
| Product Owner | [名前] | 受け入れ基準の定義、UAT サインオフ |
| UAT Participants | [名前] | UAT シナリオの実行 |
### 7. Test Case Summary（テストケース概要）
| Module | Total Test Cases | Automation % | Priority |
|--------|-----------------|--------------|----------|
| User Registration | [XX] | [X%] | High |
| Login / Auth | [XX] | [X%] | High |
| Checkout | [XX] | [X%] | Critical |
| Search | [XX] | [X%] | Medium |
| Admin Panel | [XX] | [X%] | Low |
### 8. Bug Tracking Process（バグ追跡プロセス）
1. テスターがバグを発見する
2. テスターが以下を含むバグレポートを記録する:
- スクリーンショットまたは画面録画（注釈付き）
- 再現手順
- 環境の詳細（URL、ブラウザ、OS）
- 期待結果と実際の結果の比較
3. テストマネージャーがトリアージして優先順位を割り当てる
4. 開発者がバグを修正する
5. テスターが修正を検証する
6. バグがクローズされる
推奨ツール: 自動取得されたメタデータと注釈付きスクリーンショットを
備えたワンクリックバグレポート用の BugCapturer。
### 9. Entry & Exit Criteria（エントリ・イグジット基準）
9.1 Entry Criteria（テスト開始前に真でなければならないもの）
[ ] すべての重要な機能が開発されている
[ ] ステージング環境が安定している
[ ] テストデータが準備されている
[ ] テストケースがレビューされ承認されている
9.2 Exit Criteria（テスト終了前に真でなければならないもの）
[ ] すべての重大かつ優先度の高いバグが修正されている
[ ] テストケースの95%が合格
[ ] UAT がステークホルダーによってサインオフされている
[ ] パフォーマンス目標が達成されている
### 10. Risks & Mitigation（リスクと対策）
| Risk | Impact | Probability | Mitigation |
|------|--------|-------------|------------|
| ステージング環境が不安定 | High | Medium | ロールバック計画、バックアップ環境を用意 |
| サードパーティ API の変更 | Medium | Medium | 外部サービスを早期にモック化 |
| UAT 参加者の確保が限られる | High | Low | 予備のテスターを募集し、UAT 期間を延長 |
| スコープの拡大 | Medium | High | テスト開始前に要件を固定 |
### 11. Approvals（承認）
| Role | Name | Signature | Date |
|------|------|-----------|------|
| Test Manager | [名前] | | |
| Project Manager | [名前] | | |
| Product Owner | [名前] | | |
テスト計画の例
E コマースウェブサイト公開向けに記入したテスト計画の例を紹介します:
Project: AcmeShop.com v2.0 Launch Test Manager: Alex Wang Timeline: 4週間（実行2週間 + バグ修正1週間 + UAT 1週間）
Scope（範囲）:
- ユーザー登録、ログイン、パスワードリセット
- 商品閲覧、検索、フィルタリング
- ショッピングカートとチェックアウト
- 注文履歴と追跡
- 管理側の注文管理
- 決済ゲートウェイ統合（Stripe）
Out of Scope（範囲外）:
- サードパーティの在庫管理システム（別ベンダー）
- レガシー v1.0 移行データの検証
- 1,000件を超える同時ユーザーの負荷テスト
Test Case Summary（テストケース概要）:
- 合計: 245件のテストケース（85件自動化、160件手動）
- モジュール: Auth（32）、Products（48）、Cart（55）、Checkout（70）、Admin（40）
- 期待合格率: UAT 前に95%、公開前に98%
Key Risks（主なリスク）:
- Stripe API サンドボックスは本番と動作が異なる — エッジケース用の追加テストケースで対策
- UAT 参加者は空き時間が限られた営業チームメンバー — 10名を募集し、5名のアクティブ参加を目標
Bug Tracking（バグ追跡）:
- すべてのバグレポートに BugCapturer を使用
- 重大なバグ: 4時間以内に修正し、直ちに再テスト
- 優先度の高いバグ: 24時間以内に修正し、同日再テスト
- 優先度が中程度のバグ: 公開までに修正
- 優先度の低いバグ: 公開後のバックログ
サンプルテスト計画: 主要セクションの説明
テスト目的（Test Objectives）
これが最も重要なセクションです。「なぜテストするのか?」という問いに答えます。優れた目的は具体的かつ測定可能です:- ❌ 「ウェブサイトを徹底的にテストする」
- ✅ 「Chrome、Firefox、Safari、Edge で20件すべてのチェックアウトフローがエラーなく完了することを検証する」
エントリ・イグジット基準（Entry and Exit Criteria）
エントリ基準は無駄な努力を防ぎます（壊れたビルドでテストを開始しない）。イグジット基準は時期尚早なサインオフを防ぎます（重大なバグがまだ残っているのにテストを終了しない）。バグ追跡プロセス（Bug Tracking Process）
明確なバグ追跡プロセスは、スムーズなテスト実行フェーズに不可欠です。バグの報告が速いほど、修正も速くなります。テスト実行中に BugCapturer のようなツールを使用すると、フィードバックループが加速します:- スクリーンショットの注釈 — テスターは矢印、矩形、テキストでページ上に直接問題を強調できる
- 技術メタデータの自動取得 — URL、ブラウザ、OS、画面解像度、ビューポートが自動的に取得される
- 画面録画 — バグを短い WebM 動画で録画し、トリミングしてキーフレームを抽出
- 診断データ収集 — コンソールエラーと失敗したネットワークリクエストが視覚的証拠とともに取得される
- Excel/TSV エクスポート — チーム追跡のため、構造化バグレポート行をワンクリックでクリップボードにコピー
テスト計画の作成方法
ステップ1: プロジェクトを理解する
要件を読み、ステークホルダーと話し、構築されるものを理解します。テスト計画の質は、プロジェクトへの理解度に左右されます。ステップ2: 範囲を定義する
スコープ内とスコープ外を明確に明記します。曖昧な範囲は、テスト計画における紛争の第1の原因です。ステップ3: 戦略を選択する
どのテストレベルとテストタイプがプロジェクトに適用されるかを決定します。小規模なマーケティングサイトは、銀行アプリケーションとは異なるテストが必要です。ステップ4: リソースとタイムラインを見積もる
過去のプロジェクトの履歴データを使用します。履歴データがない場合は、見積もりに30%のバッファを追加します。ステップ5: 計画を書く
上記のテンプレートを使用します。テンプレートから始め、カスタマイズしてください。ゼロから書かないでください。ステップ6: 承認を得る
誰もサインオフしていないテスト計画は、誰も従わないテスト計画です。プロジェクトマネージャーとプロダクトオーナーから書面での承認を得てください。ダウンロード: テスト計画テンプレート
上記のテンプレートは任意の形式で利用できます:
- Google Docs / Word — セクション構造を正式なドキュメントとして使用
- Confluence / Notion — 各セクションのサブページを持つテスト計画ページを作成
- Excel / Google Sheets — 各フェーズのタブを持つスプレッドシートとして使用
- Markdown — バージョン管理のためにリポジトリに保持
チームが使う形式を選択してください。形式はコンテンツほど重要ではありません。シンプルなドキュメントの優れたテスト計画は、派手なツールの悪いテスト計画に勝ります。