受入テスト

開発されたシステムが発注者の要件を満たしているかを、発注者側が確認するテスト。納品・検収の判断基準となり、実際の業務データを用いて運用可能性を検証する最終段階のテスト。

開発されたシステムが、利用者の意図する用途や目的に合致しているかを確認するテスト。要件定義の内容と実装結果の整合性を検証し、「正しいシステムを作ったか」を判定する。

システムやソフトウェアの取得者（発注者）が、納入されたシステムが契約要件を満たしているかを確認するテスト。受入れ基準に基づいて実施し、合格すれば検収となる。妥当性確認テストの一環として行われる。

開発したシステムやソフトウェアが利用者の本来の要求や意図を正しく満たしているかを確認するテスト。成功基準（期待される結果）に照らして評価し、使用性テストやソフトウェアの試行利用を含む。

開発されたシステムがユーザの要件を満たしているかを利用者が確認するテスト。ユーザ受入テスト（UAT）とも呼ばれ、本番移行前の最終的な検証として位置づけられる。監査ではテスト結果の妥当性を検証する。

個々のモジュールやクラスの機能を独立して検証するテスト工程。ドライバやスタブを用いて、テスト対象のモジュールを単独で動作させる。開発者が主体となって実施し、コードレベルの不具合を検出する。

単体テスト済みのモジュールを組み合わせ、モジュール間のインタフェースや連携を検証するテスト工程。トップダウンテスト、ボトムアップテスト、サンドイッチテスト（混合テスト）などの戦略がある。

結合テスト後にシステム全体として要件を満たしているかを検証するテスト工程。機能テスト、性能テスト、セキュリティテスト、回復テストなどを含む。本番に近い環境で実施し、非機能要件の充足も確認する。

条件の組み合わせと、それに対応する処理（アクション）を表形式で整理する技法。複雑な条件分岐をもれなく網羅的に記述でき、仕様の漏れや矛盾を発見するのに有効。テスト設計にも活用される。

内部構造を考慮せず、入力と出力の関係からテストケースを設計する手法。同値分割、境界値分析、デシジョンテーブル、状態遷移テストなどの技法がある。機能仕様に基づいてテストする。

プログラムの内部構造（制御フロー、データフロー）に基づいてテストケースを設計する手法。命令網羅、分岐網羅、条件網羅、パス網羅などのカバレッジ基準がある。ロジックの正確性を検証する。