ISTQB Foundation Level(CTFL)シラバスの**Chapter 5「Test Management」**では、
テスト活動全体をどのように管理し、効果的に進めていくかが解説されています。
本記事では、その最初のテーマ 「5.1 Test Planning(テスト計画)」 について、
わかりやすく整理しながら具体例を交えて解説します。
🔍 テスト計画(Test Plan)とは?
**テスト計画とは、テストプロジェクトを成功に導くための「設計図」**です。
テストの目的、スコープ、リソース、スケジュール、リスクなどを明確にし、
チーム全体の行動をガイドする役割を果たします。
✅ 一言で言うと「テストをどう進めるか」をまとめた文書。
テスト計画は通常、テストマネージャー(Test Manager) が作成しますが、
内容はチーム全員に共有され、レビューを経て改善されます。
つまり、テスト計画は「作って終わり」ではなく、プロジェクトの進行に合わせて見直す“生きた文書”です。
🧭 テスト計画の目的
テスト計画書(Test Plan Document)は以下の目的を持ちます。
-
テストの目的と範囲を明確化する
何を、どこまで、どのようにテストするのかを定義します。
-
プロセスとリソースの見通しを立てる
必要な人員、ツール、予算、スケジュールを整理します。
-
リスクを事前に把握して対策を立てる
開発や品質面でのリスクを洗い出し、対応策をまとめます。
-
チームやステークホルダー間の共通理解を形成する
コミュニケーション手段・報告ルール・役割分担を明確にします。
-
テストポリシーや戦略との整合性を取る
組織レベルの方針(Test Policy)やプロジェクトごとの戦略(Test Strategy)と一致しているか確認します。
🏗️ テスト計画書に含まれる主な項目
ISTQBシラバスによると、テスト計画書には以下の内容を含めることが推奨されています。
|
項目 |
内容 |
|---|---|
|
テストの目的・スコープ(Scope & Objectives) |
何をテストするか、しないかを定義 |
|
制約条件・前提条件(Constraints & Assumptions) |
使用できるツール、リソース、環境などの制約 |
|
ステークホルダー(Stakeholders) |
関係者、責任者、報告先など |
|
役割と責任(Roles & Responsibilities) |
誰がどのタスクを担当するか |
|
リスク管理(Risk Register) |
製品リスク・プロジェクトリスクの識別と対策 |
|
テストアプローチ(Test Approach) |
テストレベル、テストタイプ、使用するテクニックなど |
|
エントリ・エグジット基準(Entry/Exit Criteria) |
テストを始める/終えるための条件 |
|
成果物(Deliverables) |
作成するドキュメント、レポート、データなど |
|
テスト環境・データ(Environment & Test Data) |
使用するテスト環境・テストデータの概要 |
|
スケジュール・予算(Schedule & Budget) |
期間、マイルストーン、コスト計画 |
|
コミュニケーション計画(Communication Plan) |
連絡手段、報告頻度、会議体の設定など |
💡 テストポリシーとテスト戦略の違い
テスト計画を理解するうえで重要なのが、
「テストポリシー(Test Policy)」と「テスト戦略(Test Strategy)」の違いです。
|
項目 |
テストポリシー (Policy) |
テスト戦略 (Strategy) |
|---|---|---|
|
定義 |
組織レベルの方針 |
プロジェクトごとの具体的な方針 |
|
内容 |
組織全体での品質基準・目的 |
どのテストレベル・手法を採用するか |
|
対象 |
全社的 |
各プロジェクト |
|
例 |
「全ての製品で静的テストを必ず実施する」 |
「このプロジェクトではリスクベースドテストを採用」 |
テスト計画はこの戦略・ポリシーに基づいて作成されるため、
整合性を持つことが非常に重要です。
📘 テスト計画は“固定”ではない
テスト計画は、一度作ったら終わりではありません。
プロジェクトの進行中に新しいリスクが見つかったり、
スケジュールが変動したりすることがあります。
そのため、状況に応じて柔軟に更新・修正することが大切です。
テスト計画は“ガイドライン”であり、現実に合わせて調整されるべきものです。
🧩 実例:テスト計画のイメージ
例えば、スマートフォンアプリの新機能テストを計画するとします。
-
スコープ:ログイン機能、通知機能、新デザイン画面
-
対象外:管理者用Webポータル(今回は範囲外)
-
リスク:通知遅延が発生する可能性 → 通信遅延シミュレーションを実施
-
スケジュール:10月1日〜10月15日
-
リソース:QA 2名、テスト端末3台
-
戦略:リスクベースドテスト+探索的テストを組み合わせる
-
報告方法:毎日Slackで進捗共有、週次でレビュー会議
このように、誰でも見て理解できるように具体的に書くことが理想です。
🧠 まとめ:テスト計画の本質とは?
テスト計画の本質は、**「チームが同じ方向に進むための道しるべ」**を作ること。
目の前のタスクをこなすのではなく、
“なぜそのテストを行うのか”という目的意識を持たせる文書です。
計画の質が高ければ、
プロジェクトの予測精度が上がり、品質向上にも直結します。



コメント