テスト計画書とは？目的や立案手順、テンプレートを紹介

テスト計画書は、ISTQB標準用語集Version4.6.2において下記のように定義されています。

“達成すべきテスト目的およびそれらを達成するための手段やスケジュールを示し、調整したテスト活動を体系化したドキュメント。”

また、ISTQB Foundation Levelのシラバスでは、テスト計画書の記載内容や目的が以下のように説明されています。

テスト計画書は、テストプロジェクトの目的、リソース、プロセスを表す。

• テスト計画書は、テスト目的を達成するための手段やスケジュールを文書化する
• テスト計画書は、実施したテスト活動が、確立した基準を満たすことを保証するのに役立つ
• テスト計画書は、チームメンバーやステークホルダーとのコミュニケーション手段としての役割を担う
• テスト計画書は、テストが既存のテストポリシーやテスト戦略を遵守することを示す（またはテストがそれらから逸脱する理由を説明する）

参照：
ISTQB用語集
JSTQB-SyllabusFoundation_VersionV40.J02

これを基に、もう少し説明していきます。

以降は、ウォーターフォール型の開発を想定して、ISO/IEC/IEEE 29119やISTQBの用語だけでなく平易な用語も用いて説明します。

テスト計画書の種類

テスト計画書は、プロジェクトで実施する全てのテストの方針や概要を定義する「全体テスト計画書」と、工程ごとやテストの種類ごとなど特定のテストプロセスに関して詳細かつ具体的な内容を定義する「個別テスト計画書」に大別されます。これらは、マスターテスト計画書、レベルテスト計画書などとも呼ばれます。

個別テスト計画書はさまざまな切り口で作成されますが、例えば以下のような種類が挙げられます（図表1）。

これらは別々の文書に分けて記載してもよいですし、全体テスト計画書も含めて一つの文書にまとめて記載することもできます。文書の形態も大事ですが、全体と個別とをそれぞれ意識して計画を検討することが大事です。

Zoom

※図表１では、プロジェクトで固有のテスト工程やテストの種類別に個別テスト計画書を作成した場合の例を示しています（ISTQBのシラバスで用いられているテストレベルやテストタイプの名称とは異なります）。テスト計画書の分け方はさまざまありますので、組織やプロジェクトにおいて適切な分け方を検討してください。

なお、ISO/IEC/IEEE 29119 -3:2021に、テスト計画書と関連するドキュメントが図示されています。参考にしてください（図表2）。

全体テスト計画書／個別テスト計画書の作成時期と目的

テスト計画書は、開発プロセスのできるだけ早い段階に作成することを推奨します。

テスト計画書を検討する中で、テスト活動を阻害する可能性のある要因が浮かび上がることがあります。また、外部組織との調整が必要な場合、調整に時間がかかることもあります。これらを適切な時期に対処するために、テスト計画書の作成を先送りせずに、以下のような時期に作成しましょう。

全体テスト計画書と個別テスト計画書と、それぞれの作成時期と目的を図表3に記します。

図表3：全体テスト計画書と個別テスト計画書の作成時期

テスト計画書を早い段階に作成しておくと、プロジェクトが進むにつれて変化する状況と当初想定との乖離をチェックすることが可能になります。加えて、当初のテスト計画書作成時にステークホルダーと合意を得ておくことで、何らかの乖離が検出された際にテスト計画の見直し協議が円滑に進むことも期待できます。

――――――――――――――――――――――――

（補足） 

ここでは、テストレベル、テストタイプ、テスト工程を以下の意味としています。

• テストレベル
  系統的にまとめたテストを管理する単位。ISTQB Foundation Levelシラバスでは、コンポーネントテスト、コンポーネント統合テスト、システムテスト、システム統合テスト、受け入れテストの五つのテストレベルが説明されています。ここでは、これらと同一でなくてもよいですが、それぞれが重複しない明確な定義がされたものを想定しています。
• テストタイプ
  特定のテスト対象やテストの目的、品質特性などに焦点を当てて分けられたテストの種類。負荷テスト、ユーザビリティテスト、災対環境テストなど、さまざまな種類があります。
• テスト工程（テストフェーズ）
  プロジェクトで決めたテストを管理する単位であり、プロジェクトで管理しやすいように任意に定義したもの。テストレベルをそのままテスト工程として採用することも可能ですが、一つのテスト工程に複数のテストレベルを含ませたり、同一のテストレベルを複数のテスト工程に含ませたりすることもあります。

―――――――――――――――――――――――― 

テスト計画書は、ビジネス文書としての定型内容や可読性を高めるための概要、テストの内容そのもの、テスト管理に関するもの、それらの根拠となる情報など多岐にわたり記載します。

全体テスト計画書と個別テスト計画書とで記載項目は大きくは変わりませんが、記載する詳細度や具体度は変わります。

本記事では、ISO/IEC/IEEE 29119を基に策定したテスト計画書の記載項目の例を示します（図表4）。これは一例ですので、プロジェクトの形態や規模、組織の文化などにより、テスト計画書の記載項目や記載粒度などを適切に設定してください。それらにより、テスト計画自体にかかる工数も変わります。

なお、『ISO/IEC/IEEE 29119-3:2021 ソフトウェアおよびシステムエンジニアリング—ソフトウェアテスト—パート3：テストドキュメント』ではより細分化されたテスト計画書の記載項目が提示されていますので、参考にしてください。

図表4：テスト計画書の記載項目（例）

テスト戦略・テスト設計書との違い

テスト計画書と、テスト戦略やテスト設計書が混同されることがあります。テスト計画＝テスト戦略と称する組織もあるようです。

また、組織レベルで定めるテストの基本的な考え方や方針（ISO/IEC/IEEE 29119で示されるテストポリシーに近い内容）をテスト戦略と称する組織もあるようです。

個々のプロジェクトにおけるテスト戦略は、テスト計画書に記載されるべき内容の一部です。よくいわれる”テスト戦略”は、本記事で紹介したテスト計画書の記載項目“テスト内容：3. テスト範囲・テスト方針”の部分に示されるものに近いと思います。

一方、テスト設計書は、テストケースやテストデータ要件などの総称です。テスト計画書を基に作成されるものであり、テスト計画書とは別のドキュメントです。

なお、これらの用語は、ISTQB標準用語集 Version4.6.2では以下のように説明されています（図表5）。

図表5：テスト戦略・テスト設計の関連用語

全体テスト計画書と個別テスト計画書とで検討する流れは大きくは変わりませんが、インプットとする資料や考えるポイント、決定する事項は異なります。

『ISO/IEC/IEEE 29119-2:2021 ソフトウェアおよびシステムエンジニアリング—ソフトウェアテスト—パート2：テストプロセス』の中に、テスト計画のプロセスが定義されていますので参考にしてください。

テスト環境、体制、スケジュールなどや、個別テスト計画書に記載するテスト内容はイメージしやすい方も多いでしょうから、本記事では全体テスト計画書に記載するテスト内容の決め方を記載します。

なお、一気に全てを記載することを目指さなくても構いません。不明点や未確定事項はT.B.Dとして、記載できるところから記載してみましょう。それにより、プロジェクトで決めなければならない事項が特定されるという利点もあります。

【全体テスト計画書】テスト内容の決め方

全体テスト計画書を検討する中で、プロジェクトの目的に従い最終的にどのような品質を担保するのかを明確にします。その品質を担保するためには、プロジェクト計画書にて定められた各テスト工程で、システムのどこに対してどのようなテストレベル・テストタイプを実施するのかを組み立てます。全ての事項をテストすることはできないため、特に重視する点、逆に軽くする点はどこかも決めます。

これらを決めるためには、テスト対象に対する理解やプロジェクトに求められる事項や状況などさまざまな理解が必要です。

テスト内容を決めるために実施すべき事項の例を以下に例示します（図表6、図表7）。以下以外にも必要な調査・検討を行ってください。また、一方向に進むだけではなく、必要に応じて繰り返して検討を深めてください。

インプット（例） 

• プロジェクト計画書
• プロジェクトのキックオフ資料 
• 要件定義書
• 顧客やベンダーからのテストに対する要求事項（ヒアリング結果）
• 過去プロジェクトのノウハウ（過去資料） 

調査・検討事項（例）

図表6：調査・検討事項の例

※1 テストレベル・テストタイプ 
組織において、テストレベル・テストタイプの全量を一覧化したものを用意しておくと良いでしょう。それを用いて該当プロジェクトでの実施有無を特定すると、検討漏れが防げます。また、テストしないと決めた箇所は、テストしなくても品質が担保できる理由を明確にしましょう。

※2　No.5 各テスト工程でのテスト方針の検討が一番の肝です。
プロジェクトで実施すると決めたテストレベル・テストタイプは、いずれかのテスト工程にて実施するよう配置します。一つのテスト工程に複数のテストレベル・テストタイプを配置することも検討可能です。あえて複数のテスト工程に同じテストレベル・テストタイプを重複して配置することもあります。効果的かつ実現性のあるように組み立てます。これにより、どの工程でどの情報／環境／資材が必要なのかも特定します。特に、外部との調整事項に留意しましょう。

決定事項（例）

図表7：決定事項の例 

なお、品質に関する要求事項を整理する際は以下などが利用できます。

• JIS X 25010：2013 (ISO/IEC 25010：2011)
  システムおよびソフトウェア製品の品質要求および評価（SQuaRE）−システムおよびソフトウェア品質モデル
• JIS X 25012：2013 (ISO/IEC 25012：2008)
  ソフトウェア製品の品質要求および評価（SQuaRE）−データ品質モデル
• 非機能要求グレード2018（IPA）

前述した通り、個別テスト計画書はさまざまな切り口で分けられて作成されます。分け方の例を図表8に記します。プロジェクトに合った分け方を選択してください。

図表8：個別テストの分類と例

本ページで解説している考え方を基に作成した、全体テスト計画書のテンプレートをダウンロードいただけます。

「全体テスト計画書のテンプレート」のダウンロードはこちら

本テンプレートには、本記事で紹介した内容を記載する項目を用意してあります。全体テスト計画書作成時の検討漏れを防ぎ、テスト方針やテスト範囲、体制、管理、リスクなどを体系的に整理するためのひな形としてご利用いただけます。

記載内容や構成は一例ですので、実際のプロジェクトの特性や要件に応じて改変・調整の上ご利用ください。

適切なテスト計画書を作成しようとすると、プロジェクトを広く深く検討することになります。そのため、テスト工程だけでなく、テスト工程へのインプットとなるドキュメント類を作成する上流工程での課題にも気付き、改善につながることが多々あります。

適切なテスト計画書を作成するのは手間がかかりますが、その手間以上に良い効果を得られることでしょう。ぜひ、本記事で紹介した内容を参考にしてテスト計画書を作成してみてください。

ベリサーブでは、テスト計画の策定から終結までのプロセスにおける、品質リスクの発見や評価、監視測定、対策、振り返りなどを広範にわたり支援するサービスを提供しています。

詳細は、以下のページをご確認ください。

検証PMOサービス （テストマネジメント支援サービス）