ある程度の規模のシステム開発プロジェクトであれば、要件定義フェーズなどのプロジェクトの初期段階で「マスターテスト計画書」を作成するプロジェクトが多いだろう。この文書は、プロジェクトで実施するテストの実施方針や体制、スケジュールなどを定義したものだ。プロジェクト特性を押さえて、プロジェクトごとにカスタマイズした“中身のある”文書を作成しなければならない。

　マスターテスト計画書はプロジェクトにおけるテストの根幹となるが、きちんとした検討プロセスを経て作成されている現場は多くない。要員が足りない、時間がないといった様々な理由により、要件定義書やプロジェクト計画書に比べると、十分な配慮のうえで作成されているとはいい難いのが実情だ。

　頻繁に見かけるのが、過去案件や社内標準のサンプルをそのまま使ったマスターテスト計画書だ。体制やスケジュールといった明らかに異なる部分は手直ししているが、テストの内容などマスターテスト計画書の肝になる部分に関しては、十分な検討をせずに流用していることが多い。いわば、中身のないマスターテスト計画書だ。これは駄目な例の典型といえる。

　これだと、単体テスト、結合テスト、システムテスト、受け入れテストといったタイミングを迎える都度、何をテストの対象にするか、どんなテストを実行するかを個別に検討しなければならない。場当たり的にテストの項目や実施方法、手順などを考えると、次のような問題が起こる。

　まず、何を確認するためにどのようなテストを行うのかが可視化されない場合がある。それにより、関係者間で認識にずれが生じ、テストの漏れが起こりやすくなる。さらに、単体テスト、結合テスト、システムテストといったテストの各レベルで何を確認するつもりなのかが明確にならない。プロジェクト全体を通して、十分なテストができているかどうかを判断しづらい。

マスターテスト計画書はテストの要件定義書

　マスターテスト計画書はプロジェクトの初期段階、具体的には要件定義フェーズで策定する。プロジェクトによっては「全体テスト計画書」などとも呼ばれる。プロジェクト全体を俯瞰して、行うべきテストを決め、そのテストをどのように行っていくか、といったことを中心に記述する。テストでの実施事項や役割分担などに関して、関係者間で合意する基となる文書でもある。

　マスターテスト計画書の中で特に重要なのが、テスト内容だ。テスト内容とは「何を確認するために、どのようなテストを行うのか」ということ。テストを1つのプロジェクトと捉えると、テスト内容を明確にするマスターテスト計画書の作成プロセスは要件定義に当たる。

　ちなみに、単体テストや結合テストといった各テスト工程に応じて、プロジェクトの途中で個別に作成する「個別テスト計画書」もある。これは、個別のテスト工程に限定して具体的な計画を記述する文書だ。マスターテスト計画書とは作成の目的がやや異なるし、個別テスト計画書はマスターテスト計画書をインプットに作成する。そのため、仮に個別テスト計画書をしっかり作ったつもりでも、マスターテスト計画書の内容が不十分だとプロジェクト全体を通して見るとテストに漏れがある可能性がある。

　例えば、マスターテスト計画書を作成するユーザー企業と、マスターテスト計画書をインプットに個別テスト計画書を作成する開発ベンダーの間で、テスト内容に認識の相違が生じたりする。これがプロジェクトの途中で発覚すると、スケジュール変更や予算の見直しが必要になったりする。また、各テスト工程のテスト担当者が「テストをしっかり行った」と主張しても、プロジェクト全体を通じた抜け漏れがないかどうかを判断できない。

　マスターテスト計画書はプロジェクトにおけるテストの根幹となる。テストフェーズが慌ただしい進行になるのは、マスターテスト計画書作成時に、テスト内容の検討を十分に行ってこなかったのが原因かもしれない。

　なお、過去案件や社内標準のサンプルの活用そのものが悪いわけではない。計画作業の効率化に有効な場合も多い。ただ、プロジェクトごとに事情や背景が異なることを忘れてはならない。それに応じて行うべきテストは異なってくるため、プロジェクトに合わせたカスタマイズは必須となる。プロジェクト特性を押さえたうえで、テストで何を確認するのか、どのようなテストを行うかといったテストの中身をプロジェクトごとに考えなければならない。