単体テスト・結合テスト・総合テストの違いをやさしく解説

「単体テストは終わりました。次は結合テストに入ります」という報告を受けたとき、どういう違いがあるか説明できるでしょうか。

開発現場ではテストにいくつかの種類があり、それぞれ確認する対象も目的も異なります。非エンジニアやPMがこの違いを理解しておくと、スケジュール管理や進捗報告がグッと整理されます。

この記事でわかること

ソフトウェアテストは、大きく以下の段階に分かれます。

下に行くほどテストする範囲が広くなり、より「実際の使われ方」に近い状況で確認するイメージです。

自動車の製造・検査で考えてみます。

料理でも似た構造があります。材料を個別に味見する→複数の具材を合わせた鍋を確認する→完成した料理全体を試食する→お客様に出して確認してもらう、という流れです。

単体テストは主にエンジニアが担当します。コードを書いた本人が、関数やモジュール単位で「正しい入力を与えたら正しい結果が返ってくるか」「エラー入力にちゃんと対応できるか」を確認します。

結合テストもエンジニアが中心です。APIの連携、データの受け渡し、画面と処理の連携など、「部品を組み合わせたときの動作」を確認します。「AからBにデータを渡したら、期待通りに処理された」という形で進めます。

システムテストはQAエンジニアやテスト担当者が行うことが多く、実際の業務フローを模したシナリオで確認します。「ユーザー登録して、商品を注文して、確認メールが届く」といった一連の流れを通して動作を確認します。

受け入れテストは発注者・利用者側が担います。PMや非エンジニアが主役になる工程です。仕様書に書かれていた要件が満たされているかを、実際に使ってみながら確認します。

テストの順序を飛ばしてよいと思いがち

「時間がないから単体テストは省略して結合テストを先にやろう」とすると、後で問題の原因が特定しにくくなります。単体で問題がないことを確認してから組み合わせてテストするというステップは、品質管理の基本です。

結合テストで見つかるバグが「単体テストのやり直し」だと思う

結合テストで見つかる問題の多くは、単体では問題なくても、複数の部品を組み合わせたときに初めて出てくる問題です。単体テストの品質が悪かったから、とは限りません。

「システムテスト」と「受け入れテスト」が同じだと思う

システムテストはエンジニア・QA側が行うもの、受け入れテストは発注者・利用者が行うものです。目的も担当者も異なります。どちらも「全体を確認する」という点では似ていますが、視点が違います。

テスト工程が何日で終わるかをイメージしにくい

テスト工程の期間は、バグが何件見つかるかによって変わります。バグが多く見つかれば修正と再テストで時間がかかります。プロジェクトによっては、単体～受け入れまでのテスト工程が開発工程と同じくらいの時間を占めることもあります。

進捗確認の場面では、「テストはどこまで進んでいますか」という質問だけでなく、「今は単体テスト中ですか、結合テスト中ですか」と段階を確認すると、残りの工程がより明確になります。

受け入れテストでは、「いつから実施できるか」「何営業日必要か」「承認フローはどうなっているか」を事前に確認しておくことが重要です。受け入れテストが発注者側のスケジュールに依存する場合、そこがボトルネックになることがあります。

テストの種類と流れを体系的に押さえたい方には、FEXシリーズのソフトウェアテスト入門講座がおすすめです。各テストレベルの目的と観点を、身近なたとえで整理できます。