E2Eテストと結合テストの違いを解説｜単体・システムテストとの関係

E2Eテストと結合テストの違いを理解しないまま、テスト工程を進めていないでしょうか？違いを理解せずに進めてしまうと、必要なテストが抜け落ちたり、同じテストを何度も行ったりして、品質の低下や工数増大につながります。

E2Eテストと結合テストの違いを理解し、それぞれの役割と目的を整理すれば、どの工程で何を確認すべきかを明確にできます。本記事では、最初にE2Eテストと結合テストの違いを説明し、後半に単体テストやシステムテストとの関係を解説します。

E2Eテストとは何か

E2Eテストは、ユーザーが実際に行う操作の流れを実施し品質を確かめるテストです。ここでは、E2Eテストの定義、確認範囲、実施工程を解説します。

E2Eテストの概要

E2Eテスト（End to Endテスト）は、ユーザーが行う操作を起点に、処理の開始から完了までを一連の流れとして確認するテストです。画面操作だけでなく、その裏側で動くアプリケーション、API、データベース、外部サービスなどの連携までを含めて動作を確認します。

例えばECサイトでは、ログインから商品検索、購入、決済、注文完了までを通して確認します。個々の機能が正しく動いていても、連携した瞬間に不具合が起きることは珍しくありません。E2Eテストは、業務全体が利用者視点で成立するかどうかを確かめることが目的です。

E2Eテストで確認する範囲

E2Eテストで重視するのは、単体機能の正しさではなく、利用者が目的の操作を最後まで問題なく完了できるかです。実運用では、複数の機能が連続して動くため、個々の画面や処理が正しくても、つながったときに不具合が起きることがあります。

そのため、利用者の操作全体を通して品質の確認が必要です。例えば、次のような項目を確認します。

• 画面遷移が想定通りに進み、入力値が正しく引き継がれるか
• 入力必須項目や形式チェックが適切に機能しているか
• 権限によって表示内容や操作可否が正しく切り替わるか
• 外部サービス連携が失敗した場合に、適切なエラー表示がされるか
• 処理途中でエラーが起きた際に、正しく復旧・再実行できるか

E2Eテストでは、利用者が日常的に使う業務フローや操作に関連する処理、問題が出た場合に影響が大きな処理を優先し、ユーザー体験に直結する範囲に絞って確認するのが現実的です。重要な業務フローを中心に品質を確保することで、限られた工数でも実運用に耐えうるテストが行えます。

E2Eテストの実施工程

E2Eテストは、開発の初期段階ではなく、単体テストや結合テスト、システムテストで基本的な不具合を解消した後に行うのが一般的です。早い段階で実施すると、部品の不安定さが原因で失敗が多発し、どこに問題があるのかわかりにくくなります。

そのため、全体がある程度安定してから実施することが重要です。実務では、次のような順番を意識してテストを進めます。

1. 単体テストで各機能が正しく動くことを確認する
2. 結合テストで機能同士の連携に問題がないか確認する
3. システムテストで業務要件を満たしているか確認する
4. スプリントの終盤やリリース版でE2Eテストを実施する

E2Eテストでは、会員登録や決済など、重要な業務フローを優先します。そのため、単体・結合・システムテストで基本的な品質を固めておくことが重要です。E2Eテストは、リリース前の最終確認としての位置づけとなります。

E2Eテストの自動化については、以下の記事で詳しく解説しています。あわせてお読みください。

「E2Eテスト自動化の成功ステップを理解しよう」

結合テストとは何か

結合テストは、部品同士を結合した時に正しく動くかを確かめる工程です。ここでは、結合テストの定義、対象機能、実施範囲の目安を解説します。

結合テストの概要

結合テストは、複数の機能を組み合わせたときに、正しく連携して動くかを確認するテストです。

実際のシステムでは、機能同士がデータを受け渡しながら処理を進めます。そのため、機能単体が正しく動いても、受け渡し部分で不具合が発生することも少なくありません。

結合テストでは、画面・API・データベースなどのつながりに問題がないかを確認します。連携の不具合を解消しておくことで、システムテスト以降の工程で問題が発生した場合、調査や修正にかかる時間・コストを抑えられます。

対象となる機能・インターフェース

結合テストでは、複数の機能をつなぐ「インターフェース」を重点的に確認します。インターフェースとは、機能間でどのようにデータを受け渡し、処理結果を返すかを定めた部分です。

各機能が個別に正しく動作していても、データ形式や受け渡し条件の食い違いがあると、システム全体で不具合が生じます。そのため、結合テストでは機能同士の連携が設計どおりに行われているかを意識して検証します。

• 画面から送られた入力値が、正しくサーバーに伝わっているか
• 機能同士でやり取りされるデータ形式や内容が一致しているか
• APIの呼び出し結果が、想定通り返されているか
• データベースへの登録や更新が正しく反映されているか
• 外部サービス連携で通信失敗やエラー時に適切な戻り値が返るか

結合テストでは、テスト対象となるインターフェースを明確にしておくことが大切です。明確でないと、連携部分で見落としが発生してしまいます。

結合テストの実施範囲

結合テストは、すべての機能の組み合わせを確認する必要はありません。（※）重要なのは、業務で頻繁に使われる流れや、問題が起きた場合の影響が大きい連携を優先することです。

影響範囲の大きい部分を見極めてテストを実施すれば、無駄な工数を抑えながら、実運用に耐えうる品質を確保しやすくなります。例えば、次のような考え方で確認範囲を決定します。

• 日常業務で利用頻度が高い処理を優先する
• 障害が発生すると業務が停止する連携を洗い出す
• ログイン認証や注文処理、請求処理を優先対象にする
• 入力値の境界や異常なケースを含めて確認する
• 重要な連携が安定して動く状態を一つの目安とする

結合テストでは、確認範囲を広げ過ぎないことがポイントです。重要な連携が安定して動く状態を目安にすると、工数を抑えながら品質を確保できます。

※出典：IPA 情報処理推進機構「組込みソフトウェア開発における品質向上の勧め」（Page 10）

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

E2Eテストと結合テストは、どちらも機能同士のつながりを確認するテストです。しかし、狙いと役割が異なります。ここでは、E2Eテストと結合テストの目的、範囲・粒度、混同されやすい点について解説します。

①テストの目的の違い

E2Eテストと結合テストは、目的が異なります。E2Eテストは、利用者の操作が最初から最後まで成立するかを確認し、業務全体の流れに問題がないかを重視します。一方、結合テストは、機能同士が正しくつながり、データの受け渡しが想定どおり行われているかを確認する工程です。

両者の目的を整理すると、次の通りとなります。

項目	結合テスト	E2Eテスト
主な目的	機能同士の連携確認	業務全体の成立確認
重視する視点	機能・モジュール間でのデータの受け渡し	利用者の操作結果
保証したいこと	連携が正しいこと	業務が最初から最後まで完了できること

テストの目的を混同すると、必要以上にテストを増やしたり、逆に確認不足を招いたりします。結合テストとE2Eテストの役割を分けて考えることで、各工程で何を保証すべきかを明確にできます。

②テスト範囲と粒度の違い

E2Eテストと結合テストでは、検証の対象と進め方に明確な違いがあります。E2Eテストは業務の流れ全体を対象とするため、広い範囲を通して動作を確認します。これに対して結合テストでは、機能同士が連携する部分に焦点を当て、処理の受け渡しを細かく確認します。

こうした違いによって、テストの実施方法や不具合を見つけやすい箇所が変わります。代表的な相違点を以下に整理します。

項目	結合テスト	E2Eテスト
確認範囲	機能間の接点	業務フロー全体
粒度	細かい	大きい
不具合の切り分け	比較的しやすい	時間がかかりやすい

範囲と粒度の違いを理解していないと、どの工程で何をテストすべきか判断しづらくなります。結合テストで細かい問題を解消し、E2Eテストで全体の流れを確認することで、無駄の少ないテスト工程の組み立てが可能です。

③現場で混同されやすいポイント

実務では、テストの目的や定義を理解していても、実際の進め方や運用の違いを十分に整理していない場合、E2Eテストと結合テストが混同されることがあります。そこで、現場運用の観点から両者の違いを整理します。

混同されやすいポイント	結合テスト	E2Eテスト
テスト結果の使われ方	開発者の修正判断に直結	リリース可否判断の材料になりやすい
テスト設計の主担当	開発者・設計担当者	QA・テスト担当者
実施頻度	開発中に繰り返し実施	リリース前など特定のタイミングで実施

E2Eテストと結合テストを混同すると、テスト結果の扱いを巡って認識がずれる場合があります。それぞれのテストが、いつ、何の判断に使われるのかを整理しておくことで、現場での不要な議論や手戻りを抑えることが可能です。

なお、E2Eテストと結合テストが、開発工程全体の中でどのような位置づけになるのかを知っておくことも重要です。後半では、単体テストやシステムテストも含めて、各テスト工程の関係性を整理します。

開発工程全体から見た各テストの位置づけ

開発現場では、複数のテスト工程が存在し、それぞれ役割が異なります。ここでは、単体テストやシステムテストも含め、各テスト工程が開発全体の中でどのような役割と位置づけになるのかを整理します。

単体テストの役割と位置づけ

単体テストは、プログラムを構成する最小単位の機能が、設計通りに動作するかを確認する工程です。処理単位が小さいため、不具合が起きても原因を特定しやすく、修正の影響範囲も限定できます。

この段階で基本的な動作を固めておくことで、後工程で問題が連鎖的に広がるのを防ぎます。下表は、単体テストの役割と、位置づけをまとめたものです。

項目	単体テストの内容
役割	各プログラム部品が仕様どおりに動くことを保証する
位置づけ	開発初期に実施し、後工程の土台となる工程

単体テストは、後続の結合テストやシステムテストの品質を左右する基礎工程です。ここで動作の正しさを確認しておくことで、連携不具合の切り分けがしやすくなります。

※出典：IT用語辞典 e-Words「単体テスト【UT】Unit Testing」

結合テストとシステムテストの役割の違い

結合テストとシステムテストは、確認対象と目的が異なります。結合テストは、複数の機能が正しくつながり、データの受け渡しが問題なく行われるかを確認するテストです。一方、システムテストは、完成したシステム全体が業務や利用者の要件を満たしているかを確認します。

それぞれのテストの役割と位置づけを比較すると、以下の通りになります。

項目	結合テスト	システムテスト
役割	機能同士の連携が正しいことを保証する	業務要件が満たされていることを保証する
位置づけ	単体テストの後、連携確認として実施	結合テストの後、全体確認として実施

結合テストとシステムテストの違いを理解することで、確認内容の重複や抜け漏れを防ぎやすくなります。その結果、効率的なテスト計画を立てることが可能となります。

※出典：IT用語辞典 e-Words「結合テスト【integration testing】IT」
※出典：IT用語辞典 e-Words「システムテスト【system testing】総合テスト」

E2Eテストの必要性と位置づけ

E2Eテストは、すべてのシステムに必須の工程ではありません。対象範囲が広く、準備や実行に多くの時間を要するため、作業負担が大きくなりがちです。一方で、障害が発生した際に業務全体へ深刻な影響を及ぼす処理が含まれる場合には、リスクを抑える目的で実施する価値があります。

E2Eテストの必要性と位置づけを、下表にまとめています。

項目	E2Eテストの内容
必要性	業務停止や重大影響が想定される処理がある場合に実施
位置づけ	結合・システムテスト後の最終確認として実施
対象範囲	重要な業務フローに限定して行う

E2Eテストは、必須ではなく、目的に応じて実施を選択する工程です。決済や契約など、重要な部分に実施範囲を絞ることで、工数を抑えながら品質を確保する方法が良いでしょう。

まとめ

本記事では、E2Eテストと結合テストの違いを中心に、それぞれが何を確認し、どの品質を保証する工程なのかを整理しました。

E2Eテストは、利用者の操作が業務として最後まで成立するかを確認する工程であり、結合テストは、機能同士の連携が正しく行われているかを確認する工程です。両者は目的と役割が異なるため、代替関係ではありません。

それぞれのテストの違いを理解したうえで、影響の大きい業務フローに絞ってE2Eテストを設計・運用するのが、品質と工数のバランスを取るポイントとなるでしょう。

また、重要な業務フローを継続的に確認する場合には、テスト自動化ツールを活用することで運用負荷を抑えることも可能です。

誰でもカンタンにテスト自動化ができる時代は、すぐそこまできています。当サイトでは、テスト自動化ツールに興味のある方へ、「テスト自動化　推進ガイドブック」と「テスト自動化ツールT-DASH 基本ガイドブック」のダウンロード資料をご用意しております。ぜひダウンロードいただき、資料をご覧ください。

またテスト自動化ツール「T-DASH」を無料でトライアル利用できる環境もご用意しています。ぜひ、お試しいただき、ツールを活用したテスト自動化に挑戦してみてください。