総合テストとは？総合テストの目的や実施時のポイントについて徹底解説
「総合テスト」は、システムテストとも呼ばれ、導入するパッケージシステムやアドオンプログラムで構成されるシステム全体を検証するテストを指します。
他システムと連携がある場合には、そのインターフェース機能もテストの対象に含めます。
また、総合テストは、単体テスト・結合テストの後に行われますが、システム開発会社が主体となって行う最終テストという位置付けになります。
そのため、発注側企業への納品の可否を判断するための重要なものです。
なお、単体テスト、結合テストは、個々のプログラムの品質を検証するものですが、総合テストはシステム全体として、主に以下のポイントで進められることになります。
・機能要件、非機能要件の両方を確認する
・総合テスト仕様書は要件定義書に従って作成する
・業務の流れに則したテストを行う
・テストデータは本番に近いものを使用する
・テスト環境で行う
中でも、ひとつ目のポイントである「機能要件、非機能要件の両方を確認する」ことが、その他のポイントに大きく影響を与える重要なポイントとなります。
機能要件・非機能要件は要件定義フェーズ内における総合テスト仕様書のベースとなる要件定義書の作成の際に記述されます。
機能要件・非機能要件は、システム開発における発注者側の要望のためシステム会社側だけでは作成が出来ません。
したがって、しっかりとした総合テストを行うためには要件定義書を作成する時点で充分な検討と発注側企業の積極的な関与が前提となります。
また、テストに使用するデータの中には発注者側でないと準備出来ないものがあります。
例としては発注者側の業務に沿ったものが該当します。
特に、マスタ系データはテストの品質に大きくかかわりますので、事前にシステム開発会社と協議し、早めに準備することが望ましいと言えます。
総合テストはシステム開発会社が主体となって行うものですが、任せておけばいいというわけではありません。
先に述べたような「要件定義書の作成への関与」「マスター系データの準備」だけにとどまらず、「総合テストで使用する業務シナリオへの助言」「総合テスト仕様書の事前レビュー」「テスト結果報告書のレビュー」など、発注側企業の協力は必要不可欠です。
なお、総合テストと混同しやすい用語に「統合テスト」があります。これは、結合テストと同義で使われる場合や、その中でも内部インターフェースを含んだシステムの検証という意味で使われる用語ですので、総合テストとは別のものです。
また、総合テスト/システムテストという表現を使う際に、「発注者側が行うテスト」と定義されている会社もありますが、当社では、総合テスト（システム開発会社担当）とそれに続く受入テスト（発注側企業担当）を区別しています。
目次
よくある質問
総合テストの目的は何か？発注者が理解しておくべき重要性は？
総合テストの目的は、システム全体が仕様どおりに動作し、関連システムや周辺環境との連携も含めて想定どおりの結果を得られることを確認することです。
発注者にとっては、最終的な品質保証と受入判断の前提となる重要な工程です。
総合テストの主な目的
1. システム全体の機能検証
個別の結合テストを終えた機能を統合し、システム全体として要件が満たされているかを確認します。
2. 外部システムや周辺機器との連携確認
他システムとのデータ連携やインターフェースが正常に動作するかを検証します。
3. 運用環境下での動作確認
本番環境と同等の条件で性能、応答速度、処理能力などを評価します。
4. 想定外シナリオや例外処理の検証
障害発生時や異常データ入力など、例外条件での動作を確認し、安定稼働を確保します。
発注者が理解しておくべき重要性
・受入テストの前提条件
総合テストは受入テストの基礎となり、ここでの不具合残存は運用リスクに直結します。
・品質保証の最終段階の一部
発注者はこの工程を軽視せず、計画段階から評価基準や合格条件を明確にしておく必要があります。
・プロジェクト全体の成功可否に直結
総合テストでの不具合検出はスケジュールやコストに大きく影響するため、早期検出・迅速対応の体制構築が求められます。
これらを理解し、発注者が計画・実施・評価の各段階で適切に関与することが、安定した本番稼働と運用リスクの低減につながります。
総合テスト計画を策定する際、発注者が確認すべき事項は何か？
総合テスト計画を策定する際は、テストの目的・範囲・評価基準・スケジュール・体制などを明確にし、品質保証の観点から発注者が事前に合意しておくことが重要です。
発注者が確認すべき主な事項
1. テスト目的と対象範囲の明確化
・検証すべき機能、外部システム連携、性能要件などを明示する。
・結合テストで検証済みの範囲と総合テストで改めて確認する範囲を区別する。
2. 合格基準・判定条件の設定
・機能要件、性能要件、可用性要件などの達成基準を定義する。
・不具合発生時の判定基準や再テスト条件も含める。
3. テスト環境とデータの準備条件
・本番環境に近い構成・データ量で検証できるかを確認する。
・実運用に近いテストデータの作成・提供方法を決定する。
4. スケジュールとマイルストーン
・各テストフェーズの期間、進捗確認のタイミングを明確化する。
・他工程への影響を最小化するための予備日を設定する。
5. 体制・役割分担
・発注者、ベンダー、第三者検証者の責任範囲を明確化する。
・問題発生時のエスカレーションルートを定義する。
これらの事項を計画段階で明確にしておくことで、総合テストの目的がぶれず、品質保証とスケジュール管理の両立が可能になります。
発注者は計画書の内容を形式的に承認するのではなく、実効性の観点から精査することが重要です。
ベンダーと総合テストの範囲や基準を合意する際の注意点は？
総合テストの範囲や基準をベンダーと合意する際は、機能・性能・連携のすべてにおいて検証対象を明確化し、合格条件や不具合対応方針を事前に文書化しておくことが重要です。
合意時の主な注意点
1. 検証範囲の明確化
・対象となる機能、外部システム連携、業務フローを具体的に列挙する。
・結合テストで確認済みの範囲と総合テストで追加検証する範囲を区別する。
2. 合格基準と判定方法の定義
・機能要件・性能要件・可用性要件などの達成基準を数値や条件で明記する。
・判定方法（テストケース成功率、エラー許容範囲など）を共通認識とする。
3. 不具合の分類と対応ルール
・不具合の重大度区分（致命的、重大、中程度、軽微）を定義する。
・発生時の対応期限や再テスト条件を事前に合意する。
4. テスト環境とデータ条件の共有
・本番環境に近い構成・データ量で検証する条件を確認する。
・ベンダーと発注者双方が同じテストデータ仕様を参照できるようにする。
5. 合意内容の文書化と承認
・会話やメールだけでなく、正式な計画書・合意書として残す。
・契約上の品質保証条項や受入条件と整合させる。
総合テストは品質保証の最終段階であり、範囲や基準の曖昧さは後工程での重大なトラブルに直結します。
発注者はベンダーとの合意内容を形式的に確認するのではなく、実効性・検証可能性の観点から精査することが求められます。
総合テストの結果を受けた改善策や次工程への引き渡しで注意すべき点は？
総合テストの結果を踏まえて改善策を講じ、次工程（受入テストや本番移行）へ進む際は、不具合の残存リスクを最小化し、対応履歴と品質状況を明確に引き渡すことが重要です。
改善策の実施で注意すべき点
1.不具合の完全対応と再テスト
・重大度の高い不具合は必ず修正・再テストを実施する。
・修正の影響範囲を確認し、必要に応じて回帰テストを行う。
2.原因分析と再発防止策の反映
・発生要因を分析し、設計・開発・テスト工程へのフィードバックを行う。
・必要に応じて手順書やテストケースを更新する。
3.対応状況の記録と透明性確保
・不具合管理票や進捗報告書に修正内容・確認結果を記録する。
・発注者・ベンダー間で最新状況を共有し、認識齟齬を防ぐ。
次工程への引き渡しで注意すべき点
1.合格基準の充足確認
・総合テストの計画で定めた合格条件を満たしているかを正式に確認する。
・基準未達の場合は、条件付き承認や再テスト計画を明確にする。
2.残課題・制限事項の明示
・未解決の不具合や制限事項があれば、影響範囲と対応計画を添えて引き渡す。
・受入テストや本番運用に影響する要素は特に詳細に記載する。
3.ドキュメントと証跡の整備
・テスト結果報告書、修正履歴、エビデンス（スクリーンショット、ログ等）を整理して引き渡す。
・契約上必要な成果物提出条件も満たす。
総合テストの結果を適切に改善へ反映し、明確な品質状態と課題管理情報を次工程に引き渡すことが、安定した受入テスト・本番移行につながります。
発注者は形式的な承認ではなく、エビデンスに基づく品質確認を行うことが求められます。
あわせてこの用語と記事をチェック
この記事の編集者
大野 誠司
日本のIT変革の一助となりたいと考え（株）グローバル・パートナーズ・テクノロジーに新卒入社。 主に民間企業の情シス業務に従事しつつ、IT調達ナビでシステム発注に役立つ記事を展開するというメディア運営業務にも携わる。
