受入テスト設計の作り方｜業務シナリオ起点で漏れを潰すチェックリスト

受入テスト（UAT）が失敗する典型は、「画面は動くが運用で詰まる」状態です。
フォームが送れる、予約が取れる、見積が計算できる――ここまでで終わると、運用開始後に“例外”が噴き出します。
本記事では、業務シナリオを起点に、権限・ログ・通知・例外運用まで含めてテスト項目を作り、漏れを減らす方法を整理します。

1. UATは「機能」ではなく「業務シナリオ」で作る

機能一覧からテストを作ると、例外が漏れます。
まず、業務の流れをシナリオにします。最低でも次の3種類を用意してください。

• 正常系：想定どおりに進む（問い合わせ→返信→完了）
• 例外系：不足/差し戻し/キャンセル/担当不在/期限超過
• 運用系：引き継ぎ、集計、監査、バックアップ、権限変更

例外系を作るときは、ステータス運用（失敗しにくいステータス設計）の「差し戻し・取消・強制クローズ」の考え方をそのままテストに落とすと、漏れが減ります。

2. フォームのテスト：入力→エラー→復帰の一連で見る

フォームは「送信できる」だけでは不十分です。現場で詰まるのはエラー時と再入力です。

• 必須/任意の境界（基準設計と一致しているか）
• 即時バリデーション（入力中チェック）の誤検知がないか
• エラーメッセージの位置と文言（離脱を減らす設計）
• 入力内容保持（戻っても壊れない）

添付ファイルがある場合は、アップロードの失敗・再試行・公開範囲もテスト対象に入れます（アップロード設計）。

3. 予約のテスト：同時操作・枠の競合・当日変更を入れる

予約は“同時に触られる”前提でテストしないと、本番で破綻します。

• 同一枠への同時申込（先着判定・二重取り防止）
• 空き状況表示（表示パターン）と実際の確保の整合
• 時間枠（業種別の枠設計）と例外（延長/短縮）
• 申込フォーム連携（カレンダー×フォーム連携）

特に医療・クリニックや整備業のように当日変更が多い業種は、業務像（クリニック向け / 自動車販売・整備・タイヤショップ向け）を前提に「当日変更の権限」「変更理由」「通知」をテストに入れると事故が減ります。

4. 問い合わせ管理のテスト：担当・期限・エスカレーションまで通す

問い合わせ管理は「一覧が見れる」だけだと価値が出ません。運用の要点は担当と期限です。

• 担当割当（自動/手動/混在）の動作
• 期限・優先度（運用ルール）の表示と更新
• エスカレーション（SLA・通知）が発火する条件
• 保存ビュー/フィルタ（運用向け設計）が使えるか

5. セキュリティのテスト：権限とログは“事故シナリオ”で見る

権限は、通常操作ではなく事故シナリオでテストする方が有効です。

• 閲覧できないはずの案件が見えないか（拠点/部署/担当スコープ）
• 削除できないはずのデータが消せないか（誤操作防止）
• 例外承認でのみ可能な操作が、承認なしで実行できないか

権限の整理は 権限設計の実務、ログの確認は 監査ログ設計 の観点で「誰が何をしたか」が追えるかまでテストに含めてください。

6. レポート/集計のテスト：定義ズレを本番前に潰す

集計は、出してみて初めて「定義が違う」が起きます。本番前にズレを潰します。

• 分母/分子、除外条件（スパム、重複、キャンセル）の定義確認
• ステータス遷移の履歴が集計に反映されるか
• 担当/拠点別の集計で情報漏えいがないか（権限整合）

この論点は、KPI設計とレポート定義の観点をそのままチェック項目に落とすと、議論が早く終わります。

まとめ

受入テストは「機能が動く」確認ではなく、「業務が止まらない」確認です。
正常系に加えて、例外系（差し戻し/キャンセル/担当不在/期限超過）と運用系（権限/ログ/集計/復旧）を業務シナリオとして通すことで、リリース後の手戻りを大きく減らせます。インテンスでも、UATをシナリオ起点で作るほど、現場の納得と品質が両立しやすくなります。