テスト計画書とは、テスト計画においてテストのすべての指針を定めたものをまとめたドキュメントのことを指します。
テスト計画が適切に策定できれば、テストプロジェクトは円滑に遂行される可能性が高まるため、テストの成功・失敗は、テスト計画で決まると言っても過言ではありません。
本記事では、Qbookで公開している「テスト計画書」のテンプレートに沿った形で、計画書の作成方法について説明しています。
無料でダウンロードしていただけるテンプレートは、ISO/IEC/IEEE 29119（以下、29119規格）に対応しており、29119規格に準拠させる場合、必須項目を入力していくことで規格に適合したテスト計画書が完成させることができます。ぜひ、実務での計画立案にご活用ください。
1．テスト計画書とは
テスト計画書は、テストの設計・実装・実施・管理といったテストのすべての指針をまとめたドキュメントのことです。
テストの目的や背景、スケジュールなど全体像を表していきます。
また、具体的な担当者の役割や体制、想定あれるリスクなども記述します。
テストを円滑に進めるためにとても重要なものです。
2．「QUINTEE テスト計画プロセス（29119規格対応）」の使い方
Qbookでは、テスト計画書のテンプレートを無料でダウンロードすることができます。
本記事ではそのテンプレートに沿って、テスト計画書の書き方を解説していきます。
この章では、書き方に入る前にテスト計画書テンプレートの使い方をご紹介します。
テスト計画プロセス／テンプレート（29119規格対応）
ISO/IEC/IEEE 29119（以下、29119規格）に対応したテスト計画に関するテンプレートを公開しています。 「テスト計画」とは、テストの設計、実装、実施、管理といった、テストのすべての指針を定めるものです。ぜひ、実務での計画立案にご活用ください。
「テスト計画書」のテンプレートの活用方法について、いくつかを例を示しながら解説します。
テスト対象やプロジェクト内容に応じて変更してください。
テンプレートをダウンロードして、サンプルの通りに記入すれば良いということではありません。
テストプロジェクトそのものを設計し、意図を持った「テスト計画」を行うことが最も重要です。
テンプレ―ト内の「*」は29119規格に準拠の場合に必須
テンプレートのには「*」（アスタリスク）が記載された項目あります。これが記載された項目は、29119規格に準拠する場合の必須項目です。
テストドキュメントに記載すべき共通要素
以下の項目は、29119規格に準拠する・しないにかかわらず、テストドキュメントに共通で記載が必要です。
- 一意の識別子 ：テストドキュメントや記録を一意に識別するためのもの 例）タイトル、発行日、バージョン、文書のステータスなど
- 発行組織 ：テストドキュメントの作成と発行に責任を持つ組織
- 承認権限 ：テストドキュメントや記録の責任者
- 変更履歴 ：テストドキュメントや記録の開始以降に行われた変更のログ
- ステータス ：テストドキュメントのステータス。 例）「作成中」や「承認済み」など
- はじめに ：テストドキュメントや記録の背景や成り立ち
- スコープ ：テストドキュメントや記録によって、対象領域がカバーされている範囲 例）除外や制限などがあれば記述
- リファレンス ：参照された他の文書または記録を列挙します。（情報の保管場所を含む） 例）ポリシー、プラン、手順、その他のソース・データなど
- 用語集 ：テストドキュメントで使用されている用語、略語、頭字語がある場合は、その辞書を提供します。
3．テスト計画書：テンプレートの書き方11のポイント
テンプレートの書き方のポイントを解説致します。作成中の参考にしてみてください。
下記ではテンプレ―トのうち、一部の代表的な項目を紹介しています。
本書の対象（章番号：2.1）
「本書の対象」では、テストのスコープを明確化します。
テスト対象、対象ユーザー、システムの目的、システムがどのように利用されるのかといった詳細、新規開発なのかバージョンアップなのか、といった開発分類を記載します。
また、テストのスコープに包含される、または除外や制限、仮定など、補足説明が必要な場合は記載します。
テストの背景、テストの目的および目標（章番号：3.1, 3.2）
「テストの背景」、「テストの目的および目標」には、テスト計画を作成するプロジェクト、テストレベル、テストタイプ、およびその他の関連するコンテキスト情報（前後関係、事情、背景、状況など）を記載します。
※テンプレートでは、「現在の状況」と「問題点/懸念事項」に分けて記載していますが、この２つに捕らわれる必要がありません。
「テストレベル」、「テストタイプ」については、後述します。
テストレベル（章番号：4.1）
「テストレベル」とは、「単体テスト」「結合テスト」「システムテスト」「受け入れテスト」といった、ソフトウェア開発のライフサイクルにあるテストの段階です。
テストアイテム（章番号：4.4）
「テストアイテム」とは、テスト対象となる要素です。テストアイテムは、テスト対象によって、大小様々なケースがあります。例えば、コピー/スキャン/FAXの機能を有する複合機では、FAX受信機能を対象にするのか、スキャン機能だけを対象にするのか、など大小様々なケースが考えられます。
「スキャン機能」といっても、原稿読み取りガラスに原稿を載せてスキャン機能の各種設定をテストする場合もあるでしょうし、自動原稿送り装置を使ったスキャンのテストを含むテストを行う場合もあるかもしれません。
テスト計画の中では、このテストでカバーされるテストアイテムを識別します。
対象となるファームウェアやソフトウェアのバージョン/リビジョン情報などがあれば、それも明確にします。
テストアイテムを明確化することにより、テストの対象範囲について関係者と認識を合わせて、後から「ここまでテストして欲しかったのに...」という認識の齟齬を防止できます。
テストタイプ（章番号：4.5）
「テストタイプ」とは、コンポーネントやシステムのある特性に対応したテストの目的を基にテスト活動をまとめたものです。具体的には、「機能テスト」のほかに、性能要件に定義された効率性（時間、資源）で動作することを確認する「性能テスト 」や、 過負荷状態においても仕様通り動作することを確認する「ストレステスト」などがあります。
例えば、テストレベル「システムテスト」の中で、テストタイプ「機能テスト」と「性能テスト」「ストレステスト」を含む場合などがあります。
テストタイプの一例
テスト計画のスコープとして、どの範囲までのテストを行うのかをテスト計画書に記載しますが、具体的には、リスク低減策として対象テストタイプが特定できれば、テスト計画書の範囲で扱う対象となるテストタイプに「〇」をつけます。
リスク（章番号：7, 14）
「リスク」では、テスト計画活動の一環として特定されたリスクを列挙します。各リスクについて、その影響と確率に基づいてそのリスクが現実化するレベルを評価・分析します。
そのうえで、リスクの種類、分類、リスクスコアに基づいて、リスクを処理するための手段を特定します。
29119規格では、「プロダクトリスク」と「プロジェクトリスク」を分類して管理することが求められています。
プロダクトリスク（テンプレート番号：7.1）
「プロダクトリスク」とは、開発したソフトウェアを利用する際に、利用者の想定通りにソフトウェアが機能しないというリスクを指します。
テストに関連する「プロダクトリスク」には、機能的な欠陥や性能などの非機能的な側面での欠陥が含まれます。（性能などの非機能面を含む）
プロジェクトリスク（テンプレート番号：14.2）
「プロジェクトリスク」とは、プロジェクトのスケジュール遅延、予算への過剰な負担など、プロジェクトのパフォーマンスを低下させる何らかの要因により、プロジェクトの成功に影響を及ぼすおそれがあるものを指します。
テスト関連の「プロジェクトリスク」には、スケジュールやリソースに関連するリスクが含まれます。
テストに用いる技法（テンプレート番号：8.5）
テスト計画書のスコープに対して、どの「テスト設計技法」を用いるかを指定します。
29119シリーズで紹介されている「テスト技法」には、以下のようなものがあります。
テスト開始/終了基準（テンプレート番号：10.1）
テストの開始/終了の基準を明確化します。
※29119シリーズでは、テストプロセスのそれぞれや、選択されたプロセスについて、もしくは、テストレベルまたはテストタイプについて異なる開始/終了基準を定義することもできる、としています。
テスト中断/再開基準（テンプレート番号：10.2）
テスト中断/再開基準には、対象のテスト活動を中断、再開するための基準を指定します。
テスト活動を中断・再開する権限を誰が持っているのかを特定します。
テスト完了基準（テンプレート番号：10.3）
テストの完了基準を明確化します。
テスト技法のテスト実行が完了したとみなされる条件があれば、以下のように記載することもできます。
例）状態遷移テストのテスト完了基準
「テスト中に状態モデルのすべての状態を通過するまで、テストの実行を継続する」
収集するメトリクス（テンプレート番号：11.1）
収集するメトリクスの一例には以下のようなものがあります。
対象のテストで、収集してモニタリング対象とするメトリクスを明確化します。また、開発規模やコードステップ数など、開発からの情報提供が必要なものがある場合、事前に情報提供が可能か確認します。
4．「テスト計画書」テンプレート利用時の注意点
テスト計画の目的は、テストの設計、実装、実施、管理といった、テストのすべての指針を定めるものです。
テンプレートをダウンロードして、サンプルどおりに形式的に文書を埋めて作成すれば完璧なテスト計画ができるというわけではありません。本当に実施すべき目的や意図に基づいた「テスト計画」を行うことが最も重要です。
まとめ
今回はテスト計画のテンプレートの活用方法について解説しました。
テストを開始する前に、テストの目的やスコープ、リスクや守るべき規制・基準、活動スケジュールなど、テスト活動全体の全体方針をドキュメントとして関係者間で合意することで、テスト範囲や内容についての誤解による手戻りやテスト設計の手戻りなどを予防することができます。
また、テスト環境やテストデータの要件を整理し、テスト実行フェーズで管理すべきメトリクスなどを計画することも重要です。
後から確認する手間が省けたり、逆に後行程で確認する必要が出てきた場合の参考資料として大いに役立てたりすることができます。
このテンプレートをご利用いただくことで、計画が立てやすくなるかと思います。
ぜひ社内でのプロジェクト推進にご活用ください。
