UAT（User Acceptance Testing）は「もう一度QAテスト」ではありません。 UAT は、ソリューションが実際の使用状況でビジネス ニーズを満たしているかどうかを確認することです。
UAT の対応が適切でないと、本番稼働後にリスクが現れることがよくあります。
- ユーザーが使い方を知らない。
- 新しいプロセスが正しく動作しません。
- データ移行がありません。
- 報告書は決定にはなりません。
- ビジネスルールは間違っていますが、仕様がないため QA は知りません。
ソフトウェア BA は通常、PO、QA、ビジネス ユーザーと UAT を調整する人です。
1. UAT は QA テストとどう違うのですか?
| QAテスト | UAT |
|---|---|
| システムが仕様に達しているかどうかを確認してください | ソリューションがビジネスで使用できるかどうかを確認する |
| QA/技術チームが実施 | ビジネス ユーザー/キー ユーザーによって実行 |
| 技術的および機能的な欠陥に焦点を当てる | プロセス、ポリシー、結果に焦点を当てる |
| 詳細なテスト ケースを使用する | ビジネス シナリオを使用する |
| スプリントで連続実行可能 | 通常はリリース/稼働前 |
QA は「システムは要件を満たしていますか?」と答えます。
UAT は「企業はこのソリューションを受け入れますか?」と答えます。
2. UAT プランには何が含まれますか?
テンプレート:
# UAT Plan
## 1. Objective
- UAT để xác nhận điều gì?
## 2. Scope
- In scope
- Out of scope
## 3. Participants
- Business users
- BA
- QA
- Product Owner
- Support/Operations
## 4. Entry Criteria
- Build deployed to UAT environment
- Critical QA defects closed
- Test data ready
- UAT scenarios approved
## 5. Test Scenarios
## 6. Defect Management
- Tool
- Severity/Priority rules
- SLA fix
## 7. Exit Criteria
- Must-have scenarios pass
- No open P0/P1 defects
- Business owner sign-off
## 8. Go/No-Go Criteria
3. UAT シナリオの選択
QA テスト ケース全体をコピーしないでください。 UAT はビジネス ジャーニーに焦点を当てる必要があります。
スケジュール機能の例:
| シナリオ | なぜそれが重要なのか |
|---|---|
| お客様は正常に予約しました | コアビジネスフロー |
| ゲストのスケジュール変更 | 人気の流れ |
| ゲストが時間近くにキャンセルしました | 機密性の高いポリシー |
| 管理者は重複したスケジュールを処理します | 動作上の例外 |
| コンサルタントはその日のスケジュールを表示します | 顧客以外の役割 |
| 予約番号を報告する | ビジネス追跡 |
各シナリオには次のものが必要です。
- ペルソナ/役割。
- 前提条件。
- ステップ。
- 期待されるビジネス成果。
- データが必要です。
- 合格/不合格の基準。
4. テストデータ
テストデータが標準ではないため、UAT は頻繁に失敗します。
チェックリスト:
- ロールごとにユーザーが存在します。
- ノーマル、エッジ、無効なデータがあります。
- ステータスデータが異なります。
- テストレポートが必要な場合に十分な量のデータが含まれています。
- データには許可なく実際の PII が含まれていません。
- テストラウンド間でデータをリセットできます。
たとえば:
| データ | 目的 |
|---|---|
| 顧客 A は確認済み | カレンダー テストキャンセル・変更 |
| 顧客 B にはまだスケジュールがありません | 新しいセットテスト |
| スロットがいっぱいです | テストが空/エラー |
| 管理者ユーザー | 管理テスト |
| コンサルタントユーザー | テストビューカレンダー |
5. 開始および終了の基準
エントリー基準
次の場合にのみ UAT を開始します。
- ビルドが安定しています。
- QA はクリティカル パスを通過しました。
- 既知の問題が発表されました。
- UAT シナリオが承認されました。
- テストデータとアカウントの準備ができています。
- ビジネス ユーザーはテスト スケジュールをすでに知っています。
終了基準
UAT は次の場合に完了します。
- 必須シナリオは 100% 合格します。
- P0/P1 欠陥はなくなりました。
- P2 には回避策があり、企業はそれを受け入れます。
- トレーニング/リリースノートが完成しました。
- ビジネスオーナーの承認。
6. UAT の欠陥にどう対処するか?
ユーザーがエラーを報告した場合:
- THREE は再生ステップを確認します。
- QAは技術的なバグがないかどうかをチェックします。
- BA はビジネスへの影響を判断します。
- PO/ビジネスオーナーが優先順位を決定します。
- チームは修正または延期します。
- BA は UAT のステータスとリリースのリスクを更新します。
分類:
| タイプ | 例 | 取り扱い方法 |
|---|---|---|
| バグ | 予約をキャンセルしてもスロットは再開されません | 修正 |
| 要件のギャップ | ビジネスはキャンセル理由を追加したい | 変更リクエスト |
| 使いやすさの問題 | ユーザーには「再スケジュール」ボタンが表示されません。 UXの調整 | |
| トレーニングの問題 | ユーザーはフィルター レポートを知りません | アップデートガイド |
7. ビジネスの準備
UAT パスは稼働を保証するものではありません。ビジネスの準備には次のものが含まれます。
- ユーザートレーニング。
- 新しい SOP。
- スクリプトをサポートします。
- よくある質問。
- ロールバック計画。
- コミュニケーション計画。
- モニタリングダッシュボード。
- 稼働後の所有者。
稼働開始チェックリスト:
☐ UAT sign-off
☐ Release note
☐ Training done
☐ Support team ready
☐ Monitoring/alert ready
☐ Rollback/fallback plan
☐ Business owner approves go-live
8. ゴー/ノーゴーの決定
ゴー/ノーゴーは感情的であってはなりません。スコアカードを使用します。
| 基準 | ステータス | メモ |
|---|---|---|
| 重要な UAT シナリオ | パス | 12月12日 |
| P0/P1 の欠陥 | パス | 0 オープン |
| P2 欠陥 | 危険にさらされています | 2 オープン、回避策あり |
| トレーニング | パス | 30 人のユーザーがトレーニングを受けた |
| サポートの準備 | パス | SOP が更新されました |
| モニタリング | パス | ダッシュボードのライブ |
| 事業承認 | 保留中 | 待機中の運用責任者 |
「危険にさらされている」場合は、所有者と軽減策を記録する必要があります。
9. 完全な UAT スクリプトの例
UAT シナリオ: 顧客がコンサルティングを予約し、再スケジュールします。
| フィールド | 値 |
|---|---|
| シナリオ ID | UAT-BOOK-002 |
| ペルソナ | 既存の顧客 |
| 目的 | ゲストが締め切りの 4 時間前までに予約および再スケジュールできることを確認します。 |
| 前提条件 | 顧客がアクティブで、コンサルタント A には明日の 09:00 と 10:00 のスロットがあり、電子メール サービスが有効になっています。 |
| テストデータ | customer_id = CUS-1001、consultant_id = CON-2001、slot_09 = SLOT-0900、slot_10 = SLOT-1000。 |
手順:
| ステップ | アクション | 期待される結果 | 証拠 |
|---|---|---|---|
| 1 | 顧客が予約ページを開きます。 | コンサルタントと空のスロットのリストは 2 秒以内に表示されます。 | スクリーンショットのスロットリスト。 |
| 2 | コンサルタント A、スロット 09:00 を選択します。 | 確認ボタンが有効になり、カレンダー情報が正しいです。 | スクリーンショットの確認ページ。 |
| 3 | 「確認」をクリックします。 | ステータスが「確認済み」、確認コードが付いている予約が作成されました。 | 予約ID。 |
| 4 | メールをチェックしてください。 | 確認メールは 1 分以内に届きますが、機密データは含まれません。 | 電子メールのスクリーンショット。 |
| 5 | 10:00の枠に変更してください。 | 古いスロットが再度開かれ、新しいスロットが確認され、監査ログに古い/新しいスロットが記録されます。 | 監査ログID。 |
| 6 | 別のユーザーの予定に変更してみてください。 | 給与体系403。エラーのスクリーンショット。 |
このシナリオの終了基準:
- 高/重大度の欠陥はありません。
- ビジネスユーザーは、文言が理解しやすいことを確認します。
- カスタマー サービスは 4 時間以内に例外処理 SOP を確認します。
- QA は重複予約パスのリグレッションを確認します。
10. AI 機能に何を追加すればよいですか?
機能に AI がある場合、UAT は以下を追加する必要があります。
- ゴールデンテストセット。
- 出力品質のしきい値。
- 幻覚/フォールバックシナリオ。
- ヒューマンオーバーライドフロー。
- 影響が大きい場合のバイアス/安全性レビュー。
- 稼働後のモニタリング。
ただし、UAT 全体が AI を中心に展開しないようにしてください。ビジネスは依然としてエンドツーエンドのプロセスを確認する必要があります。
参照元
- IIBA BABOK ガイド: https://www.iiba.org/standards-and-resources/babok/
- スクラムガイド 2020: https://scrumguides.org/scrum-guide.html
結論
優れた UAT とは、たくさんのテストを行うことではなく、適切なビジネス シナリオ、適切なユーザー、適切なデータをテストし、明確な意思決定を行うことです。ソフトウェア BA は橋渡しの役割を果たします。つまり、要件を UAT 計画に変換し、フィードバックを欠陥/変更に変換し、企業が自信を持って稼働できるよう支援します。