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

受入テスト（UAT）でつまずきやすいのは、「画面は動くのに、実際の運用に乗せると止まる」という状態です。
フォームが送れる、予約が取れる、見積が計算できる。ここまで確認していても、担当不在、例外処理、権限違い、通知漏れ、引き継ぎ、集計の定義ずれといった部分が抜けていると、本番で手戻りが出ます。

本記事では、業務シナリオを起点に、権限・ログ・通知・例外運用まで含めてテスト項目を組み立てる方法を整理します。 機能一覧を埋めるためのテストではなく、現場で止まらないかを確かめるための受入テスト をどう作るか、という観点です。

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

受入テストを機能一覧から作ると、「登録できる」「編集できる」「削除できる」といった確認に寄りがちです。 もちろんそれ自体は必要ですが、それだけでは本番で起きる引っかかり方を拾いきれません。

先に作りたいのは、実際の業務に沿ったシナリオです。 最低でも、次の3種類は分けておくと整理しやすくなります。

• 正常系：想定どおりに完了する流れ
• 例外系：不足、修正依頼、キャンセル、担当不在、期限超過などを含む流れ
• 運用系：引き継ぎ、集計、権限変更、監査確認、バックアップ後の復元確認など

例外系を作るときは、ステータス運用（失敗しにくいステータス設計）で考える 「修正依頼」「取消」「差し戻し」「強制クローズ」といった状態を、そのままテストケースに落とすと整理しやすくなります。

2. テストケースは「誰が、何を、どこまで見てOKとするか」まで書く

UATでよく起きるのが、テスト項目はあるのに、誰が見て何をもって合格とするかが曖昧なケースです。 現場担当、管理者、営業、システム管理者で、見るべきポイントは同じではありません。

そのため、1ケースごとに最低限次の要素は持っておく方が扱いやすくなります。

• シナリオ区分（正常系 / 例外系 / 運用系）
• 前提条件（ログイン権限、対象データ、日付状態など）
• 操作手順
• 期待結果
• 確認者

3. フォームのテストは「入力 → エラー → 復帰」まで通す

フォームのテストで見落とされやすいのは、送信成功時ではなく、エラー時と再入力時です。 現場で止まりやすいのもこの部分です。

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

添付ファイルがある場合は、アップロード失敗、再試行、差し替え、公開範囲の確認もテスト対象に入れます（アップロード設計）。 添付が1回成功しただけで安心せず、途中失敗時の挙動まで見ておく方が安全です。

4. 予約は「同時操作」「枠競合」「当日変更」を含めて確認する

予約機能は、1人で触る前提のテストだけだと足りません。 実際には複数の利用者や管理者が同時に触るため、競合や変更時の挙動が重要になります。

• 同一枠への同時申込で、二重確保が起きないか
• 空き状況表示と実際の確保状態がずれないか（表示パターン）
• 時間枠の例外処理に無理がないか（業種別の枠設計）
• 申込フォームとカレンダーの連携が崩れないか（カレンダー×フォーム連携）

特に医療や整備業のように当日変更が多い業種では、 クリニック向け や 自動車販売・整備・タイヤショップ向け のような運用を前提に、 「変更権限」「変更理由」「関係者通知」までテストに含めておくと後で困りにくくなります。

5. 問い合わせ管理は「担当」「期限」「エスカレーション」が本体

問い合わせ管理は、一覧が表示されるだけでは価値が出にくい機能です。 運用の中心は、誰が持っていて、いつまでに返すか、予定より遅れたら誰へ上げるか、という部分にあります。

• 担当割当が仕様どおりか（自動 / 手動 / 混在）
• 期限・優先度が一覧で見分けられるか（運用ルール）
• エスカレーション条件で通知が発火するか（SLA・通知）
• 保存ビューやフィルタが日常運用に使えるか（運用向け設計）

6. 権限とログは「通常操作」より「困る場面」で見る

権限テストは、通常の閲覧や編集より、むしろ見えてはいけないものが見えないか、できてはいけない操作ができないか、という方向で確認した方が有効です。

• 拠点や部署をまたいだ案件が不正に見えないか
• 削除不可のデータが消せないか
• 承認が必要な操作を、承認なしで進められないか
• 変更履歴や承認履歴が監査用に残るか

権限の整理は 権限設計の実務、 ログの確認は 監査ログ設計 の観点で、 「誰が・いつ・何をしたか」が確認できるかまでテストに含める方が実務向きです。

7. レポートと集計は「数字が出るか」ではなく「定義が合っているか」で見る

集計画面は、表示されるだけでは意味がありません。 本番前に揉めやすいのは、数字が出ないことより、数字の定義が合っていないことです。

• 分母 / 分子、除外条件（重複、キャンセル、スパム）の定義が合っているか
• ステータス遷移の履歴が集計へ反映されるか
• 担当別、拠点別で情報の見せ方が権限と整合しているか

このあたりは、KPI設計とレポート定義 の考え方をそのままテスト項目へ落とすと確認しやすくなります。 画面の見た目だけでなく、「この数字は何を数えているのか」が同じ解釈になっているかを確認したいところです。

8. 最後に確認したい受入テストの基本チェック

案件が大きくなるほど、観点を増やしすぎて逆に抜けが見えなくなることがあります。 最後は、次の4群で整理すると全体を見直しやすくなります。

まとめ

受入テストは、「機能が動く」確認ではなく、業務が止まらないかを確かめる工程です。 そのためには、正常系だけでなく、例外系と運用系を業務シナリオとして通しておく必要があります。

フォームならエラーから復帰できるか、予約なら同時操作や当日変更に耐えられるか、問い合わせ管理なら担当と期限が回るか、権限とログは困る場面で破綻しないか。 そこまで含めて見ておくと、リリース後の手戻りはかなり減らせます。

インテンスでも、UATを業務シナリオ起点で組んだ案件の方が、現場の納得感と品質の両立がしやすくなります。 機能一覧を埋めるための受入テストではなく、運用を始めたときに困らないかを確かめるための受入テストとして設計していくのが重要です。