UAT（受け入れテスト）シナリオの作り方｜テンプレート・具体例付き
UAT（User Acceptance Testing／ユーザー受け入れテスト）では、単に機能が仕様どおりに動くかだけでなく、実際の利用者が業務を最後まで成立させられるか、ビジネス上の受入条件を満たしているかを確認します。
そのため、UATの成否を左右するのが「どの業務を、誰が、どの条件で、どこまで確認するか」を整理したUATシナリオです。シナリオが曖昧だと、正常系だけを確認して重要な例外処理を見落としたり、担当者ごとに判定がぶれたりする原因になります。
この記事では、UATシナリオを業務フローから作成する6ステップ、すぐ使えるテンプレート、ECサイトと販売管理システムの具体例、テストケースへの落とし込み方、受入基準・終了条件まで実務ベースで解説します。
| 先に結論：UATシナリオに最低限必要な6要素 ①業務の目的・ゴール ②利用者／権限 ③前提条件・テストデータ ④業務フロー ⑤期待結果・受入基準 ⑥優先度。まず正常な業務フローを作り、その後に例外・エラー・運用上の分岐を追加すると整理しやすくなります。 |
UATシナリオとは
ここでは、実際の利用者が行う業務を開始から完了まで一連の流れとして整理し、その業務がシステム上で成立するかを確認するためのテスト設計単位を「UATシナリオ」と呼びます。
JSTQBのAdvanced Level「テストマネジメント」では、受け入れテストについて、ステークホルダーと受入基準を確認し、開発環境外でプロダクトがビジネスニーズと品質基準を満たすことを確かめる活動として整理されています。UATシナリオも、機能一覧ではなく、ユーザーの業務と受入条件を起点に設計することが重要です。
UATとシステムテストの違い
UATとシステムテストは重なる確認項目もありますが、主な目的と視点が異なります。
| 比較項目 | UAT（ユーザー受け入れテスト） | システムテスト |
| 主な目的 | 業務で受け入れられるか、ユーザーニーズ・受入条件を満たすかを確認 | システム全体が定義された要件・仕様どおりに動作するかを確認 |
| 主な視点 | 利用者・業務・ビジネスプロセス | システム・機能・非機能要件 |
| 主な実施者 | 業務部門、利用部門、発注者など | 開発・QA・テスト担当など |
| テストの起点 | 実業務、業務フロー、受入基準 | 要件定義、仕様書、設計、テスト条件 |
| 判断 | この状態で業務利用・リリースを受け入れられるか | 要求された品質・仕様を満たしているか |
UAT全体の目的・流れ・システムテストとの違いを詳しく知りたい方は、「UAT（受け入れテスト）とは？システムテストとの違い・手順・成功のポイント」もあわせてご覧ください。
UATシナリオとテストケースの違い
UATシナリオは「何の業務を、どの流れで受け入れ確認するか」を示す上位の単位です。テストケースは、そのシナリオを検証するために、条件・入力値・操作・期待結果をより具体化した実行単位です。
| 項目 | UATシナリオ | テストケース |
| 粒度 | 業務の開始から完了までの一連の流れ | 個別条件・入力値・操作手順まで具体化 |
| 主な視点 | ユーザー／業務プロセス | 検証条件／具体的な操作 |
| 例 | 会員が商品を選び、決済し、注文を完了する | 在庫ありの商品Aをカード決済し、注文番号が発行される |
| 関係 | 1つのシナリオから複数のケースへ展開する | シナリオを正常・例外・入力条件などに分解して確認する |
テストシナリオとテストケースの一般的な違いや作成順を詳しく確認したい場合は、「テストシナリオ・テストケースの違い」をご参照ください。
UATシナリオのテンプレート｜まずこの項目をそろえる
UATシナリオは、文章だけでなく表形式で管理すると、抜け漏れや判定のばらつきを防ぎやすくなります。以下は実務で使いやすい基本項目です。プロジェクト規模に応じて増減してください。
| 項目 | 記載内容 |
| シナリオID | 一意に識別できる番号。例：UAT-EC-001 |
| シナリオ名 | 何の業務を確認するかが一目で分かる名称 |
| 業務目的 | その業務で達成したいゴール・ビジネス上の意味 |
| 利用者／役割 | 営業担当、承認者、会員、管理者など |
| 前提条件 | ログイン状態、権限、データ状態、環境など |
| テストデータ | 商品、顧客、金額、アカウント、マスタなど |
| 業務フロー／操作 | 開始から完了までの主要な操作を時系列で記載 |
| 期待結果 | 画面・通知・連携・データなど、各操作後に期待する結果 |
| 受入基準 | 業務として受け入れ可能と判断する条件 |
| 優先度 | High／Medium／Lowなど。業務影響と発生頻度で設定 |
| 実施者／確認者 | 誰が実施し、誰が業務判断をするか |
| 結果 | Pass／Fail／Blocked／未実施など |
| 備考・課題ID | 不具合・保留事項・証跡・関連チケットなど |
| テンプレートを作るときのポイント「期待結果」と「受入基準」は分けて書くのがおすすめです。期待結果は各操作に対するシステムの振る舞い、受入基準はその結果を踏まえて業務上受け入れられる状態かどうかの判断条件です。 |
UATシナリオの作り方｜6ステップ
STEP1：対象業務の目的と業務フローを整理する
最初に機能一覧を見るのではなく、ユーザーが何を達成する業務なのかを整理します。業務の開始条件と終了条件、途中で関与する担当者、外部システム、帳票・通知・データ連携まで含めて、実際の業務フローを書き出します。
たとえばECサイトの購入業務なら、「商品を探す→商品を選ぶ→カートに入れる→配送先を確認する→支払方法を選ぶ→注文を確定する→注文完了通知を受け取る」までを一つの流れとして捉えます。
STEP2：利用者・権限・前提条件・テストデータを決める
同じ機能でも、一般ユーザー、管理者、承認者など役割が違えば操作できる範囲や期待結果が変わります。誰が操作するのか、どの権限で実施するのかを明確にし、ログイン状態・契約状態・在庫・マスタ・締め日など、業務成立に必要な前提条件も記載します。
テストデータは「適当な値」ではなく、シナリオの目的を再現できる具体的なデータを準備します。実行者が変わっても同じ条件を再現できる状態が理想です。
STEP3：まず正常系の主要シナリオを作る
最初から例外を増やしすぎると全体像が見えにくくなります。まず、最も頻度が高い、または業務上最重要となる正常な流れを作成します。
「ユーザーがそのシステムを使って最終的に何を完了できればよいか」を起点に、途中の機能を業務の順番に並べるのがポイントです。
STEP4：例外・エラー・運用上の分岐を追加する
正常系ができたら、実際の業務で起こりうる分岐を追加します。入力ミスだけでなく、在庫不足、決済失敗、権限不足、承認却下、外部システム停止、キャンセル・再開、締め処理なども検討します。
分類名はプロジェクトごとに異なりますが、「正常」「業務上の例外」「入力・システムエラー」「運用イベント」のように分けると抜け漏れを確認しやすくなります。
STEP5：期待結果と受入基準を具体的にする
「正常に処理される」「問題なく登録できる」のような曖昧な表現は避けます。何が、どこに、どの状態で反映されるのかを具体的に書きます。
例：注文番号が発行される／在庫数が1減る／決済結果が注文情報に反映される／注文確認メールが送信される、などです。そのうえで「注文・在庫・決済・通知の状態が一致し、担当者が追加の手作業なしで次の業務へ進める」など、業務上の受入基準を定義します。
STEP6：優先順位を付け、業務担当者とレビューする
すべてのシナリオを同じ重要度で扱う必要はありません。売上・法令・顧客影響・業務停止リスク・利用頻度などから優先度を決めます。時間が限られる場合でも、重要業務を先に実行できるようにしておきます。
最後に、業務担当者、開発・QA担当、必要に応じて運用担当でレビューし、「実際の業務に沿っているか」「受入判断できる表現になっているか」「重要な分岐が抜けていないか」を確認します。
レビュー時に確認したいチェックポイント
業務の開始条件と終了条件が明確か
実際の利用者・権限・担当部署が反映されているか
主要業務だけでなく、現場で起きる例外や差し戻しも含まれているか
前提条件とテストデータを第三者が再現できるか
期待結果が「正常に動く」などの曖昧な表現になっていないか
受入基準を満たしたかどうかを客観的に判断できるか
重要シナリオから実行できる優先順位になっているか
UATシナリオの具体例① ECサイトの購入業務
ECサイトを例に、UATシナリオをどの程度具体化すればよいかを見てみましょう。個々のボタンの動作ではなく、「顧客が購入を完了し、その後の注文業務まで正しくつながるか」を確認するのがUATのポイントです。
| ID | シナリオ | 分類 | 利用者 | 受入のゴール | 優先度 |
| UAT-EC-001 | 会員が在庫あり商品を購入する | 正常 | 会員 | 注文・在庫・決済・通知が一連で完了する | High |
| UAT-EC-002 | 在庫不足の商品を購入しようとする | 業務例外 | 会員 | 購入不可が明確に案内され、不整合な注文が作成されない | High |
| UAT-EC-003 | 決済が否認された後に別手段で再決済する | 例外／復旧 | 会員 | 失敗注文が二重計上されず、再決済後に正しい注文が確定する | High |
| UAT-EC-004 | 注文確定後にキャンセルする | 運用 | 会員・運用担当 | 注文・在庫・返金／取消・通知がルールどおり更新される | Medium |
詳細記入例：UAT-EC-001
| 項目 | 記入例 |
| シナリオ名 | 会員が在庫あり商品をクレジットカードで購入する |
| 業務目的 | 顧客が商品を購入し、注文受付から後続業務まで正常に進められること |
| 利用者／役割 | 登録済み会員 |
| 前提条件 | ログイン済み／商品Aの在庫あり／配送先登録済み／利用可能なカードを準備 |
| テストデータ | 商品A×1、会員A、配送先A、カードA |
| 業務フロー | 商品検索 → 商品詳細 → カート → 配送先確認 → 支払方法選択 → 注文内容確認 → 注文確定 |
| 期待結果 | 注文番号が発行され、注文履歴に表示される。在庫が更新され、決済結果が注文に紐づき、注文確認通知が送信される |
| 受入基準 | 顧客と運用担当が同一の注文情報を確認でき、追加の手作業なしで出荷業務へ進める |
| 優先度 | High |
このシナリオからテストケースへ展開する例
| ケースID | 条件／操作 | 期待結果 |
| TC-001 | 在庫あり・通常価格・カード決済 | 注文確定し、注文番号・在庫・決済・通知が正しく反映 |
| TC-002 | クーポン適用後に購入 | 割引後金額で決済され、注文明細にも同額が反映 |
| TC-003 | 配送先の必須項目が未入力 | 注文確定できず、該当項目に分かりやすいエラーが表示 |
| TC-004 | 注文直前に在庫切れ | 在庫不足が案内され、不正な注文・決済が成立しない |
| TC-005 | カード決済が否認 | 注文が確定扱いにならず、再試行または別手段を選択できる |
UATシナリオの具体例② 販売管理システム
業務システムでは、一人のユーザーだけで完結せず、複数部署や承認者をまたぐことがあります。その場合は、担当者間の引き継ぎとデータの一貫性までシナリオに含めます。
| ID | シナリオ | 利用者 | 前提条件 | 受入のゴール |
| UAT-SALES-001 | 受注から出荷・請求まで | 営業→上長→倉庫→経理 | 得意先・商品・在庫・承認ルールが登録済み | 受注・承認・在庫引当・出荷・請求が同じ取引情報でつながる |
| UAT-SALES-002 | 与信限度額を超える受注 | 営業→上長 | 与信設定済み | 警告または承認フローが働き、ルール外の確定を防止 |
| UAT-SALES-003 | 在庫不足時の受注 | 営業→倉庫 | 在庫不足の商品 | 欠品状態が共有され、納期回答や代替処理へ正しく移行 |
| UAT-SALES-004 | 承認後の注文取消 | 営業→上長→倉庫→経理 | 承認済み受注 | 在庫・売上予定・請求予定など関連情報が取消ルールに従って更新 |
| 業務システムで見落としやすいポイント 「画面上で登録できたか」だけでなく、その後の承認、在庫、帳票、通知、外部連携、取消・修正まで追跡します。業務担当者が実際に次の作業へ進める状態かを確認すると、UATらしいシナリオになります。 |
UATシナリオで押さえたい8つのテスト観点
1. エンドツーエンドの業務成立性：業務の開始から完了まで、途中で手作業の補正やデータの入れ直しをせずに進められるか。
2. 権限・役割：担当者、承認者、管理者などの権限ごとに、見える情報・実行できる操作が適切か。
3. データの一貫性：画面、帳票、通知、後続処理などで、金額・ステータス・顧客情報が食い違っていないか。
4. 外部システムとの連携：決済、会計、在庫、メール、APIなど、業務に必要な連携が成功・失敗時ともに正しく扱われるか。
5. 例外・エラーからの復旧：入力ミス、通信失敗、決済失敗、承認却下などの後に、ユーザーが安全にやり直せるか。
6. 通知・帳票：メール、画面通知、請求書、注文書などが正しい相手・内容・タイミングで出力されるか。
7. 運用イベント：取消、変更、再処理、締め、月跨ぎ、担当者変更など、日常運用で発生するイベントに対応できるか。
8. 利用上の受容性：業務上必要な応答時間や操作性など、受入条件として定めた非機能面を満たしているか。
受入基準とUATの終了条件を事前に決める
UATでは、テストを実施するだけでなく「どの状態ならリリースを受け入れられるか」を事前に合意しておくことが重要です。JSTQB Foundation Levelでも、受入基準はステークホルダーが実装を受け入れるために満たす条件として位置付けられています。
| 種類 | 例 | ポイント |
| シナリオ単位の受入基準 | 注文・在庫・決済・通知が矛盾なく完了し、運用担当が出荷へ進める | 単なる画面表示ではなく業務の成立を表す |
| UAT全体の終了条件 | 優先度Highのシナリオをすべて実施し、重大な未解決課題がない | 数値や重要度の定義はプロジェクトで合意する |
| 例外を残す場合の条件 | 既知課題について回避策・影響範囲・改修時期を業務責任者が承認 | 「不具合ゼロ」だけを唯一の終了条件にしない |
| 最終承認 | 業務責任者／プロダクト責任者が結果と残課題を確認してサインオフ | 承認者と記録方法を事前に決める |
※上記は終了条件の例です。重大度、実施率、未解決課題の許容条件は、システムのリスク・契約・規制・業務影響に応じて個別に設定してください。
UATシナリオ作成でよくある失敗
| 失敗例 | 改善方法 |
| 機能一覧をそのままシナリオにする | 機能単位ではなく、利用者が達成したい業務ゴールから組み立てます。 |
| 正常系だけで終わる | 現場では差し戻し、取消、在庫不足、権限違いなどが発生します。重要な例外を追加します。 |
| シナリオが細かすぎてテストケースと区別できない | UATシナリオは業務の流れ、テストケースは具体的な条件・入力・手順と役割を分けます。 |
| 前提条件・テストデータが不足する | 実施者が変わると再現できないため、必要な権限・データ状態まで記録します。 |
| 期待結果が曖昧 | 「正常」「問題なし」ではなく、どのデータ・ステータス・通知がどうなるかを書きます。 |
| 業務担当者だけ、または開発側だけで作る | 利用実態とシステム仕様の両方を反映するため、業務・開発／QA・運用がレビューします。 |
| 終了条件を後から決める | テスト終盤で判断が割れないよう、受入基準とサインオフ条件を事前に合意します。 |
UATの実施・管理を効率化する方法
シナリオ数が少ないうちは表計算ソフトでも管理できますが、複数部署・複数環境・多数のテストケースが関わると、最新版の管理、担当者割り当て、実施結果、証跡、不具合との紐づけが複雑になります。
その場合は、テスト管理ツールを使ってシナリオやケース、実行結果、課題、進捗を一元管理すると効率的です。特に、UATの再実施やリグレッションが発生するプロジェクトでは、過去のケースや結果を再利用しやすくなります。
UATはすべて自動化できる？
繰り返し実行する定型的な確認や、結果を機械的に判定できる操作は、自動化で補助できる場合があります。一方、UATの中心は「業務として受け入れられるか」という判断です。操作性、例外時の業務判断、現場運用との適合性などは、実際の利用者・業務担当者による確認が重要です。
そのため、「UATそのものをすべて自動化する」のではなく、反復性の高い確認は自動化し、業務判断が必要な部分は人が確認する、と役割を分けるのが現実的です。
UATシナリオに関するよくある質問
UATシナリオは誰が作成するのですか？
業務を理解する利用部門・発注側が中心となり、開発者やQA・テスト担当者が設計を支援する形が一般的です。重要なのは、システム仕様だけでなく実際の業務手順と受入条件を反映できるメンバーが関わることです。
UATシナリオはいつ作り始めるべきですか？
UAT直前ではなく、要件や業務フロー、受入条件が整理される段階から準備を始めると、環境・テストデータ・担当者の不足を早めに発見できます。開発中に要件が変わる場合は、シナリオも更新します。
UATシナリオは何件作ればよいですか？
一律の正解はありません。主要業務、重大なリスク、利用頻度、法令・契約上の重要性などから優先順位を付け、受入判断に必要な範囲を定めます。件数を増やすことより、重要な業務フローと分岐をカバーすることが大切です。
UATでも異常系・例外系は必要ですか？
必要です。ただし、すべての技術的な異常をUATで網羅するのではなく、業務上起こりうる例外や、発生したときに業務影響が大きいケースを優先します。
UATシナリオとテストケースはどちらを先に作りますか？
基本は業務フローをもとにUATシナリオを作り、そのシナリオを検証する条件・入力値・操作・期待結果へ分解してテストケースを作成します。
UATの合格基準は誰が決めるべきですか？
業務上の受入可否を判断できる責任者を含むステークホルダーで合意します。開発側だけで決めるのではなく、重大な未解決課題をどこまで許容するか、誰が最終承認するかまで明確にしておくことが重要です。
まとめ
UATシナリオは、機能を一つずつ確認するための一覧ではなく、実際の利用者が業務を開始から完了まで遂行できるかを確認するための設計図です。
作成するときは、業務フローを起点に、利用者・権限、前提条件、テストデータ、正常系、例外・エラー、期待結果、受入基準を整理し、重要なシナリオから優先順位を付けます。
特に「期待結果」と「受入基準」を具体化し、業務担当者と開発・QA担当者がレビューすることで、UATの判定ぶれや重要な確認漏れを減らせます。まずは本記事のテンプレートを使い、自社の主要業務を1本のシナリオとして書き出すところから始めてみてください。
QA業務効率化ならPractiTest
テスト管理の効率化についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで工数を20%削減できる総合テスト管理ツール「PractiTest」がおすすめです！
PractiTest(プラクティテスト)に関する
お問い合わせ
トライアルアカウントお申し込みや、製品デモの依頼、
機能についての問い合わせなどお気軽にお問い合わせください。
この記事の監修
Dr.T。テストエンジニア。
PractiTestエバンジェリスト。
大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。
2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。
記事制作：川上サトシ（マーケター、合同会社ぎあはーと代表）
