システムテストは、ソフトウェアやシステム全体が要件を満たしているかどうかを確認するためのテストであり、通常、開発フェーズの最後に行われます。

システムテストでは、ソフトウェアやシステムの機能やパフォーマンスが、ユーザーの期待やプロジェクトの要件に従っているかどうかをテストします。

一方、受け入れテストは実際のユーザーがシステムを使用して、ニーズや要件に合致しているかテストし、自分の業務に必要な機能が適切に動作するかどうかを確認します。

受け入れテストは、本番環境で行われる事が一般的であり、ユーザーがソフトウェアを使用して、実際の業務プロセスやシナリオでテストします。

コンポートテストは、作成したプログラムや画面を、できるだけ小さな範囲でテストする段階です。

プロジェクトによっては、単体テストやユニットテストといわれているケースもあり、プログラムであれば関数やメソッドあるいはAPIの単位で動作のテストを行い、画面であればそれだけを表示して見た目や動作を確認します。

受け入れテストが業務的な視点で確認するのに対して、コンポーネントテストは作成された内容が正しいかどうかを個別に確認します。

コンポーネントテストの目的はあくまでも作成されたプログラム単体が詳細設計書通りに動作するかどうかであり、業務的な意味合いに関してはあまり重視していません。

どちらかというと、作成されたプログラムや画面が作成者の意図通りになっているかどうかを確認する意味合いが強いのがコンポーネントテストにあたります。

業務的な要件は要件定義・基本設計まで細分化され、詳細設計に直接影響することはないので、受け入れテストでコンポーネントテストレベルのテストを実行することはほぼありません。


しかし、コンポーネントテストには自動化されている部分が多く、後の保守を想定して自動化されたテストが再実行できる環境を確認することは受け入れテストのなかで行う必要があるでしょう。

また、コンポーネントテストが十分に実施されたエビデンスとして、コンポーネントテストのカバレッジを確認するケースもあるでしょう。

受け入れテストには、以下のような様々な形態があります。

　・ユーザー受け入れテスト
　・運用受け入れテスト
　・契約による受け入れテスト
　・規制による受け入れテスト
　・アルファテストおよびベータテスト

1.ユーザー受け入れテスト

ユーザー受け入れテストは、システムがビジネスで使えるかをユーザーが確認するテストです。

ビジネスで使われる状況を想定した本番環境または模擬本番環境で、ユーザーがシステムを実際に使用して、ニーズや要件に合致しているかを確認します。

2.運用受け入れテスト

運用担当またはシステム管理者が行うシステムの運用受け入れテストは、次のような運用側面に焦点を置いたテストを行います。

本番環境または模擬本番環境で行うのが一般的です。

　・バックアップリスト/リストアのテスト
　・インストール、アンインストール、アップグレード
　・災害復旧
　・ユーザーマネジメント
　・メンテナンスタスク
　・データロードと移行のタスク
　・セキュリティの脆弱性のチェック
　・性能テスト

3.契約による受け入れテスト

契約による受け入れテストは、受注制作のソフトウェアの場合、発注側と開発を担当した企業が契約時に合意し、契約書に記載された基準に従って行うテストです。契約によっては、発注側ではなく、独立したテスト担当者（第三者機関）が行うこともあります。

4.規制による受け入れテスト

規制による受け入れテストは、政府、法律、安全の基準に合致しているかを確認するためのテストです。

会計、セキュリティ、医療など様々なドメインで法律や基準があり法的または規約的要件を満たすことを確認したり、標準、基準に適合しているかを確認したりします。

また、規制による受け入れテストも、契約による受け入れテストと同様に第三者機関が行うこともあります。

5.アルファテストおよびベータテスト

アルファテストとベータテストの違いは、誰がテストを行うかです。
アルファテストは、技術的なバグや生産上のエラー検出のために、社内の専門職員がラボ環境で行うことが多いです。

ベータテストは、実際の使用状況のフィードバックのために、社外の実際のユーザーが本番環境で実施します。

通常はアルファテストを行った後にベータテストを行いますが、ベータテストはアルファテストなしに行うこともあります。

受け入れテストでは、以下のような目的があります。

　・システムの機能的振る舞いが仕様書通りであることを検証するため
　・システムの非機能的振る舞いが仕様書通りであることを検証するため
　・システムが完成し、期待通りに動作する事の妥協性確認をするため
　・システム全体の品質が信頼出来るものであることを確認するため


このように完成したシステムがユーザーの要件や期待を満たしているかどうかの検証を目的に行っています。
なのでこの目的を意識しながらテストを実施すことで見落としや不具合の発見などがしやすくなります。

またテストの形態ごとにもテスト目的があります。

・ユーザー受け入れテスト

システムがユーザーニーズに合致しているかを確認するため
システムが機能要件を満たしていることを確認するため
　

・運用受け入れテスト

例外的な、または困難な状況になった運用環境であっても、システムを適切な稼働状態に　維持できるという信頼を積み上げるため

・契約による受け入れテスト

契約に準拠しているという信頼関係を積み上げるため

・規制による受け入れテスト

規制に準拠しているという信頼関係を積み上げるため

・アルファテストおよびベータテスト

日常的な状況の運用環境であるとき、顧客またはシステム運用者の目的を達成できるという信頼を積み上げるため、システムが使用される状況や環境において、テスト対象に内在する欠陥を検出するため

受け入れテストはテスト工程において最後に実施する工程であり、必要不可欠なテストです。すでに開発とテストが最終段階に入っているシステムを、開発を依頼した側が実際に使用する環境やそれに近い環境で業務や運用の観点で検証を行います。

「依頼側が求めている要件は満たしているか」や、実際に使用するユーザーが「快適に利用できるか」「使用するうえで不都合はないか」など実際の利用を見据えた検証結果を得なければ、本当の意味でシステムの完成とはいえません。仕様書に沿ったシステム開発であったとしても、仕様書に絶対に誤りがないとはいえません。実際の利用環境においてそのシステムが機能しなかったり使いにくかったりすれば、システムを利用した業務が進行しない可能性などもあります。その結果、せっかく作ったシステムが利用されなくなってしまう可能性もあるでしょう。

そのような事態を防ぐため受け入れテストを行い、システムの最終的な完成を確認する必要があるのです。開発者視点だけではなく、依頼者視点でのテストも、使いつづけてもらうソフトウェアを開発するためには必要不可欠なのです。