タイトル: 受入テスト/運用テスト
SEOタイトル: 受入テスト (UAT) / 運用テスト完全ガイド
| この記事の要点 |
|
受入テスト (UAT) とは
受入テスト (User Acceptance Test, UAT) は、ソフトウェアテストの最終フェーズで、エンドユーザーまたは発注者が業務シナリオに沿ってシステムを検証する段階です。「技術的に動くか」ではなく「業務に使えるか」を判断します。合格すれば本番リリース、不合格なら開発フェーズへ差し戻しになります。
テスト工程全体の位置づけ
| テスト | 誰が | 何を | 環境 |
|---|---|---|---|
| 単体 (UT) | 開発者 | 関数・クラス単位 | ローカル |
| 結合 (IT) | 開発者 | モジュール間連携 | 開発環境 |
| システム (ST) | QA | 機能全体 | STG |
| システム結合 (SIT) | QA | 外部連携も含む | STG |
| 受入 (UAT) | エンドユーザー | 業務シナリオ | UAT / 本番相当 |
| 運用テスト | 運用チーム | 本番運用想定 | 本番相当 |
UAT と SIT の違い
| 項目 | SIT (System Integration Test) | UAT (User Acceptance Test) |
|---|---|---|
| 視点 | 技術視点 | 業務視点 |
| 実施者 | 開発側 QA | 発注者・ユーザー |
| 目的 | システム連携が技術的に動くか | 業務遂行に使えるか |
| 判断基準 | 仕様書通りに動く | 業務を完遂できる |
| 合否の影響 | 開発側で修正 | リリース判定 |
運用テストの観点
UAT が「機能の業務利用」を見るのに対し、運用テストは本番運用が滞りなく回るかを検証します。
| 分類 | テスト項目 |
|---|---|
| バックアップ / リストア | 日次バックアップ、ポイントインタイムリカバリ、リストア所要時間 |
| 監視 / アラート | CPU/メモリ閾値超過アラート、ログ集約、Slack/PagerDuty 通知 |
| パフォーマンス | ピーク負荷時の応答時間、CPU、DB コネクション |
| セキュリティ | WAF、SQL インジェクション、XSS、認証突破 |
| 災害対策 (DR) | リージョン障害想定の Failover、RTO/RPO 達成 |
| 障害復旧 | サーバ停止 → 自動再起動、DB プライマリ切替 |
| 定期メンテ | パッチ適用手順、再起動時のサービス停止時間 |
| ログローテーション | ディスク満杯にならない |
テスト計画書の構成
1. テスト概要
1.1 テスト目的
1.2 対象システム / 範囲
1.3 前提条件
2. テスト体制
2.1 ロール (発注者代表 / 業務責任者 / 開発側支援)
2.2 連絡フロー / エスカレーション
3. テスト環境
3.1 ハード / ソフト構成
3.2 テストデータ
3.3 外部連携先 (本番接続 / モック)
4. テストスケジュール
4.1 開始日 / 終了日
4.2 マイルストーン
5. テスト範囲
5.1 実施するシナリオ一覧
5.2 除外項目
6. テストシナリオ / ケース
6.1 業務フローごと
6.2 異常系 / 例外系
7. 合否判定基準
7.1 Critical 不具合 0 件
7.2 重要度別の許容件数
8. 不具合管理
8.1 起票プロセス (Jira / Redmine)
8.2 重要度分類 (S/A/B/C)
9. 終了条件 / 報告テストケースの書き方
[テストケース ID: UAT-ORDER-001]
名前 : 顧客が商品を注文できる
前提条件 : 会員登録済み、商品Aの在庫が5個
手順:
1. ログイン (user@example.com / pass)
2. 商品Aを 2 個カートに入れる
3. レジへ進む
4. クレジットカード情報を入力 (テストカード番号)
5. 「注文を確定する」を押下
期待結果:
- 注文完了画面に注文番号が表示される
- 確認メールが届く (件名: 注文ありがとうございます)
- 管理画面で「未発送」ステータスで注文確認できる
- 在庫が 5 → 3 に減少
実施者 : 業務担当 田中
実施日 : 2024-12-15
結果 : OK / NG
備考 :α テスト / β テスト
| テスト | 場所 | 参加者 | 目的 |
|---|---|---|---|
| α (Alpha) | 開発側社内 | 社員・QA | 機能網羅、致命バグ排除 |
| β (Beta) | 限定外部ユーザー | 選定モニター / クローズドベータ | 実利用環境でのフィードバック |
| 受入 (UAT) | 発注者側 | 発注者・業務担当 | 本番投入判定 |
E2E テスト自動化
UAT を支援するため、繰り返し検証する基本シナリオを自動化しておくと効率的です。
// Cypress 例: ログイン → 注文 → 確認のシナリオ
describe('注文フロー', () => {
it('顧客が商品Aを注文できる', () => {
cy.visit('/login');
cy.get('#email').type('user@example.com');
cy.get('#password').type('pass1234');
cy.get('form').submit();
cy.contains('商品A').click();
cy.get('#add-to-cart').click();
cy.visit('/cart');
cy.contains('レジへ進む').click();
cy.get('#card-number').type('4242424242424242');
cy.get('#expiry').type('12/29');
cy.get('#cvc').type('123');
cy.contains('注文を確定する').click();
cy.contains('注文ありがとうございます').should('be.visible');
cy.contains(/注文番号: ORD-\d+/).should('be.visible');
});
});主要 E2E 自動化ツール:
- Cypress: 開発者フレンドリー、JavaScript、ブラウザ内実行
- Playwright: Microsoft 製、複数ブラウザ並列実行、CI 統合容易
- Selenium: 古参、多言語対応、レガシー案件で多用
- Autify / mabl: AI による自己修復、ノーコード
不具合の重要度分類
| レベル | 例 | 対応 |
|---|---|---|
| S (Critical) | 業務停止、データ破壊、セキュリティ脆弱性 | 即時修正、リリース延期 |
| A (High) | 主要機能の動作不良、回避策困難 | リリース前に修正必須 |
| B (Medium) | 非主要機能の不具合、回避策あり | リリース後の優先修正 |
| C (Low) | 表示崩れ、軽微な UX | 次バージョンで対応 |
Go/No-Go 会議
本番リリース判定のための最終会議。以下を確認します:
- S/A レベルの未解決不具合がゼロ
- UAT 合格率 (例: 95% 以上)
- 運用テスト全項目クリア
- ロールバック手順の準備完了
- 監視 / アラート設定済
- 運用チームへの引継ぎ完了
- サポート体制 (リリース直後の張り付き)
承認者: 業務責任者・IT 責任者・開発リーダー・運用責任者の全員サインオフ。
FAQ
Q: UAT で大量の不具合が出たらリリースを止めるべき？
A: S/A 級が出たら止めるべき。B/C 級はサポート対応や次リリース修正で許容することが多い。「UAT で問題ゼロ」を目指すと永遠にリリースできない。
Q: UAT に開発者が参加してよい？
A: 支援役としては OK だが、テスト実施者にはなれない。開発者は自分のコードを甘く見がちなのと、業務知識が浅いため、業務ユーザーが主役。
Q: 運用テストは本番でやってよい？
A: バックアップ / リストア / 監視は本番相当環境で実施推奨。災害対策は本番でやるとリスク。Game Day (計画的に本番擬似障害を起こす演習) はある程度成熟したチームのみ。