ユーザー受け入れテスト（UAT）とは？やり方や計画書への記載項目を解説

ユーザー受け入れテスト（UAT：User Acceptance Test）とは、開発したソフトウェアやシステムに対して、ユーザー（顧客）が機能的／非機能的振る舞いが仕様通りであることを確認し、期待通りに動作することの妥当性確認を目的とした受け入れテストの一種です。

システム全体の振る舞いや能力に焦点を当てたテストを実施することで、ユーザー（顧客）のニーズ・要件・ビジネスプロセスを満たしているかの評価や検証を行う重要なテストレベルです。

本記事では、テストレベルでもある受け入れテストの一種であるユーザー受け入れテストについて、エンタープライズ領域にフォーカスして説明します。

ユーザー受け入れテストで指摘される典型的な故障として、主に以下の四つが挙げられます。

1. システムのワークフローがビジネス要件またはユーザー要件を満たさない
2. ビジネスルールが正しく実装されていない
3. システムが契約要件または規制要件を満たさない
4.  セキュリティの脆弱性、高負荷時の不適切な性能効率、サポート対象プラットフォームでの不適切な操作などの非機能特性の故障

国際標準（JSTQB）に基づく受け入れテストの定義

受け入れテストの定義は、ソフトウェアテスト分野における国際的な知識体系および資格制度を策定・維持するISTQB（International Software Testing Qualifications Board）が定めるシラバスや用語集を参照しています。

シラバスや用語集は、各国の認定組織を通じて共通の基準として提供されており、日本では JSTQB（Japan Software Testing Qualifications Board）がその提供主体となっています。

受け入れテストは、テストレベルの一つとして次のように記載されています。

受け入れテストは、妥当性確認と、デプロイの準備ができていることの実証に焦点を当てる。これは、システムがユーザーのビジネスニーズを満たしていることを意味する。受け入れテストは、想定ユーザーによって実施をすることが理想的である。受け入れテストの主な形式としては、ユーザー受け入れテスト、運用受け入れテスト、契約、および規制による受け入れテスト、アルファテストおよびベータテストがある。

JSTQB Foundation LevelシラバスVersion 2023V4.0.J02「2.2.1 テストレベル」より引用抜粋

ユーザー受け入れテストとは、ユーザー（顧客）がシステムを受け入れられるかどうかを判断することに焦点を当てたテストレベルです。

一方で、システムテストや運用テスト、シナリオテスト、ユーザーテストなど、目的や役割が異なるテストとユーザー受け入れテストは度々混同されることがあります。

本章では、ISTQB/JSTQBで定義されている考え方を踏まえ、ユーザー受け入れテストと類似するテストを比較し、それぞれの目的と役割の違いを整理します。

図表 1：ユーザー受け入れテストと類似するテスト一覧と対比表

図表1のように、ユーザー受け入れテストは他のテストと確認内容が似ているものの、検収可否を判断する点で本質的に異なります。

次項では、ユーザー受け入れテストを適切に機能させるために、どのような進め方や体制が求められるのかを具体的に整理します。

ユーザー受け入れテストは、テスト工程の終盤、V字モデルのテストレベルにおけるシステムテスト完了後に行います。（ただし、他の工程で行う場合もあります。この点に関してはユーザー受け入れテスト観点で詳しく言及します。）

このテストは実際にユーザーが使用する環境、もしくはそれに近い環境で、システム開発の依頼元によって行われます。（外部ベンダーに外注する場合もあります。）

ユーザー受け入れテストは、開発したシステムが業務・利用文脈において受け入れ可能かをユーザー側が判断することを目的とするため、ISO/IEC25010:2011【JIS X 205010:2013】の品質特性の中でも特に以下のような特性について重点的に検証を行います。

例えば、機能適合性（システムがどの程度要件を満たしているか）、ユーザビリティ（ユーザーが使いやすい仕様になっているか）、信頼性テスト（障害時でも壊れにくいか）、性能効率性（システムが処理を行うに当たって容量を効率良く使用し最適化できているか）、互換性（異なるシステムやハードウェアを組み合わせた際に正常に動作するか）などを中心に検証します。

テスト計画策定の上、実際の運用環境を再現した環境を構築し、上記のような特性を検証するためのテストケースを作成しますが、それらのテストケースはあらかじめ開発委託先に提示するのが一般的です。そのテストケースを基に、ユーザー受け入れテストを実施します。

※品質特性：テスト対象システムの品質要求に焦点を当てた、モデル体系のこと（図表2）

ユーザー受け入れテスト計画書は、受け入れ可否をどの前提と条件で判断するかを事前に整理するための文書で、あらかじめ受け入れ側であるユーザー（顧客）が策定した上で、システム開発を行う組織へ提示します。

ユーザー受け入れテストで対象になるのは主要業務シナリオです。

例えば、受注から請求のプロセスや、マスタ管理などがあります。その一方で、開発者の利用を想定した保守機能などは本テストの対象外です。

ユーザー受け入れテストはまず、実施者としてシステム開発依頼元のテスト担当者、判断者として業務責任者、最終責任者としてプロジェクト責任者から成る体制を敷くことが一般的です。そして、システムテスト完了後、本番相当環境にて本番データ相当のデータを使用して実施します。

具体的には、業務シナリオに基づき、実利用を想定した操作を行い、その結果を確認する流れで実施します。また、この際は手順遵守よりも、業務目的が達成されているかを重視します。

受け入れ基準は、「主要業務シナリオが全て実行可能であること」「重大な不具合が残存しないこと」と設定することが一般的です。この際は、軽微な不具合は影響を確認した上で対応を判断します。この受け入れ基準を達成後、ユーザー（顧客）からユーザー受け入れテスト仕様書やユーザー受け入れテスト結果報告書を受領し、ユーザー受け入れテスト完了となります（図表3）。

ユーザー受け入れテスト計画書によって判断の前提が整理された後、次に大切となるのが具体的に「なにを」「どのように」実施し確認するのかを明らかにすることです。

次項では、この計画書をベースに受け入れ判断につながるテスト項目の考え方について整理します。

ここで言及するテスト項目とは、観点をテストケースに落とし込む前段階の、観点をより具体化した内容のことを指します。

ユーザー受け入れテスト項目は、システムが「正しく動くか」を確認するためのものではなく、業務や利用の文脈において「受け入れ可能か」を判断するための確認項目です。そのため、システムテストの項目をそのまま流用することは適切ではありません。ユーザー受け入れテスト項目は、業務シナリオを起点に整理する必要があります。

例えば、受注から請求までの一連の業務が滞りなく完了するか、ビジネスルールが期待通りに適用されるか、といった観点で項目を定義します。

また、操作のしやすさや業務上許容できる処理時間など、実運用を前提とした観点も重要な項目です。

項目の記載では、操作手順を細かく書くのではなく、結果として何が確認できれば受け入れ可能と判断できるのかを明確に定義します。ユーザー受け入れテスト項目は、網羅性よりも受け入れ後に運用可能なシステムであるかを判断できるかを重視して作成することが重要です（図表4）。

ユーザー受け入れテストには幾つかの観点があります。

例えば、ユーザー（顧客）自身がビジネスで使用できるかの観点がある一方で、情報システム部門など運用者やシステム管理者が運用側面に重点を置いた観点もあります。

その他には、顧客と取り交わした契約書の取り決め基準を満たしているか否かに重点を置く観点や、法的・規制的要件を満たしているか否かに重点を置くといった観点もあります。

テストレベルとしての受け入れテストは、テスト自動化＊1、自動テスト＊2を行うことが可能です。

受け入れテストにおける自動化では、全ての受け入れテストを対象とするものではなく、テストタイプや確認内容の性質に応じて適用範囲を見極める必要があります。

具体的には、仕様として期待結果が明確に定義されている機能テストや、毎リリース実施される回帰的な確認は、自動テストと相性が良い領域です。

これらを自動化することで、確認作業の再現性が向上し、限られた受け入れテスト期間でも安定したテスト実行が可能になります。

また、テスト結果を一定の形式で残せるため、説明責任や確認根拠の明確化という点でも効果があります。

一方で、受け入れテスト工程での自動化には注意点も存在します。

環境やテストデータへの依存が強い場合、自動テストの実行結果が安定せず、再実行のたびに結果が変わることで判断を迷わせる要因となります。

また、「業務運用の妥当性」や「利用方法の適切さ」といった、人の判断を前提とする確認は、自動化の対象には適しません。

これらを無理に自動化すると、かえって受け入れ判断の負担が増大する可能性があります。

受け入れテストでのテスト自動化は、量を増やすことを目的とするのではなく、合否判断に必要な事実確認を安定して提供するための手段として活用することが重要です。

テストタイプごとの特性を踏まえ、図表5に整理したようなメリットとデメリットを理解した上で適用範囲を定めることが、実務で機能する受け入れテストにつながります。

ユーザー受け入れテストは、実運用環境で利用目的やビジネス要件が満たせるか否かを確認する工程です。

システムの開発依頼元であるユーザー（顧客）自身によって行われるテストであり、主要業務シナリオに基づき使用できるか、実用に当たって重大な不具合が残存していないかなどの確認を行います（図表6）。この工程を通じ、システムを本番利用に耐え得るレベルへと引き上げていきます。