利用者が実際の運用を想定して受け入れの可否を確認するテスト。
受入テストとは、開発が終わったシステムを発注した利用者(発注者)側が、実際の運用を想定して試し、受け入れてよいかを判断するテストです。受入れテスト・承認テストとも呼ばれます。
ソフトウェア開発のテストは段階的に進み、受入テストはその最後の工程に位置します。
・システムテスト:開発側がシステム全体を要件どおりか確認する
・受入テスト:発注者側が「自分たちの業務で使えるか」を確認する
身近な例で考えると、注文住宅の「内覧・引き渡し前のチェック」に似ています。工務店が建てて点検を済ませた後、注文した施主が実際に部屋を見て回り、「依頼どおりに建っているか」を自分の目で確かめてから受け取る──この施主のチェックが受入テストにあたります。
受入テストの大きな特徴は、開発者ではなく発注者(利用者)側が主体となって実施する点です。それまでのテストは作る側が行いますが、受入テストだけは「使う側」が確認します。
発注者は、机上の仕様確認ではなく実際の業務の流れに沿ってシステムを操作し、次のようなことを確かめます。
・要件を満たしているか:契約・要件定義で取り決めた機能が備わっているか
・実運用に耐えるか:普段の業務手順どおりに無理なく使えるか
・受け入れてよいか:問題なければ合格、不足があれば修正を依頼する
発注者が主体になるのは、「本当に役立つかは、使う人にしか分からない」からです。開発側のテストで機能が動くことは確認済みでも、業務の現場で使い物になるかどうかは、実際の利用者が試して初めて判断できます。
受入テストに合格すると、発注者は納品物を正式に受け入れたと認めます。この行為を検収(けんしゅう)といいます。検収は「注文どおりの品を確かに受け取りました」という確認の手続きです。
検収が完了すると、契約上は次のような区切りになります。
・納品の完了:開発側の引き渡し義務が果たされたとみなされる
・支払いの根拠:検収を条件に代金が支払われることが多い
・本番運用へ:以降は発注者がシステムを使い始める
身近な例では、通販で届いた荷物の受け取りに似ています。箱を開けて注文どおりの品か中身を確かめ(受入テスト)、問題なければ「受け取りました」とサインする(検収)──このサインで取引が成立します。だからこそ受入テストは、後のトラブルを防ぐためにも丁寧に行うことが大切です。