受け入れテスト

一言でいうと

作られたシステムが、利用者や発注者の合意した要件と受け入れ基準を満たしているかを、使う側の立場で確かめるテストです。

提唱者と登場年

米国電気電子学会（IEEE）が2008年に発行したテスト文書の規格IEEE 829-2008は、受け入れテストを「システムが受け入れ基準を満たすかを確かめ、顧客がそのシステムを受け入れるかを判断できるようにするために行うテスト」と定義しています。同じ規格は、利用者や顧客などの権限を持つ主体が受け入れの可否を判断するための正式なテストという定義も併記しています。

テスト技術者の資格を運営するJSTQBのFoundation Levelシラバス（2023年版の日本語訳）は、受け入れテストの主な形式として、ユーザー受け入れテスト（UAT）、運用受け入れテスト、契約および規制による受け入れテスト、アルファテストとベータテストを挙げています。

何を解決するか

開発側のテストをすべて通っても、業務で使えるとは限りません。開発側は仕様書に照らして確認するため、仕様書そのものが業務の実態とずれていれば、そのずれは開発側のテストでは見つかりません。受け入れテストでは、実際の業務の流れやデータで利用者が操作し、仕様の外にある食い違いを見つけます。

受託開発では、契約上の区切りを作る役割もあります。独立行政法人情報処理推進機構が公開している「情報システム・モデル取引・契約書」第二版は、発注者が検査仕様書を作成し、それに基づいて納入物を検査して検収する流れを定めています。何を満たせば合格とするかを事前に文書で決めておくことが、この仕組みの前提になります。

実際の進み方

要件定義の段階で受け入れ基準を決め、開発の後半に受け入れテストの計画とテストケースを用意します。テストは本番に近い環境で、業務担当者が実際の手順に沿って行います。

見つかった問題は、不具合として修正するものと、要件の変更として扱うものに分けます。受託開発では、どちらに分類するかによって、追加の費用と期日を誰が負担するかが決まります。合格の判定を得たら、本番へのリリースと運用への移行に進みます。

導入でよくある失敗

• 受け入れ基準を決めないまま始め、合否の判断が担当者の印象に左右される
• 業務担当者の時間を確保せず、開発側が代わりに操作して形式的に終える
• 受け入れテストの段階で初めて画面に触れ、要件の変更が大量に出る

求人票にこの語がある場合に読み取れること

発注側の企業の求人で「受け入れテスト」や「UAT」が業務に含まれている場合、外部の開発会社に委託したシステムを検証し、検収を判断する立場だと読み取れます。開発側の企業の求人では、顧客の受け入れテストを支援する役割を指すことがあります。候補者には、受け入れ基準を誰が決めたか、不具合と要件変更をどう切り分けたかを確認してください。

隣接手法との違い