テストレベルとは、ソフトウェアテストを開発工程の段階に応じて体系的にグループ化した分類です。JSTQBでは「系統的にまとめ、マネジメントしていくテスト活動のグループ」と定義され、一般に単体テスト（コンポーネントテスト）・結合テスト（統合テスト）・システムテスト・受け入れテストの4段階に分けられます（最新のv4.0では統合テストが2つに分割されています）。
やっかいなのは、このテストレベルがテストタイプやテストフェーズと混同されやすい点です。チーム内で「結合テスト」の指す範囲がずれたまま進行し、テスト漏れや手戻りが起きることもあります。
そこでこの記事では、JSTQBシラバスに基づくテストレベルの正確な定義と、4段階それぞれの目的・対象・実施者を整理したうえで、テストタイプやテストフェーズとの違いまで解説します。
テストレベルごとに何をどこまで検証するか、計画の切り分けが定まらないまま進めると、段階間でテスト漏れや手戻りが起きがちです。ISO/IEC/IEEE 29119準拠のQUINTEEメソッドで各テストレベルの計画策定から実行まで一貫して支援するバルテスのソフトウェアテスト支援サービスを、テスト計画を固める際の相談先として検討してみてください。
テストレベルとは？ 開発工程と対になるテストの段階区分
テストレベルは、ソフトウェアテストを開発段階に応じて体系的にグループ化した分類であり、JSTQB／ISTQBの国際標準で定義が定められています。単なる作業区分ではなく、V字モデルの各開発工程と対応づけて理解すべき概念です。
ここではまず、JSTQBの公式定義でテストレベルの意味を確定し、続いてV字モデルの開発工程との対応関係を整理します。
1-1. JSTQBシラバスが定める「テストレベル」の定義
JSTQBシラバスv4.0では、テストレベルを「系統的にまとめ、マネジメントしていくテスト活動のグループ」と定義し、各テストレベルは個々のコンポーネント単位から完成したシステムまでの開発段階に応じたテストプロセスのインスタンスであるとしています（出典：tech.learningift.com（JSTQB(ISTQB)調査）「JSTQB Foundation Level シラバス Version 2023V4.0」2023年）。
「テスト活動のグループ」とは、計画・分析・設計・実行といった一連のテスト作業を、対象の粒度ごとにまとめた単位を指します。「テストプロセスのインスタンス」という言い方は、同じテストの進め方（プロセス）を、コンポーネント段階・システム段階といった各段階で個別に実体化して回すという意味です。つまりテストレベルとは、同じ手順を粒度違いで繰り返す各段階の実行単位だと捉えると分かりやすくなります。
テストを段階に分けるのは、テスト対象の粒度を少しずつ広げていくためです。小さな単位から順に検証することで、その段階でしか見つけにくい欠陥を効率的に検出し、次の上位段階へ欠陥を持ち越さずに済みます。小さな部品の不具合を早い段階で潰しておけば、システム全体を組み上げた後で原因を探す手間を減らせるわけです。
1-2. V字モデルにおけるテストレベルと開発工程の対応
V字モデルは、左辺に開発工程、右辺にテストレベルを配置し、両者を対応づけて示すモデルです。左辺を上から要件定義・基本設計・詳細設計・実装と下りていき、右辺を下から順にコンポーネントテスト・統合テスト・システムテスト・受け入れテストと上がっていく形で対応します。
この対応関係の要点は、各テストレベルのテストベース（テストの根拠とする文書）が、対応する開発工程の成果物になっている点です。詳細設計に対してコンポーネントテスト、基本設計に対して統合テスト、そしてシステムテストはシステム要件、受け入れテストは要件定義や業務要件をテストベースとします。
成果物とテストレベルを対応づけておくと、「何を根拠に、どの段階で検証するか」がぶれません。要件定義で決めた業務要件は受け入れテストで確認し、詳細設計で決めた内部ロジックはコンポーネントテストで確認する、という筋道が明確になります。
4つのテストレベルの目的・テスト対象・実施者
4つのテストレベルは、それぞれテスト対象の粒度と検証目的が異なり、適した担当者が段階的に実施することで欠陥の上位レベルへの流出を防ぎます。
以下では、単体テストから受け入れテストまでを、目的・テスト対象・実施者・別称の4軸で順に解説します。
2-1. 単体テスト（コンポーネントテスト）
単体テストは、プログラムを構成する最小単位を個別に検証するテストレベルです。ユニットテスト、モジュールテストとも呼ばれ、UTと略されることもあります。JSTQBの標準名称ではコンポーネントテストと呼びます。
目的は、個々の部品が仕様どおりに動くかをロジックとデータフローの両面から確かめることにあります。テスト対象は関数・メソッド・クラスといった最小単位で、実施するのは基本的にその部品を書いた開発者です。分岐条件の誤りや変数の初期化漏れといった内部ロジックの欠陥を、この段階で早期に検出します。
2-2. 結合テスト（統合テスト）
結合テストは、単体テストで検証済みのモジュールを組み合わせ、その接続部分を検証するテストレベルです。ITと略されることもあり、JSTQBの標準名称では統合テストと呼びます。
目的は、モジュール間のインターフェースやデータ連携が正しく機能するかの確認です。テスト対象はモジュール同士の接続部分で、単体では正しくても、値の受け渡し形式やデータ型の食い違いで不具合が出る箇所を狙います。実施主体は開発者とテストエンジニアが協力する形が一般的です。
なお、JSTQBシラバスv4.0では、統合テストレベルがコンポーネント統合テストとシステム統合テストの2つに分割されました（出典：co-well.jp（JSTQB調査）「JSTQB Foundation Level シラバス Version 2023V4.0 変更点解説」2024年）。
前者はソフトウェア内部のコンポーネント間連携を、後者はシステムや外部サービスとの連携を扱う区分です。「結合テスト」と一口に言っても指す範囲が広いため、この分割はスコープを明確にする助けになります。この分割によりv4.0のテストレベルは形式的には5つになりますが、本記事では実務で広く使われる4段階（統合を1つの段階とみなす区分）を基本に整理しています。
2-3. システムテスト
システムテストは、統合を終えたシステム全体をひとまとまりとして検証するテストレベルです。現場では総合テスト、またはSTと呼ばれます。
目的は、機能要件だけでなく非機能要件まで含めた包括的な検証です。画面遷移や業務フローといった機能面に加え、性能・セキュリティ・可用性などの品質特性も対象に入ります。テスト対象はシステム全体で、開発者から独立したテストエンジニアが中心となり、本番環境に近い条件で実施することで、実運用に耐えるかを見極めます。
2-4. 受け入れテスト
受け入れテストは、完成したシステムが業務で使えるかをユーザー視点で確認する最終段階です。UAT（ユーザー受入テスト）やATとも呼ばれます。
目的は、システムが業務要件を満たしているかの確認であり、「仕様どおり動くか」ではなく「業務が回るか」を問う点がほかのレベルと異なります。テスト対象は本番環境相当の条件下でのシステム全体で、実施主体は開発側ではなく発注者やビジネス部門です。実際の利用者が自分たちの業務シナリオで操作し、受け入れの可否を判断します。
ここまで見たとおり、同じ「結合テスト」でも現場によってAPI単体の連携を指す場合とシステム間連携を指す場合があります。テストレベルの名称と実際のスコープは必ずしも一致しないため、計画の初期段階でチーム内が各用語で何を指すかをすり合わせておくと、後工程での認識齟齬を避けられます。
テストレベルとテストタイプは何が違う？ 混同しやすい概念の整理
テストレベルは「いつ・何の粒度でテストするか」の段階区分です。これに対しテストタイプは「何の品質特性をテストするか」の目的別分類であり、両者は分類軸が異なる別概念です。この区別が曖昧なまま進めると、テスト計画の抜け漏れや議論のすれ違いを招きます。
テストレベルと混同されやすい概念は、テストタイプ・テストフェーズ・テスト技法の3つです。以下では、まずテストタイプとの直交関係を整理し、続いてテストフェーズとテスト技法との区別を扱います。
3-1. テストタイプとの違いと直交する関係
テストタイプは、特定の品質特性に焦点を当てたテスト活動のグループです。機能テスト・非機能テスト（性能・セキュリティなど）・ホワイトボックステストといった分類がこれにあたり、いずれのテストレベルでも実行できます。
テストレベルとテストタイプは「段階」と「品質特性」という別々の軸であり、直交する関係にあります。例えばシステムテストレベルの中で、機能テスト・性能テスト・セキュリティテストを組み合わせて実施できます。
「システムテストで何を確認するか」を決めるのがテストタイプ、という関係です。
| 比較軸 | テストレベル | テストタイプ |
| 分類の視点 | いつ・どの粒度でテストするか | 何の品質特性をテストするか |
| 分類基準 | 開発工程に対応する段階 | 検証対象の品質特性・目的 |
| 具体例 | 単体／結合／システム／受け入れ | 機能テスト／性能テスト／セキュリティテスト |
3-2. テストフェーズ・テスト技法との区別
テストレベルと似て非なる概念が、もう2つあります。日程の区切りであるテストフェーズと、テストケースの作り方であるテスト技法です。この2つは分類の目的がテストレベルとまったく異なります。
それぞれを順に見ていきます。
テストフェーズとの違い
テストフェーズは、テスト実行を日程で区切ったグルーピングです。「10月はこのテストを実施する」といったスケジュール上の区分であり、対象の粒度で分ける概念的分類であるテストレベルとは性質が違います。
両者が混同されやすいのは、ウォーターフォール開発ではフェーズとレベルが一致しやすいからです。単体テストの期間・結合テストの期間というように日程がテストレベルにほぼ対応するため、「結合テスト」がスケジュールの名前なのか粒度の名前なのか曖昧になります。
ちなみにテストレベルは概念的分類なので、アジャイル開発でも各イテレーション内でコンポーネント・統合・システムの各段階として適用でき、ウォーターフォール専用の考え方ではありません。
テスト技法との違い
テスト技法は、同値分割や境界値分析に代表される、テストケースの導出方法です。「どうやってテストケースを洗い出すか」を扱う手段であり、段階を示すテストレベルや品質特性を示すテストタイプとは別の軸に位置します。
テスト技法は、どのテストレベル・どのテストタイプでも横断的に使えます。例えば境界値分析は、コンポーネントテストの入力値検証にもシステムテストの機能テストにも適用できます。自チームでテスト計画を設計する際は、テストレベルを縦軸、テストタイプを横軸に置いた対応表を作り、各セルにどのテスト技法を使うかを埋めていくと、抜け漏れと用語の食い違いを同時に整理できます。
テストレベルの理解をテスト計画に活かすために
テストレベルは、開発工程と対になるテスト活動の段階区分であり、テストタイプやテストフェーズとは分類軸の異なる別概念です。この区別を曖昧にしたままテスト計画を進めると、「結合テスト」の範囲がチーム内でずれ、認識齟齬やテスト漏れを招きます。
だからこそ、テストレベルの正確な理解はテスト計画の出発点であり、定義と用語を事前にチームで合意しておくことがテスト漏れ防止の第一歩になります。
テストレベルの理解を土台に自チームでテスト計画を運用していくとしても、有識者が不足していると各テストレベルの計画・設計は属人化しやすく、テストの抜け漏れも起きがちです。バルテスのソフトウェアテスト支援サービスは、ISO/IEC/IEEE 29119準拠のQUINTEEメソッドで各テストレベルに応じた計画策定から実行までを一貫して支援し、属人化しがちなテスト設計を標準化されたプロセスに乗せられます。
自チームだけで計画の切り分けや抜け漏れの解消が難しいと感じたら、まずは現状のテスト計画を持ち込んで相談してみてください。
