結合テスト・総合テストで使われるテストタイプ（テストの種類）の基本

はじめに

「テスト工程はベンダー側がやってくれる」と思っていても、 その中身までは見えづらく、実際に何をどう確認しているかまでは把握できていないことも多いのではないでしょうか。

テストには、「テストタイプ」と呼ばれる確認観点や目的ごとの分類があり、それぞれのタイプが工程の中で異なる役割を担っています。

特に「結合テスト」「総合テスト」といった中〜後期の工程では、さまざまなテストタイプが組み合わされ、品質を支える重要なプロセスが実行されています。

本コラムでは、代表的なテストタイプを整理し、「どの工程で、なぜ行われるのか」をわかりやすく解説します。

結合テストと総合テストの違い

まずは、それぞれの工程の目的を整理しておきましょう。

テスト工程	主な目的
結合テスト	モジュールや機能のつなぎ目の整合性を確認。構造的なバグや連携不整合の検出
総合テスト	システム全体の業務シナリオや運用条件下での通し確認。受入に近い視点での最終検証

このように、テストの対象や視点が異なるため、工程ごとに求められるテストタイプにも違いが出てきます。

主要なテストタイプ

テストタイプとは、「何を目的に」「どのような観点で」テストを行うかという分類のことです。
ここでは、結合テストや総合テストでよく使われる代表的な7つのテストタイプを整理します。

テストタイプ	主な目的・確認内容
スモークテスト	テスト開始前に、システム全体が“最低限動作する状態”にあるかを確認します。ログインや画面表示など、ごく基本的な操作のみを対象に、テストを進められる準備が整っているかを把握するために行います。
機能テスト	仕様書や設計書に基づき、各機能が正しく動作しているかを検証します。主に正常系（想定された入力や操作）を対象とし、個々の機能の妥当性を確認します。
異常系テスト	ユーザーの誤操作や不正な入力、想定外のデータが与えられた場合に、アプリケーションが適切に対応するかを確認します。エラーメッセージ表示や異常時の制御フローなどが主な検証対象です。
リグレッションテスト	バグ修正や仕様変更後に、既存機能に副作用が出ていないかを検証します。変更による影響範囲を意識し、以前は問題なかった箇所に新たな不具合が発生していないかを重点的に確認します。
シナリオテスト	実業務に即した一連のフロー（例：受注→出荷→請求）を通しで実行し、画面や機能が連動して動作するかを検証します。業務全体の整合性をチェックするため、総合テスト工程での中心的な役割を担います。
探索的テスト	テストケースに沿わず、テスト担当者の経験や直感をもとに、仕様書や設計書に記載されていないような観点を積極的に探索するテストです。思わぬ操作や例外条件により、潜在的な不具合を発見することを目的とします。
互換性テスト	異なるブラウザ、OS、端末などで動作が変わらないかを確認します。特定の環境でのみ発生する不具合（表示崩れ、ボタンの無反応など）を洗い出し、ユーザー環境の多様性に対応できているかを評価します。

テストタイプごとのテスト実施タイミング

続いて、これらのテストタイプがどのタイミングで使われるかを整理します。
結合テスト〜総合テストにかけての進行に応じて適用時期も変わっていきます。

テストタイプ	テスト開始前	テスト初期	テスト中期	テスト後期
スモークテスト	◎	◯
機能テスト		◎	◯	△
異常系テスト		△	◎	◯
シナリオテスト		△	◯	◎
リグレッションテスト			◯	◎
探索的テスト			◎	◯
互換性テスト		△	◯	◎

◎：このテストタイプが重要かつ集中的に行われるタイミング。代表的な実施フェーズ
◯：実施されることは多いが、補完的・補助的な位置づけ。検出目的が限定的な場合もある
△：場合によっては行うこともあるが、通常は中心的ではないフェーズ

テストタイプの視点がないと起きやすい問題

テストタイプを意識せず、「とにかく動かすだけ」のテストになってしまうと、次のような問題が発生します。

• 正常系だけ確認して異常系の抜け漏れ
• 修正の影響がチェックされない
• 実業務の流れを確認しないままリリース
• 環境依存での不具合が見逃される

こうした問題は、発注側でも「なぜそれを確認するのか？」という視点を持つことで未然に防げます。

発注側が把握しておくべき観点

外部に開発を依頼する場合でも、発注側がテストタイプの意図と役割を知っておくことで、以下のようなメリットが得られます。

• 見積や工程の妥当性を判断しやすくなる
• 品質リスクを能動的に把握・管理できる
• 業務観点に沿ったテスト観点を提供できる

特に「どのテストタイプをいつ、誰が行うのか」という情報は、テスト計画の中でも要点となる部分です。
これを理解しておくことは、結果的に発注側としての品質責任を果たすことにつながります。

まとめ：テストタイプの“意図”を知ることが品質判断の第一歩

テストタイプとは、単なる作業手段ではなく、「何を防ぐために、どの段階で、どう確認するか」という品質設計の一部です。

発注側がこの意図を理解し、ベンダーと共通認識を持つことで、テスト工程のブラックボックス化を防ぎ納品物の妥当性もより明確に評価できるようになります。

まずは見積段階やテスト計画書の内容から、「どのテストタイプを実施する予定か」を確認することをおすすめします。