監修：山根一城（株式会社ポテンシャライト代表取締役CEO ／ 業界20年）
結合テストは、単体で確認済みの複数のモジュールやプログラムをつなぎ合わせ、部品同士のデータの受け渡しや呼び出しの流れが設計どおり動くかを確かめる工程です。単体テストが一つの部品の内部を見るのに対し、結合テストは部品と部品の「境界」に焦点を当てます。基本設計や詳細設計で決めたインターフェースが実装で正しく噛み合っているかを、システムテストより前の段階で洗い出す位置づけになります。
結合テストの主眼は、単体では正しく動く部品どうしをつないだときに、データや制御の受け渡しが崩れないかを確認することにあります。単体テストで一つひとつの関数や画面が仕様どおり動いても、モジュール間で渡す項目の桁数、型、必須の有無、呼び出す順番がずれていれば、つないだ瞬間に破綻します。その境界の食い違いを、システム全体を通した確認より手前で見つけるのがこの工程の役割です。
確認の対象は大きく二つに分けられます。一つは画面から入力した値がサーバ側の処理へ正しく届き、期待した結果が返るかという、機能をまたぐ流れです。もう一つは、自社システムと外部の連携先とのやり取り、たとえば他システムへ送るファイルの項目順やコード体系が取り決めどおりかという、外部インターフェースの整合です。
PMの立場では、この工程を「バグを潰す作業」ではなく「設計で決めた約束が守られているかの照合」と捉えると、確認すべき範囲を見積もりやすくなります。約束の出どころは基本設計書やインターフェース定義であり、そこに書かれた項目が結合テストの観点表の土台になります。
進め方はおおむね決まった順序をたどります。まずテストの担当者が、基本設計書やインターフェース定義をもとにテスト観点を洗い出し、どのモジュールとどのモジュールをつないで、どの入力でどの結果を期待するかを一覧にまとめます。この観点表とテストケースが最初の成果物です。
次に、確認に必要なデータを用意します。境界となる値、必須項目が欠けた値、想定外の区分値など、受け渡しがつまずきやすいパターンを含めて準備します。実行時は、まだ完成していない相手側の部品を仮の代役プログラム（スタブやドライバと呼ばれる呼び出し役・被呼び出し役）で置き換え、下から積み上げる方式か上から降ろす方式かを決めて順にテストします。
ここでのPMの仕事は、テスト実施そのものではなく段取りの管理です。連携先の担当チームと結合するタイミングをすり合わせ、テスト環境やデータの準備が間に合うかを見ます。検出した不具合は起票して修正と再確認の状態を追い、消化件数と未解決件数の推移を見ながら、次のシステムテストへ進めてよいかを判断する材料にします。
この工程で頻出するつまずきは、いくつかの典型的な形にまとまります。
これらはいずれも、実装の巧拙より段取りと設計の詰めに起因します。PMとしては、テストに入る前にインターフェースの取り決めが文書として固まっているか、相手チームと日程が合っているかを先に確かめておくと、後半の手戻りを減らしやすくなります。
結合テストは、開発の後半に並ぶいくつかの確認工程の一つで、前後との違いを押さえると全体像がつかみやすくなります。
手前にある単体テストは、一つのモジュールの内部が仕様どおりかを個別に見る工程です。結合テストはその成果を前提に、部品と部品の境界へ視点を移します。単体で見つからなかった不具合の多くが、この受け渡しの層に潜んでいます。
後ろに続くシステムテストは、つなぎ終えた全体を業務の流れに沿って通し、要件定義で求めた機能や性能が満たされているかを確認する工程です。結合テストが「設計どおり噛み合うか」という技術寄りの視点なのに対し、システムテストは「業務として成り立つか」という利用者寄りの視点になります。さらにその先に、発注側が受け入れ可否を判断する確認が控えます。
この並びを踏まえると、結合テストは設計の妥当性を実装で裏づける工程だと言えます。ここで境界の不整合を残したままシステムテストへ進むと、業務の流れを確認している最中に基礎的な受け渡しの不具合が混ざり、原因の切り分けに余計な時間がかかります。工程の境目を曖昧にしないことが、後半の混乱を抑える助けになります。
結合テストの勘どころを理解していると、PMとしてテスト計画の妥当性を自分の言葉で点検できるようになります。観点表が基本設計やインターフェース定義と結びついているか、境界の値や欠損データまで確認範囲に入っているかを見て、実施前に穴を指摘できるからです。これは上流の設計品質を後半の確認工程から逆算して評価する視点でもあり、要件定義や基本設計の議論にも活きます。
また、この工程は連携先チームとの日程調整や不具合の状態管理が要になるため、進捗を数字で捉えて判断につなげる練習の場になります。開発の後半で起きがちな手戻りの原因を段取りの側から抑えられるようになると、より上流の工程や複数チームをまたぐ役割へ広げていく足がかりになります。
結合テストと単体テストは何が違いますか。
単体テストは一つのモジュールの内部が仕様どおり動くかを個別に確かめる工程です。結合テストは単体で確認済みの部品をつなぎ、モジュール間のデータの受け渡しや呼び出しの流れが設計どおりかを見ます。見る対象が部品の中身か、部品と部品の境界かという点が主な違いです。
PMは結合テストで具体的に何を管理しますか。
テストの実施そのものより、段取りとリスクの管理が中心になります。連携先チームと結合のタイミングをすり合わせ、テスト環境やデータの準備状況を確認します。検出した不具合の消化件数と未解決件数の推移を追い、次のシステムテストへ進めてよいかを判断する材料を整えます。
スタブやドライバは何のために使いますか。
まだ完成していない相手側のモジュールを、仮の呼び出し役や被呼び出し役として代替するためのプログラムです。相手の部品が揃う前でも、境界の受け渡しを先行して確認できます。下から積み上げる方式か上から降ろす方式かによって、どちらを用意するかが変わります。