結合テスト仕様書の作り方｜項目例と単体との違い

単体テストは各エンジニアが書けているのに、モジュールをつなぎ始めた途端にバグが噴き出す。結合テストの段階で「誰が」「どこまで」「何を確認するのか」が曖昧なまま進み、リリース直前に手戻りが発生する。受託開発の現場では、こうした結合フェーズの混乱がスケジュールを崩す典型的な原因になっています。

その混乱の多くは、結合テスト仕様書が整っていないことに起因します。仕様書がなければ、テストの範囲も観点も担当者の頭の中にしかなく、抜け漏れが起きても気づけません。

この記事では、そのまま流用できるテンプレート構成を軸に、結合テスト仕様書の作り方を項目例つきで解説します。単体テスト仕様書との違い、テストケースの書き方、テスト観点の洗い出し方までを一気通貫でまとめました。読み終えたその日から、自社の結合テスト仕様書の骨組みを作り始められることを目標にしています。

結合テスト仕様書とは何か｜単体テスト仕様書との違い

結合テスト仕様書とは、複数のモジュールや機能を組み合わせたときに、そのつなぎ目（インターフェース）が正しく動くことを確認するためのテスト計画とテストケースをまとめた文書です。単体テストが「部品単体の正しさ」を見るのに対し、結合テストは「部品と部品の連携の正しさ」を見ます。

この目的の違いが、そのまま仕様書の中身の違いになります。単体テスト仕様書は関数やクラスの入出力に焦点を当てますが、結合テスト仕様書はデータの受け渡し・呼び出し順序・境界をまたぐ例外処理に焦点を当てます。

『単体テストの考え方／使い方』の著者Khorikovは、結合テストの役割を「単体テストで網羅できない部分を埋めるもの」と位置づけ、退行に対する保護が強い一方で実行時間と保守コストが高いというトレードオフを指摘しています。だからこそ、結合テストはクリティカルパスを中心に厳選し、仕様書で範囲を明示することが重要になります。

単体テスト仕様書と結合テスト仕様書の違いを整理すると、次のようになります。

比較項目	単体テスト仕様書	結合テスト仕様書
検証対象	関数・クラス・メソッド単体	モジュール間・機能間の連携
主な観点	入出力・分岐・境界値	インターフェース・データ整合性・呼び出し順序
前提条件	モックやスタブで依存を遮断	実際の連携先や近い環境を使う
主な担当	実装したエンジニア	実装者＋テスト担当・PM
バグの典型	ロジックの誤り	引数の型不一致・NULL連携・状態の引き継ぎ漏れ

このように、両者は似て非なる文書です。単体テスト仕様書の作り方については単体テスト仕様書テンプレートの基本構成を確認すると、結合版との差分がより明確になります。まずは「連携を見る文書である」という前提を、チーム内で共有しておきましょう。

なお、結合テストそのものの進め方に不安がある場合は、結合テストの基本と実践を体系的に押さえることをおすすめします。仕様書はあくまでテストを実行するための道具であり、テストの目的を理解していないと形だけの文書になってしまうためです。

結合テスト仕様書の作り方｜全体の流れを5ステップで整理

いきなりテンプレートの空欄を埋め始めると、観点の抜け漏れや粒度のばらつきが起きます。結合テスト仕様書の作り方は、次の5ステップで進めると全体像を保ちながら作成できます。

1. テスト範囲とテスト方式の決定：どのモジュール間を、どの順序（トップダウン／ボトムアップ／サンドイッチ）で結合するかを決める
2. テスト観点の洗い出し：連携で起こりうる不具合を観点として列挙する
3. テストケースの設計：観点ごとに、入力・操作・期待結果を具体化する
4. 仕様書への落とし込み：計画部とテストケース部をテンプレートに沿って記述する
5. レビューと合意：PM・実装者・テスト担当で内容を確認し、抜け漏れをつぶす

この順序で進めるポイントは、テストケースを書く前に観点を固めることです。観点なしにケースから書き始めると、思いついた項目だけを並べる「気づき依存」の仕様書になり、レビューでも抜けを発見できません。

ステップ1の「範囲・方式の決定」では、どのモジュールから結合していくかを図で描くのが有効です。上位モジュールから順に結合するトップダウン、下位から積み上げるボトムアップ、両者を組み合わせるサンドイッチのいずれを採るかで、必要になるスタブやドライバの量が変わります。受託開発では連携先の準備状況に左右されるため、「決済APIは後半に結合する」といった順序も、この段階で仕様書に書き残しておきます。

ステップ2からステップ3への移行では、観点を「点」で終わらせず、正常系・境界値・異常系という3つの角度でケースに展開します。1つの連携経路につき最低でも「正常に通るケース」「境界の値を渡すケース」「連携先が失敗するケース」の3本を用意すると、粒度が安定します。

ステップ5のレビューは、形式的な読み合わせで終わらせないことが肝心です。実装者に「この連携で過去にハマった箇所はないか」を必ず聞き、その経験を観点として追加します。ここで拾えた1件が、本番障害1件の予防につながることも珍しくありません。

各ステップの成果物と担当を整理すると、次のとおりです。

ステップ	主な成果物	主担当	目安工数
1. 範囲・方式決定	結合方式図・対象一覧	PM	0.5〜1日
2. 観点洗い出し	テスト観点リスト	テスト担当＋実装者	1〜2日
3. ケース設計	テストケース一覧	テスト担当	2〜4日
4. 仕様書化	結合テスト仕様書	テスト担当	1〜2日
5. レビュー・合意	レビュー記録	全員	0.5日

※工数はあくまで中規模の1機能群を想定した目安の例です。案件の規模や連携先の数に応じて調整してください。

仕様書作成を「テストケースを書く作業」だと捉えると失敗します。本質は、テスト範囲と観点を関係者で合意するプロセスです。テスト全体の位置づけを設計するテスト計画書の作成ステップとあわせて進めると、単体・結合・システムの各工程が矛盾なくつながります。

結合テスト仕様書テンプレートの基本構成と必須項目

結合テスト仕様書は、大きく「計画部（ヘッダー情報）」と「テストケース部（明細）」の2ブロックで構成します。国際的にはテストドキュメントの標準としてISO/IEC/IEEE 29119が存在し、その源流であるIEEE 829では、テスト計画書・テスト設計仕様書・テストケース仕様書・テスト手順書といった文書群が定義されています。とはいえ、中小規模の受託開発でこれらをフルセットで作る必要はありません。実務では計画部とテストケース部を1つの仕様書にまとめ、必要十分な項目に絞るのが現実的です。

まず、計画部に含めるべき必須項目は次のとおりです。

項目	記載内容の例	目的
文書管理情報	文書ID・版数・作成日・作成者・承認者	版管理と責任の明確化
対象システム・機能	対象の機能群・モジュール名	テスト範囲の明示
テストの目的	連携の何を確認するか	目的のブレ防止
結合方式	トップダウン／ボトムアップ／サンドイッチ	実施順序の共有
テスト環境	OS・ミドルウェア・接続先・データ	再現性の確保
前提条件	単体テスト完了・スタブ準備状況	開始判定
合否基準	全ケースPass・重大不具合0件 等	終了判定の客観化
スケジュール	開始・終了予定	進捗管理

次に、テストケース部（明細）に含めるべき必須項目です。こちらが仕様書の中核になります。

項目	記載内容の例
テストケースID	IT-001 のような一意な番号
テスト観点	インターフェース／業務シナリオ／異常系 等
対象インターフェース	画面A→API B→DB C の連携経路
前提条件	事前データ・ログイン状態など
テスト手順	操作・入力の具体的なステップ
入力データ	具体的な値（正常値・境界値・異常値）
期待結果	画面表示・DB更新・戻り値の期待状態
実施結果	Pass／Fail／保留
不具合ID	不具合票との紐付け番号
実施日・実施者	記録用

テストケースIDの採番にも一工夫あると運用が楽になります。「IT-001」のような連番だけでなく、機能や観点が分かる接頭辞を付けると、後から特定のグループだけを抽出しやすくなります。たとえば「IT-LOGIN-001（ログイン連携の1番目）」「IT-PAY-ERR-003（決済連携の異常系3番目）」のように、機能・観点・連番を組み合わせる方式です。件数が数百に達する結合テストでは、この命名規約の有無が集計効率を大きく左右します。

版管理も軽視できません。仕様変更のたびに版数を上げ、更新履歴に「いつ・誰が・どこを・なぜ変えたか」を1行で残すだけで、古い仕様書でテストしてしまう事故を防げます。文書管理情報の欄は、単なる形式ではなく品質を守る仕組みだと捉えてください。

テスト技法の解説で知られるCopelandによれば、あらかじめ手順と期待結果を文書化しておくスクリプトテストの利点は、再現性・客観性・監査性にあります。同氏は、テストケース仕様書を「作成者以外が実行しても同じ方法で実行でき、要件からテストケースへのトレーサビリティが取れるもの」と説明しています。受託開発では、この監査性がクライアントへの品質説明にもそのまま使えます。テストの結果報告を求められたとき、仕様書とテストケースの一覧がそのままエビデンスになるためです。

期待結果を「正常に動作すること」で済ませないことが、テンプレート運用で最も差が出るポイントです。「画面Aに登録した内容が、DB CのUSERテーブルに1件INSERTされ、画面Bの一覧に表示される」というレベルまで具体化して初めて、テスト担当者が判断に迷わなくなります。

結合テスト項目（テストケース）の書き方と記載例

テンプレートの器が用意できたら、次はテストケース（結合テスト項目）の中身です。ここでは代表的な3つの観点について、具体的な記載例を示します。

結合テストで押さえるべき観点は、大きく次の3種類に分けられます。

• インターフェーステスト：モジュール間で受け渡されるデータが、型・桁・項目の対応どおりに連携されるか
• 業務シナリオテスト：一連の業務フロー（例：申込→承認→通知）が、複数機能をまたいで正しく完結するか
• 異常系・例外連携テスト：連携先がエラーを返す・タイムアウトする・NULLが渡るといった異常時に、適切に処理されるか

これらを実際のテストケースに落とすと、たとえば次のような記載になります。

ID	観点	対象連携	テスト手順（要約）	入力データ	期待結果
IT-001	インターフェース	登録画面→登録API→DB	必須項目を入力し登録	氏名=山田太郎, 年齢=30	DBのUSERに1件INSERT、IDが採番される
IT-002	インターフェース（境界値）	登録画面→登録API→DB	桁数上限で登録	氏名=全角50文字	正常に登録され、50文字が欠落なく保存される
IT-003	業務シナリオ	申込→承認→通知	申込後、管理者が承認	申込1件を承認	ステータスが「承認済」に更新、申込者へ通知メール送信
IT-004	異常系	決済画面→外部決済API	決済APIがタイムアウト	応答遅延を発生	エラー画面を表示し、注文は未確定のまま保持される
IT-005	異常系（NULL連携）	検索画面→検索API	任意項目を空で検索	条件なしで検索	全件表示、システムエラーが発生しない

このように、1つの観点に対して正常系・境界値・異常系を意識してケースを分割すると、抜け漏れが減ります。とくに受託開発では、外部システムやクライアント側APIとの連携が絡むことが多く、IT-004のような異常系連携が本番障害の火種になりがちです。

Khorikovが指摘するように、外部APIのような「管理下にない依存」はモック化して単体テストで確認し、結合テストでは自前のDBのような「管理下にある依存」を実物で確認するという役割分担も有効です。結合テストで何を実物に置き換え、何をスタブで代替するかを仕様書に明記すると、環境起因の判定ブレを防げます。

具体的なイメージを持てるよう、IT-003の業務シナリオを例に、テストケースの中身をもう一段掘り下げてみます。「申込→承認→通知」というフローでは、次のように手順・入力・期待結果を段階的に記述します。

• 前提条件：申込者アカウントと承認者アカウントが登録済みで、通知メールの送信設定が有効になっている
• 手順1：申込者が申込フォームに必要事項を入力し、送信する
• 期待結果1：申込データがDBに登録され、ステータスが「申請中」になる
• 手順2：承認者が管理画面で当該申込を開き、「承認」を押す
• 期待結果2：ステータスが「承認済」に更新され、更新日時と承認者IDが記録される
• 手順3：承認処理の完了を契機に、申込者へ通知メールが送信される
• 期待結果3：申込者のメールアドレス宛に、承認完了を知らせるメールが1通届く

このように、1つの業務シナリオを複数の手順と期待結果に分解すると、どの連携でつまずいたのかを切り分けやすくなります。もし「承認はできたが通知が届かない」という結果になれば、承認処理とメール送信処理のつなぎ目に問題があると即座に特定できます。逆に、期待結果を「申込が承認されること」の一言で済ませていると、どこで失敗したのかを追う手がかりが残りません。

書き方に迷ったら、システムテストとの境界も意識しておきましょう。連携の正しさは結合テスト、システム全体としての要件充足はシステムテストが担当します。両者の切り分けはシステムテストと結合テストの違いを整理すると明確になります。

テスト観点の洗い出しで抜け漏れを防ぐ

テストケースの質は、その前段にある「テスト観点の網羅性」で決まります。観点が漏れていれば、どれだけ丁寧にケースを書いても、その領域のバグは永遠に見つかりません。結合テストで漏れやすい観点を、チェックリストとして持っておくと有効です。

結合テストで見落としやすい観点の例を挙げます。

• データ型・桁・フォーマットの不一致：送信側と受信側で日付形式や数値桁が食い違わないか
• 必須／任意・NULLの扱い：任意項目が未入力のときに連携先が落ちないか
• 文字コード・全角半角：連携をまたいで文字化けや切り捨てが起きないか
• トランザクション整合性：連携の途中で失敗したときにデータが中途半端に残らないか
• 状態遷移の引き継ぎ：前機能で設定したステータスが次機能に正しく伝わるか
• 同時実行・排他制御：複数ユーザーが同じデータを操作したときに競合しないか
• タイムアウト・リトライ：外部連携が遅延したときの挙動が定義どおりか
• 権限・認可の連携：権限のないユーザーが連携経由で操作できてしまわないか

これらを毎回ゼロから考えるのは非効率です。過去案件の観点を蓄積し、テンプレート化して再利用することで、担当者のスキルに依存しない一定の網羅性を確保できます。観点を体系的に洗い出す手順はテスト観点の洗い出しテクニックを取り入れるで詳しく解説しています。

観点リストは「一度作って終わり」ではなく、本番で発生した障害を観点として追記し続ける生きた資産にすることが理想です。障害の再発防止が、そのまま次のプロジェクトの品質底上げにつながります。

観点の優先順位づけには、次のような簡易マトリクスも役立ちます。

影響度＼発生頻度	高い	低い
大きい（業務停止・金銭事故）	最優先で網羅	重点的に確認
小さい（軽微な表示崩れ等）	標準的に確認	余力に応じて確認

限られた工数の中では、すべての観点を同じ濃度でテストすることはできません。影響度と発生頻度でメリハリをつけ、クリティカルな連携から仕様書に落とし込みましょう。左上の「影響度が大きく発生頻度も高い」領域は、金銭事故や業務停止に直結するため、正常系だけでなく異常系まで厚くテストします。一方、右下の「影響度が小さく発生頻度も低い」領域は、工数に余力があるときに確認する程度で構いません。

このメリハリを言語化しておくと、クライアントや上長に対して「なぜここを重点的にテストするのか」を費用対効果の観点で説明できます。テスト工数の妥当性を問われたとき、観点マトリクスは根拠資料としても機能します。限られた予算のなかで品質を最大化する意思決定を、感覚ではなく基準で示せるようになるのは大きな利点です。

結合テスト仕様書の作り方でつまずく落とし穴と対策

最後に、実際に結合テスト仕様書の作り方を実践する際につまずきやすいポイントと、その対策を整理します。テンプレートを配っただけでは品質は上がりません。運用でよくある失敗を先回りして潰しておきましょう。

現場で頻発する落とし穴と対策は次のとおりです。

よくある落とし穴	何が起きるか	対策
期待結果が曖昧	判定が担当者の主観になりPassの基準がブレる	DB・画面・戻り値まで具体化する
単体テストと重複	同じ確認を二度行い工数が膨らむ	結合は「連携」に絞り、ロジックは単体に任せる
異常系が手薄	本番で連携エラー時に障害化	観点リストで異常系を必須項目にする
環境条件の記載漏れ	「自分の環境では動いた」問題が多発	テスト環境・データ・接続先を計画部に明記
版管理がない	古い仕様書でテストしてしまう	文書ID・版数・更新履歴を必ず付ける
粒度がバラバラ	人によってケースの詳細さが違う	記載例を1つ用意し、粒度の基準にする

とくに多いのが、単体テストとの重複による工数の膨張です。結合テスト仕様書に単体レベルの分岐網羅まで書き込んでしまうと、テストケースが数倍に膨れ、レビューも実施も回らなくなります。「ロジックの正しさは単体、連携の正しさは結合」という役割分担を、チーム全員で徹底することが対策になります。

判断に迷ったときは、「このケースが失敗したら、原因は1つのモジュール内で完結するか、それとも複数モジュールのつなぎ目にあるか」を自問してみてください。前者なら単体テストで、後者なら結合テストで扱うべきケースです。この問いを基準にするだけで、重複の大半は整理できます。

もう1点、見落とされがちなのがテストデータの準備不足です。結合テストでは、連携先に事前登録しておくべきマスタデータや、特定の状態にしておくべきレコードが必要になります。仕様書の前提条件欄に「どのデータが、どの状態で存在している必要があるか」を書いておかないと、テスト当日に環境を作れず着手が遅れます。データ準備も仕様書の一部だと考えておきましょう。

もう1つの典型が、仕様書が実態に追いつかないことです。仕様変更が入ったのに仕様書を更新せず、テスト時に「仕様書と画面が違う」という事態に陥ります。仕様変更が入ったら、まず結合テスト仕様書の該当ケースを更新するルールを決めることで、文書と実装の乖離を防げます。

なお、仕様書のフォーマットは凝りすぎないことも大切です。IPAが公開するソフトウェア開発分析データ集（IPA）のような公的データを参考にしつつも、自社の規模に合わない重厚な様式を持ち込むと、作成も更新も続かなくなります。まずは必須項目だけの軽量版から始め、運用しながら育てるのが長続きのコツです。テスト技法の標準的な考え方はJSTQB（日本ソフトウェアテスト技術者資格認定委員会）のシラバスも参考になります。

FAQ｜結合テスト仕様書に関するよくある質問

現場で寄せられることの多い疑問を、以下の観点でまとめました。自社の状況に近いものから読んでみてください。

• 適切な分量とフォーマットの選び方
• 単体テスト仕様書との使い分け
• アジャイル開発やレビュー体制での運用
• 外部システム連携が絡む場合の進め方

Q. 結合テスト仕様書はどのくらいの分量が適切ですか？ A. 案件規模によりますが、計画部はA4で1〜2枚、テストケース部は連携経路と観点の数で決まります。分量よりも「連携の重要な経路と異常系が網羅されているか」を基準にしてください。厚さより網羅性です。

Q. Excelとテスト管理ツールのどちらで作るべきですか？ A. 小規模ならExcelでも十分機能します。ただし、複数人での同時編集や不具合票との連携が増えるなら、テスト管理ツールへの移行を検討する価値があります。まずは項目の型を固め、後からツールに載せ替える順序が安全です。

Q. 単体テスト仕様書があれば結合テスト仕様書は不要では？ A. 別物なので必要です。単体は部品の正しさ、結合は連携の正しさを見ます。単体がすべてPassでも、つなぎ目のデータ不整合や状態引き継ぎの漏れは結合テストでしか検出できません。

Q. アジャイル開発でも結合テスト仕様書は作りますか？ A. 作り方は変わりますが、連携の観点を整理する価値は変わりません。フルの仕様書ではなく、受け入れ基準と連携チェックリストを軽量に運用する形が現実的です。イテレーションごとに更新することを前提にしましょう。

Q. 結合テスト仕様書のレビューは誰が行うべきですか？ A. 実装者・テスト担当・PMの3者が関わるのが理想です。実装者は連携の実態を、テスト担当は観点の網羅性を、PMはスケジュールと合否基準の妥当性を確認します。役割ごとに見る視点が違うため、1人だけのレビューでは抜けが残りやすくなります。

Q. 外部システムとの連携が相手都合で結合テストできないときはどうしますか？ A. スタブ（模擬の連携先）を用意して先に自社側の処理を確認し、実機での連携は別ケースとして切り出します。その際、仕様書に「スタブでの確認」「実機での確認」を明記し、どちらが済んでいるかを管理してください。実機確認が残っている状態でリリース判断をしないことが重要です。

まとめ｜テンプレート化で結合フェーズの混乱をなくす

結合テスト仕様書は、複数のモジュールをつなぐ工程で「誰が・どこまで・何を確認するか」を明確にするための道具です。単体テスト仕様書との違いを押さえ、計画部とテストケース部の必須項目をテンプレート化し、観点の洗い出しで抜け漏れを防ぐ。この流れを型として持てば、案件が変わっても一定の品質でテストを設計できます。

要点を振り返ります。

• 結合テストは「連携の正しさ」を見る工程で、単体テストとは目的も観点も異なる
• 作成は「範囲・方式→観点→ケース→仕様書化→レビュー」の5ステップで進める
• 計画部（管理情報・環境・合否基準）とテストケース部（観点・手順・期待結果）を必須項目で構成する
• 期待結果はDB・画面・戻り値まで具体化し、異常系連携を必ず盛り込む
• 観点リストは障害を追記し続ける生きた資産として育てる

完璧な様式より、チームが継続して更新できる軽量なテンプレートのほうが、現場では品質に効きます。まずは必須項目だけの骨組みから始め、案件を重ねながら自社の型に育てていきましょう。

結合テストは、単体テストとシステムテストのあいだにあって見過ごされがちな工程ですが、モジュール同士のつなぎ目こそが本番障害の温床になりやすい場所です。そこを仕様書で可視化し、観点とケースを言語化しておくことは、リリース直前の手戻りを減らし、納期と品質を両立させる最も費用対効果の高い投資の1つだと言えます。今日つくる1枚のテンプレートが、次の案件のトラブルを未然に防ぎます。

テスト体制の見直しや、結合フェーズの品質を担保する仕組みづくりを検討されている方は、テスト体制の課題整理について相談するところから始めてみてください。現状の進め方を棚卸しするだけでも、次の一手が見えてきます。