外注先から納品された単体テスト済みモジュールで、結合テストの段階でバグがたくさん発見された。本来、単体テストで摘出すべきバグなのに――。システム開発の現場では、こうした問題がよく起こる。「どこからどこまで何をテストするのかが単体テストか」という認識が、元請け企業と下請け企業の間で異なるのが原因だ。
規模や複雑度が一定以上のシステムやプロダクトでは、一気に全モジュール、全機能、全システムを結合してテストするのは現実的ではない。システムやプロダクトをある粒度で区切る、というアプローチが一般的となる。まずは最も細かい粒度でテストを実施して、段階的に結合して大きな粒度にしながらテストを進めていく。
こうしたテスト対象を区切る粒度を「テストレベル」と呼ぶ。テストレベルの種類は、組織やプロジェクトごとにさまざまな定義がある。よく見かけるのが「単体テスト」「結合テスト」「システムテスト」「受け入れテスト」といった4段階の定義だろう。ウォーターフォール型の開発プロセスでは、要求～詳細設計の各開発工程に単体テスト～受け入れテストといった各テストレベルが対応する。結合テストを「内部結合テスト」「外部結合テスト」とさらに詳細化する場合もある。
細かい粒度から段階的にテストを行っていくため、バグを特定しやすいのがメリットだ。一方、デメリットもある。冒頭のように、テストレベルの認識がずれてしまいやすいのだ。“単体テスト済み”なのにバグが多発するのは、だいたいの場合で下請け企業（テスト実施者）がサボっているからではない。元請け企業（テスト発注者）と下請け企業の間で「単体テストとはどこからどこまで何を検証するのか」の認識が一致していないのが原因だ。
このような問題が発生するのは、単体テストに限った話ではない。テストレベルの種類は組織やプロジェクトごとにさまざまな定義がある。そのため、明確に定義をしておかないと、認識がずれやすい。
テストレベルを分かりやすく明確に定義
トラブルを避けるには、プロジェクトの初期段階（要件定義フェーズ）で作成する「マスターテスト計画書」が重要な役割を果たす。関係者の誰もが理解できる表現でテストレベルを明確に定義して、マスターテスト計画書に記載しておくのだ。マスターテスト計画書はプロジェクト全体を俯瞰して、行うべきテストを決め、そのテストをどのように行っていくかを記述する文書である。
以下では、テストレベルの定義で押さえておきたい2つのポイントを解説する。
