「単体テストは終わりました。次は結合テストに入ります」
開発チームからこのように報告されたとき、単体テストと結合テストの違いを説明できるでしょうか。
システム開発では、テスト工程がいくつかの段階に分かれています。
代表的なものが、次の4つです。
- 単体テスト
- 結合テスト
- システムテスト
- 受入テスト
名前は聞いたことがあっても、初心者や非エンジニアにとっては、どのテストで何を確認するのか、誰が担当するのか、PMとして何を見ればよいのかが分かりにくいものです。
この違いを曖昧にしたまま進捗確認をすると、次のような問題が起きます。
「テスト中です」と聞いて安心したが、実はまだ単体テストだった
結合テストで大量の不具合が出て、スケジュールが崩れた
受入テストの日程を顧客と調整しておらず、リリース前に詰まった
テスト完了の意味が人によって違い、リリース判断で揉めたこの記事では、単体テスト・結合テスト・システムテスト・受入テストの違いを、初心者向けに整理します。
この記事で分かること
この記事では、次の内容を扱います。
| 分かること | 内容 |
|---|---|
| テスト工程の全体像 | 単体・結合・システム・受入の流れが分かる |
| 各テストの違い | 何を対象に、何を確認するのかが分かる |
| 誰が担当するか | エンジニア、QA、PM、顧客の役割が分かる |
| PMが見るべきポイント | 進捗・品質・リリース判断で確認する観点が分かる |
| よくある誤解 | 「テスト中」の意味を取り違えないようになる |
| 進捗確認の質問例 | 実務で使える確認フレーズが分かる |
単体テスト・結合テスト・システムテスト・受入テストの違い
ソフトウェアテストは、ざっくり言うと、小さい単位から大きい単位へ確認範囲を広げていく工程です。
| テスト種別 | 確認する範囲 | 主な目的 | 主な担当 |
|---|---|---|---|
| 単体テスト | 関数、クラス、画面部品、モジュール | 部品単体が正しく動くか確認する | エンジニア |
| 結合テスト | 複数の部品・画面・API・DB連携 | 部品同士をつないだときに正しく動くか確認する | エンジニア、QA |
| システムテスト | システム全体 | 業務フロー全体として要件を満たすか確認する | QA、テスト担当 |
| 受入テスト | 利用者・発注者視点の業務確認 | 発注者・利用者が使って問題ないか判断する | 顧客、業務部門、PM |
イメージとしては、次のような流れです。
単体テスト
↓
結合テスト
↓
システムテスト
↓
受入テスト下に行くほど、確認範囲は広くなります。
そして、実際の利用場面に近づいていきます。
身近な例で理解するテスト工程
自動車の製造・検査で考えると、テスト工程の違いは分かりやすくなります。
| テスト種別 | 自動車でたとえると |
|---|---|
| 単体テスト | エンジン、ブレーキ、ライトなどの部品単体を確認する |
| 結合テスト | エンジンとトランスミッション、ブレーキと制御装置を組み合わせて確認する |
| システムテスト | 完成した車を試験コースで走らせ、全体の動きを確認する |
| 受入テスト | 購入者や利用者が試乗して、期待どおりか確認する |
料理でも同じです。
単体テスト：材料やソースを個別に味見する
結合テスト：具材を合わせた状態で味や火の通りを確認する
システムテスト：完成した料理全体として味や見た目を確認する
受入テスト：お客様に出して問題ないか確認するこのように、テストは「最後にまとめて確認するもの」ではありません。
段階ごとに、確認する範囲と目的が違います。
単体テストとは
単体テストとは、プログラムの部品を一つずつ確認するテストです。
英語では Unit Test と呼ばれます。
たとえば、次のような単位を確認します。
- 関数
- クラス
- モジュール
- 画面部品
- 入力チェック処理
- 計算処理
- APIの一部処理
単体テストの目的は、部品単体として正しく動くか を確認することです。
たとえば、消費税を計算する処理なら、次のようなことを確認します。
| 確認項目 | 例 |
|---|---|
| 通常ケース | 1,000円なら税込1,100円になる |
| 境界値 | 0円、1円、大きな金額でも正しく計算される |
| 異常ケース | 数値以外が入力されたときにエラーになる |
| 端数処理 | 小数点や四捨五入のルールに従っている |
単体テストは、主にエンジニアが担当します。
PMや非エンジニアが細かいコードレベルまで理解する必要はありません。
ただし、単体テストが終わっていない状態で結合テストに入ると、後で原因特定が難しくなることは理解しておきましょう。
結合テストとは
結合テストとは、複数の部品を組み合わせたときに、正しく動くかを確認するテストです。
英語では Integration Test と呼ばれます。
単体では問題なく動いていても、組み合わせたときに問題が出ることがあります。
たとえば、次のような確認です。
| 確認対象 | 確認すること |
|---|---|
| 画面とAPI | 画面から送ったデータがAPIで正しく処理されるか |
| APIとDB | APIがDBから正しくデータを取得・更新できるか |
| 複数画面 | 登録画面で登録したデータが一覧画面に表示されるか |
| 外部連携 | 外部サービスへ正しい形式でデータを送れるか |
| 権限連携 | ユーザー権限に応じて表示・操作が変わるか |
結合テストでは、インターフェースのズレがよく見つかります。
たとえば、
画面側は「customerName」という項目名で送っている
API側は「clientName」という項目名を期待しているこのようなズレは、単体テストでは見つからないことがあります。
そのため、結合テストで見つかるバグは、単体テストのやり直しというより、つなぎ目の確認で初めて見える問題 と考えるとよいです。
システムテストとは
システムテストとは、システム全体を通して、要件や仕様を満たしているかを確認するテストです。
総合テストと呼ばれることもあります。
単体テストや結合テストよりも、実際の業務フローに近い形で確認します。
たとえば、ECサイトなら次のような流れです。
ユーザー登録する
↓
商品を検索する
↓
カートに入れる
↓
注文する
↓
決済する
↓
注文確認メールが届く
↓
管理画面で注文を確認するこの一連の流れが、システム全体として正しく動くかを確認します。
システムテストでは、次のような観点を見ます。
| 観点 | 確認すること |
|---|---|
| 業務フロー | 実際の利用手順に沿って動くか |
| 仕様整合 | 仕様書どおりに動くか |
| 権限 | ユーザー種別ごとの表示・操作が正しいか |
| 例外処理 | エラー時や想定外入力時に適切に動くか |
| 性能 | 画面表示や処理速度に問題がないか |
| 運用 | ログ、通知、管理画面などが使えるか |
システムテストは、QAエンジニアやテスト担当者が中心になることが多いです。
ただし、PMも進捗、残バグ、リリース影響を確認する必要があります。
受入テストとは
受入テストとは、発注者や利用者が、システムを受け入れてよいか確認するテストです。
英語では UAT（User Acceptance Testing）と呼ばれます。
受入テストの主役は、開発チームではなく、発注者・利用者側です。
目的は、単にシステムが動くかどうかではありません。
業務で使えるか
要件を満たしているか
受け入れてよい状態かを確認することです。
たとえば、次のような観点で確認します。
| 観点 | 確認すること |
|---|---|
| 業務適合 | 実際の業務手順で使えるか |
| 要件充足 | 合意した要件を満たしているか |
| 操作性 | 利用者が迷わず使えるか |
| 帳票・出力 | 必要な帳票やデータが出せるか |
| 承認 | 業務責任者が利用開始を認められるか |
| 残課題 | 本番利用前に解消すべき課題がないか |
受入テストは、PMにとって非常に重要です。
なぜなら、顧客や業務部門のスケジュールに強く依存するからです。
受入テスト担当者が忙しく、確認できる日が限られている場合、そこがリリース前のボトルネックになります。
テスト工程ごとの違いを一覧で整理する
ここまでの内容を一覧にすると、次のようになります。
| テスト種別 | 確認対象 | 主な観点 | よく見つかる問題 | PMが見るべきこと |
|---|---|---|---|---|
| 単体テスト | 部品単体 | 入力・出力・例外処理 | 計算ミス、条件分岐ミス | 完了基準、未実施範囲 |
| 結合テスト | 部品同士の連携 | API、DB、画面連携 | 項目名ズレ、データ受け渡しミス | 連携不具合、後続影響 |
| システムテスト | システム全体 | 業務フロー、仕様整合 | 業務シナリオ上の不具合 | 残バグ、リリース影響 |
| 受入テスト | 利用者視点 | 業務で使えるか、要件充足 | 期待値ズレ、操作性問題 | 顧客確認日程、承認条件 |
この表を押さえておくと、「今どの段階のテストなのか」「次に何が残っているのか」を把握しやすくなります。
テスト種別だけでなく、品質確認の基本を体系的に学びたい方へ
単体テスト・結合テスト・受入テストの違いを理解しても、実務ではテスト観点、バグ票、再テスト、リリース判断までつながります。
ソフトウェアテストの基本を学びたい方は、関連講座も確認してください。
ソフトウェアテスト入門の講師クーポン対象講座を見る
初心者がつまずきやすいポイント
テストの順序を飛ばしてよいと思ってしまう
時間がないからといって、単体テストを省略して結合テストへ進むのは危険です。
単体で問題がある状態で組み合わせてしまうと、問題が起きたときに原因を特定しにくくなります。
部品が悪いのか
つなぎ方が悪いのか
データが悪いのか
環境が悪いのかが分からなくなるからです。
結合テストで見つかるバグを「単体テスト漏れ」と決めつける
結合テストでは、単体では見えない問題が出ます。
たとえば、APIの項目名、データ形式、権限、外部サービスとの接続などです。
そのため、結合テストでバグが出たからといって、必ずしも単体テストが悪いとは限りません。
重要なのは、どの段階で見つかるべき問題だったのかを冷静に見ることです。
システムテストと受入テストを同じだと思ってしまう
システムテストと受入テストは、どちらも全体を確認する点では似ています。
しかし、目的と担当者が違います。
| テスト | 視点 |
|---|---|
| システムテスト | 開発側・QA側が、仕様どおりに動くかを確認する |
| 受入テスト | 発注者・利用者が、業務で使えるかを確認する |
受入テストは、開発側が「問題ありません」と言うだけでは完了しません。
発注者・利用者が確認し、受け入れる判断をする必要があります。
「テスト完了」の意味を確認しない
「テスト完了」と言われても、次のどれを意味しているか確認が必要です。
テストケースをすべて実施した
テストで見つかったバグをすべて修正した
修正後の再テストまで完了した
未解決バグはあるが、リリース可能と判断した
顧客の受入承認まで完了したPMは、「テスト完了」という言葉だけで判断せず、完了条件を確認する必要があります。
PM・非エンジニアが進捗確認で聞くべき質問
PMや非エンジニアは、テストの細かい技術内容をすべて理解する必要はありません。
ただし、進捗確認では次の質問が有効です。
今はどのテスト段階ですか？
単体テスト、結合テスト、システムテストのどこまで完了していますか？
未実施のテストケースはどれくらいありますか？
重大なバグは何件ありますか？
修正済みだが再テスト待ちのものは何件ありますか？
リリース判断に影響するバグはありますか？
受入テストはいつから誰が実施しますか？
顧客の承認条件は明確ですか？このように聞くと、「テスト中です」という曖昧な報告から一歩進んで、工程・品質・リリース影響を把握できます。
テスト進捗を見るときの基本指標
テスト進捗を見るときは、件数だけでなく状態も確認します。
| 指標 | 意味 |
|---|---|
| テストケース数 | 予定している確認項目の数 |
| 実施済み件数 | 実際に確認した件数 |
| 未実施件数 | まだ確認していない件数 |
| OK件数 | 期待どおりに動いた件数 |
| NG件数 | 不具合が見つかった件数 |
| 修正済み件数 | 開発側が修正した件数 |
| 再テスト待ち件数 | 修正後の確認がまだの件数 |
| 未解決バグ件数 | まだ解消していない不具合の数 |
| 重大バグ件数 | リリース判断に影響する不具合の数 |
特に注意したいのは、修正済みとクローズ済みは違うという点です。
修正済みは、開発側が修正した状態です。
クローズ済みは、再テストして、期待どおりに直っていることを確認した状態です。
リリース判断では、修正済み件数だけでなく、再テストとクローズ状況も確認しましょう。
受入テストでPMが事前に確認すべきこと
受入テストは、顧客や利用者の協力が必要です。
そのため、直前になってから調整すると遅れることがあります。
PMは、少なくとも次の項目を早めに確認しておきます。
| 確認項目 | 内容 |
|---|---|
| 実施者 | 誰が受入テストを行うのか |
| 実施期間 | 何日間必要か |
| 実施場所 | 本番相当環境、検証環境、顧客環境など |
| テストデータ | 実データに近いデータを使えるか |
| 確認範囲 | どの業務・機能を確認するか |
| 承認者 | 誰が受入完了を判断するか |
| 承認条件 | 何が満たされれば受け入れOKか |
| 不具合時の扱い | どの不具合が残っていると受入不可か |
受入テストが遅れると、リリース日にも影響します。
開発が終わってから考えるのではなく、計画段階から受入テストの段取りを組み込むことが大切です。
バグが見つかったらどうするか
テスト工程では、バグが見つかること自体は珍しくありません。
大切なのは、見つかったバグを記録し、重要度・優先度を判断し、修正・再テストまで管理することです。
基本的な流れは次の通りです。
バグ発見
↓
バグ票作成
↓
重要度・優先度判断
↓
原因調査
↓
修正
↓
再テスト
↓
クローズバグ票の書き方や、バグ・不具合・エラーの違いについては、バグとは？不具合との違い・原因・修正の流れを初心者向けに解説で詳しく解説しています。
AIを使ってテスト観点を整理する
生成AIを使うと、テスト観点の洗い出しを支援できます。
たとえば、次のように依頼できます。
以下の機能仕様をもとに、単体テスト、結合テスト、システムテスト、受入テストの観点を分けて整理してください。
# 機能概要
ここに機能概要を貼り付ける
# 出力形式
| テスト種別 | テスト観点 | 確認内容 | 期待結果 |
|---|---|---|---|
# 注意点
- 技術的に断定できないことは確認事項として出してください
- 受入テストでは、利用者視点の確認を含めてくださいただし、AIにテスト責任を丸投げしてはいけません。
AIは観点のたたき台を出す補助として使い、最終的なテスト範囲や完了判断はPM・QA・開発チームで確認します。
よくある質問
単体テストと結合テストはどちらが重要ですか？
どちらも重要です。
単体テストは部品単体の品質を確認し、結合テストは部品同士をつないだときの問題を確認します。
どちらか一方だけでは、十分な品質確認になりません。
受入テストは開発会社がやるものですか？
受入テストは、基本的には発注者・利用者側が実施します。
ただし、開発会社やPMがテストシナリオ作成、操作説明、不具合整理を支援することはあります。
テストでバグが出るのは悪いことですか？
バグが出ること自体は悪いことではありません。
テストで見つかることに意味があります。
問題は、重大なバグがリリース直前や本番後に初めて見つかることです。
テスト完了は何をもって判断すべきですか？
テストケースの実施率、重大バグの有無、再テスト状況、未解決課題、受入承認の有無を見て判断します。
単に「予定していたテストを実施した」だけでは、リリース可能とは限りません。
関連講座
テスト種別、バグ票、再テスト、リリース判断まで体系的に学びたい方は、以下の講座が参考になります。
ソフトウェアテスト入門
単体テスト・結合テスト・受入テストの違い、テスト観点、バグ票、再テスト、品質確認の基本を学びたい方におすすめです。
ソフトウェアテスト入門の講師クーポン対象講座を見る
まとめ
単体テスト・結合テスト・システムテスト・受入テストは、それぞれ確認する範囲と目的が違います。
単体テスト：部品単体が正しく動くか
結合テスト：部品同士をつないだときに正しく動くか
システムテスト：システム全体として要件を満たすか
受入テスト：発注者・利用者が業務で使えると判断できるかPMや非エンジニアは、コードの細部まで理解する必要はありません。
ただし、今どのテスト段階なのか、未実施や未解決バグがどれくらいあるのか、受入テストの日程と承認条件は明確かを確認する必要があります。
テスト工程は、リリース前の単なる作業ではありません。
品質、スケジュール、顧客承認、リリース判断をつなぐ重要な工程です。