本稿は 受入テスト (UAT) と運用テスト (OT) に関する記事です。それぞれ User Acceptance Testing、Operation Test の略で、開発工程の最終局面に位置するテストです。「使う側の合格判定」と「運用回せる状態か」を確認するための重要な工程です。

位置づけ

テスト工程	誰が	確認内容
単体テスト (UT)	開発者	関数・クラスが仕様通りか
結合テスト (IT)	開発者 / QA	モジュール間の連動
システムテスト (ST) / 総合テスト	QA	システム全体としての品質・性能
受入テスト (UAT)	発注者・業務ユーザ	業務として使えるか / 合格基準を満たすか
運用テスト (OT)	運用部門・インフラ担当	本番運用フローが回せるか

受入テスト (UAT) の目的

• ユーザ視点で業務要件を満たしているかを最終確認
• 開発者では気付きにくい運用上のおかしさ・操作性を洗い出す
• 契約上の検収判定 (合格 / 不合格) の判断材料
• 本番リリースの Go / NoGo 判断

運用テスト (OT) の目的

• 本番運用フローが想定どおり回せるかを通しで確認
• 監視・ログ・バックアップ・障害対応・夜間バッチ・リリース手順を試行
• 運用担当者の習熟・訓練を兼ねる
• 本番環境構成での性能・容量・障害復旧 (RTO/RPO) 検証

受入テストの典型的なシナリオ例

業務	確認内容
顧客新規登録 → 商品購入 → 出荷	1 件を通し処理できる (Happy path)
キャンセル / 返品	例外シナリオ
月次締め処理	大量データで正しく集計・帳票出力
権限ごとの操作	管理者 / 一般 / 閲覧専用 の権限境界
多端末・ブラウザ	主要ブラウザ・スマホでの動作
業務帳票	レイアウト・桁・印字位置の現場確認

運用テストで通すべき主要シナリオ

シナリオ	確認観点
監視アラート発報	CPU/Memory/Disk/外形監視・通知先・エスカレーション
バックアップ / リストア	取得・保管・復元手順・所要時間 (RTO/RPO)
夜間バッチ	正常終了・異常終了・リトライ・遅延通知
リリース手順	本番リリース・切り戻し・ホットフィックス
パッチ適用	OS・ミドルウェアの保守時間帯運用
障害シミュレーション	サーバ片系停止・DB フェイルオーバ・NW 切断
負荷試験	本番想定 TPS・ピーク時の応答
セキュリティ運用	ログ収集・SIEM 連携・インシデント対応訓練

主な成果物

• 受入テスト計画書 — スコープ・期間・体制・環境・合格基準
• 受入テストシナリオ / テストケース — 機能ID・業務との紐付け
• 運用テスト計画書 / シナリオ
• テスト結果報告書 — 件数・OK/NG・欠陥一覧・再テスト結果
• 残課題・運用上の制限事項リスト
• 運用手順書 (運用設計書の確定版)
• 検収書 / 受領書

合格基準 (Exit Criteria) の例

• テストケースの実施率 100%、合格率 95% 以上
• 重大度 High の欠陥がすべてクローズ済み
• Medium の欠陥は業務影響軽微 + 回避策ありで合意
• 運用テストで RTO / RPO の目標値を達成
• 監視アラートが正しく担当者へ届く
• ステークホルダ全員の承認文書

うまくいかないサイン

• UAT が「画面ポチポチ」 — 業務シナリオではなく機能単体になっている
• 運用テストが省略される — リリース後に深夜障害で爆発
• 本番相当のデータ・件数が用意されていない
• 欠陥の収束曲線を見ていない (毎日新規欠陥が増えるなら未成熟)
• 合格基準が後出し — 「動けば OK」では揉める
• 運用担当が訓練に参加できない — 本番でぶっつけ運用

注意点

• UAT は業務ユーザ視点で行うべき。テスト要員に開発側ばかり混じると意味が薄れる
• OT は本番相当の環境で行う。性能・容量の証跡をログ・スクショで残す
• 個人情報・本番データのコピーを検証環境に持ち込む場合は、マスキング・期限管理が必須
• 欠陥は重大度と再現条件を必ず記録 (再現できないものは塩漬けにしない)
• リリース判定はテスト結果＋運用判断＋ビジネス判断の合議で決める

関連

• 親カテゴリ: 開発工程
• 前工程: 要件定義 / 基本設計 / 単体テスト