結合テストとは？単体・システム・受入テストとの違いと流れ

結合テストとは、部品や機能をつないだときに、データや処理の受け渡しが仕様どおりに行われるかを確かめる活動です。個々の機能が単体で動いていても、画面からAPIを呼び出す場面や、登録したデータを別の機能で参照する場面では、接続したことで初めて問題が現れることがあります。

結合テストを進める際は、工程名を覚えるだけでは足りません。対象となる結合点、確認する順番、開始・完了の判断材料を整理する必要があります。この記事では、自案件で確認すべき結合点と、次工程へ進むための判断材料を整理できるようになります。

結合テストは、単体で確認した部品・機能をつなぎ、受け渡しが正しく行われるかを確認する工程です。

01Section結合テストとは：部品・機能間の接続を確認する

結合テストは、複数の部品・機能を組み合わせた状態で、相互の受け渡しを確認するテストです。ここでいうインターフェースとは、部品・機能間で「何を、どの形式で受け渡すか」を定めた取り決めを指します。

ISTQBのFoundation Levelシラバスでは、コンポーネント結合テストを、部品間のインターフェースと相互作用を確認するテストレベルとして整理しています。記事内では、部品間だけでなく外部サービスとの連携も含めて「結合テスト」と呼ぶことがありますが、どこまでを対象にするかはテスト計画で明確にします。

単体で動いても、つなぐと問題が起きる理由

単体テストでは、関数や画面部品などを比較的独立した状態で確認します。一方、結合テストでは、ある機能の出力を次の機能が正しく受け取れるか、失敗したときに適切な処理へつながるかを確認します。

たとえば、登録処理そのものが正しく動いていても、画面から渡す項目名が異なる、権限情報が引き継がれない、時間差で動く処理の完了後に一覧へ反映されない、といった問題は接続後に判明しやすいものです。入力、処理、出力だけでなく、エラー時の受け渡しも確認対象になります。

まず洗い出したい結合点

案件の結合点は、機能一覧、画面一覧、API仕様、データ項目定義、構成図を見ながら洗い出します。代表的な候補は次の5つです。

• 画面からAPIへの接続：画面操作が処理の窓口であるAPIを呼び出し、結果やエラーを表示する流れ
• APIからデータ保存先への接続：処理結果をデータベースなどの保存先へ登録・更新・取得する流れ
• 認証から各機能への接続：ログイン状態や利用者権限を、各機能が正しく利用する流れ
• 外部サービスとの接続：決済、通知、本人確認など、組織やシステムの境界を越える連携
• 時間差で実行される処理：依頼を受けた後に別の処理が動く非同期処理で、処理中・完了・失敗を引き継ぐ流れ

結合点ごとに「入力元」「渡し先」「期待する処理」「失敗時の扱い」を書き出すと、確認対象の漏れを減らせます。

02Section単体・結合・システム・受入テストの違い

工程名ではなく、何を対象にして何を確かめるかでテストレベルを区別します。

単体・結合・システム・受入テストは、理解しやすい基本モデルとして並べられることがあります。ただし、実際の工程名、実施順、反復の有無、担当範囲は、開発手法や品質方針によって異なります。名称ではなく、何を確かめたいのかで区別することが重要です。

IPA「共通フレーム2013に基づく調達管理ガイド」でも、調達工程の例として結合・統合テスト等と受入れテストは区別されています。ただし、これはすべての案件に同一の名称や順序を求めるものではありません。

結合テストとシステムテストの境界を判断する

迷ったときは、次の4点を順に確認します。

1. 1中心課題は何か：特定の画面、API、データ保存先の受け渡しが正しいかを確認するなら、結合テスト寄りです。業務全体が成立するかを確認するなら、システムテスト寄りです。
2. 2対象範囲はどこまでか：特定の連携経路を追うなら結合テスト寄りです。承認、通知、権限、運用を含めて複数機能を横断するなら、システムテスト寄りです。
3. 3主な利用資料は何か：API仕様やデータ定義が中心なら結合テスト寄り、要件定義書や業務シナリオ、非機能要件が中心ならシステムテスト寄りです。
4. 4外部サービスへ実接続するか：外部サービスとの接続を結合テストに含める場合も、システム結合テストとして独立させる場合もあります。対象環境と確認範囲を計画に記載します。

たとえば「申請画面から登録APIを呼び出し、登録データが一覧に反映されるか」は、特定経路の受け渡しを確認するため結合テスト寄りです。一方で「申請、承認、権限判定、通知、監査記録までを業務ロール別に確認する」は、全体要件の確認が中心となるためシステムテスト寄りです。

受入テストとのつながり

受入テストは、利用者や発注者の立場から、業務上の受入条件を満たしているかを確認する活動です。結合テストの完了は、受入テストや検収の完了を意味するものではありません。

受入テストで確認する業務条件を早めに把握しておくと、結合テストで重要な連携や残存課題を見落としにくくなります。受入テストの進め方は、受入テストとは？目的・進め方・テスト項目の作り方で詳しく確認できます。

03Section結合テストの進め方：対象整理から結果報告まで

結合テストでは、実施前の対象・環境・判定条件の整理と、実施後の残存リスクの申し送りを含めて管理します。

結合テストは、ケースを実行する作業だけではありません。対象を決め、環境を整え、不具合を修正・再確認し、結果と残存リスクを次工程へ申し送るまでを一連の活動として扱います。

ISTQBのテスト計画と完了条件の説明では、テスト計画に範囲、責任、リスク、開始・完了条件、環境・データ要件などを含める考え方が示されています。反復型の開発では、上記の流れを機能追加や変更の単位で繰り返すこともあります。

開始と完了は、条件・記録・判定者をセットで決める

開始条件は「何がそろえばテストを始められるか」、完了条件は「何を確認すれば、そのテスト活動を終えられるか」を示すものです。どちらも不具合件数だけで判断せず、条件、確認記録、判定者、未達時の扱いを同じ単位で定めます。

判断結果は「進める」「条件付きで進める」「追加確認後に再判定する」のように記録します。実施者、確認者、判定者、例外を承認できる人は固定ではないため、案件の体制、品質方針、契約条件に応じてテスト計画で明確にします。

テスト工程全体で、どの資料を次の活動へ渡すかを把握したい場合は、システム開発の工程と進め方も参照してください。

04Section結合点の優先順位を決める

結合点が多い場合、すべてを同じ深さ・同じ順番で確認するとは限りません。リスクに応じて優先順位を付けることで、影響の大きい連携や、確認可能な時間が限られる連携を早めに扱えます。

優先順位は、合否や必要工数を自動的に決める採点ではありません。関係者が「なぜこの連携から確認するのか」を共有するための補助です。接続先を利用できる時間、後続ケースの前提となる関係、リリース条件も加味して順番を決めます。

05Section確認観点をテストケースにする

結合テストのケースでは、「正常に動く」とだけ書くと、実施者とレビュー者で判定がずれるおそれがあります。画面、API応答、データ保存先の状態、時間差で動く処理の状態など、実際に観測できる結果へ分解して記載します。

結合点ごとに選ぶ確認観点

すべての結合点に同じ観点を当てはめるのではなく、構成とリスクに応じて選びます。主な確認観点は次のとおりです。

• インターフェース整合とデータ整合性：項目名、形式、必須・任意、更新順序、関連データ、重複の扱いが仕様と合っているか
• 正常系と異常系：想定どおりの入力に加え、入力不備、認証失敗、権限不足、連携先エラーで安全に失敗するか
• 境界・再試行・非同期処理：文字数や件数の上限、応答遅延、再送時の重複防止、処理中・完了・失敗の状態が正しいか
• 証跡と調査可能性：画面記録、リクエスト・レスポンス、ログ、データ確認結果を残せるか。機微情報を不要に記録しないか

期待結果は観測可能な状態で書く

期待結果は「正常に動く」とまとめず、画面、応答、データ、後続画面で観測できる状態に分けて記載します。

以下は、申請画面から登録APIを呼び出し、登録後に一覧へ反映する経路を確認する例です。表示文言、応答値、状態名、データ項目名は、案件仕様で定めた内容に置き換えます。

異常系では、通信失敗、権限不足、重複実行、応答遅延などから、自案件の結合点で起こり得る条件を選びます。失敗時も、利用者への表示、データの状態、再試行時の結果、調査に必要な記録を確認します。

外部連携は模擬応答と実接続を分ける

連携先を利用できない場合は、あらかじめ決めた応答を返す模擬応答で、自システム側の処理を確認できることがあります。その場合でも、どこまでを模擬応答で確認し、どこからを実接続で再確認するかをテスト計画と結果報告に残します。

06Section成果物と役割分担：次工程へ何を引き継ぐか

成果物は、単に提出するための書類ではなく、対象範囲をそろえ、実施結果を追跡し、次工程の判断を支える記録です。小規模な案件では一つの管理表にまとめることもありますが、それぞれの確認目的は分けて残します。

実施者・確認者・判定者を計画で明確にする

重要なのは、誰が実施するかだけでなく、誰が結果を確認し、誰が未解決課題を含めた移行可否を判断するかを事前に決めることです。

体制、開発方法、契約条件に応じて、テスト計画に実施者・確認者・判定者と連絡経路を明記します。

工数・期間は作業単位に分けて考える

結合テストの期間や工数は、結合点数だけでは決まりません。固定の目安を当てはめるのではなく、少なくとも次の作業単位に分けて確認します。

• 結合点の数、優先順位、変更範囲、回帰確認の対象
• 外部連携の数、同期・非同期の違い、接続先との調整
• 環境、アカウント、権限、テストデータ、ログ取得の準備
• 正常系・異常系、再試行、回復処理、実接続確認のケース設計と実施
• 不具合修正、再テスト、結果レビュー、次工程への申し送り