ユーザー受入テスト (UAT)
エンドツーエンドのUATフレームワーク。計画生成、実行、ステークホルダーの承認、およびGo/No-Goリリースゲートをカバーします。UATは本番環境前の最後の品質ゲートです。そのように扱ってください。受け入れ基準に対する明示的なステークホルダーの承認なしに、フィーチャーをリリースしてはなりません。
前処理 (自動コンテキスト取得)
開始する前に、プロジェクトのコンテキストを静かに収集します。
- プロジェクトルートまたは親ディレクトリに
PORTFOLIO.mdが存在する場合は、それを読み、プロダクト/チームのコンテキストを取得します。 - 実行:
cat package.json 2>/dev/null || cat build.gradle.kts 2>/dev/null || cat Podfile 2>/dev/nullスタックを検出します。 - 実行:
git log --oneline -5 2>/dev/null最近の変更を確認します。 - 実行:
ls src/ app/ lib/ functions/ 2>/dev/nullプロジェクト構造を把握します。 - このコンテキストを使用して、すべての出力を実際のプロジェクトに合わせて調整します。
ステップ1: UATの必要性を分類する
計画を立てる前に、UATのタイプを決定します。タイプによって、スコープ、深さ、ステークホルダーの関与、およびタイムラインが決まります。
| UATタイプ | トリガー | スコープ | 標準的な期間 |
|---|---|---|---|
| 新機能UAT | 機能開発完了、ステージング環境にマージ済み | PRD/ストーリーのすべての受け入れ基準、完全なハッピーパス＋エッジケース | 2〜5営業日 |
| 回帰UAT | 大規模なリファクタリング、依存関係のアップグレード、またはプラットフォーム移行 | 重要なユーザージャーニーを再検証、動作の後退がないこと | 1〜3営業日 |
| リリース候補UAT | リリースブランチ作成、全機能統合 | リリース全体のスコープ — すべての機能、統合ポイント、およびクロスプラットフォームの動作 | 3〜5営業日 |
| ホットフィックス検証 | 本番バグ修正、パッチをステージング環境にデプロイ | 狭いスコープ — 修正を検証し、隣接するフローへの副作用がないことを確認 | 2〜4時間 |
UATのタイプが不明な場合は、先に進む前に質問してください。ホットフィックス検証とリリース候補UATでは、根本的に異なる計画が必要です。
自動コンテキスト収集
UAT計画を作成する前に:
- 既存のテスト仕様、PRDファイル、受け入れ基準ドキュメントをグロブします。
- 見つかった仕様を読み、テスト可能な要件を抽出します。
- テスト対象の機能を制御するフィーチャーフラグをgrepします。
成果物の生成 (必須)
Writeを使用して以下を生成します:
- UAT計画:
docs/uat/uat-plan.md— テスト計画出力スタイルを使用。 - テストケース:
docs/uat/test-cases.md— 手順と期待される結果を含む詳細なテストケース。 - 承認フォーム:
docs/uat/sign-off.md— ステークホルダー承認テンプレート。 - バグトリアージテンプレート:
docs/uat/bug-triage.md— 重大度分類ガイド。
ステップ2: コンテキストを収集する
UAT計画を作成する前に、すべての入力を収集します。コンテキストが不足すると、不完全な計画になります。
| 入力 | 必須 | ソース | 注意事項 |
|---|---|---|---|
| 機能名/リリースバージョン | はい | PM/テックリード | 追跡用の短い識別子 |
| 受け入れ基準 | はい | PRD、ユーザーストーリー、Jira/Linearチケット | 利用可能な場合は/sdlcスキルの出力を使用 |
| ステークホルダーリスト | はい | PM/プロダクトオーナー | 誰がテストし、誰が承認し、誰に拒否権があるか |
| ターゲット環境 | はい | 開発チーム | ステージングURL、ビルド番号、フィーチャーフラグ |
| プラットフォーム | はい | 開発チーム | Android、iOS、Web、または組み合わせ |
| コンプライアンス要件 | オプション | 法務/セキュリティ | テストデータに対するHIPAA、SOC 2、PCI-DSS、GDPRの制約 |
| 既知のリスクまたは制限 | オプション | 開発チーム | 技術的負債、既知の問題、未完了の統合 |
| 以前のUAT結果 | オプション | QA/PM | 回帰比較のベースライン |
| リリース期限 | はい | PM | 固定日か柔軟か — Go/No-Goのプレッシャーを左右する |
受け入れ基準が存在しない場合は、停止し、/sdlcスキルを使用して最初にそれらを作成します。受け入れ基準なしのUATは、意見ベースのテストです。何も証明しません。
ステップ3: UAT計画の生成
3.1 受け入れ基準の抽出
すべてのソースから受け入れ基準を取得し、テスト可能なステートメントに正規化します。
フォーマット: Given [前提条件]、When [アクション]、Then [期待される結果]
ソースの優先順位:
1. PRD受け入れ基準 (権威)
2. ユーザーストーリーの受け入れ基準 (詳細)
3. デザイン仕様 / プロトタイプ (ビジュアルおよびインタラクション動作)
4. APIコントラクト (レスポンス形状、エラーコード)
5. コードレビューまたは/feature-audit中に特定されたエッジケース
すべての受け入れ基準は、1つ以上のテストシナリオになります。基準を手動でテストできない場合は、フラグを立て、自動化された検証方法を指定します。
3.2 テストシナリオマトリックス
完全なシナリオマトリックスを構築します。すべてのシナリオに、期待される結果が1つだけあります。
| ID | カテゴリ | シナリオ | 前提条件 | 手順 | 期待される結果 | プラットフォーム | 優先順位 |
|---|---|---|---|---|---|---|---|
| UAT-001 | ハッピーパス | [主要な成功フロー] | [セットアップ状態] | [1. 2. 3.] | [期待される結果] | すべて | P0 |
| UAT-002 | ハッピーパス | [副次的な成功フロー] | [セットアップ状態] | [1. 2. 3.] | [期待される結果] | すべて | P0 |
| UAT-003 | エッジケース | [境界条件] | [セットアップ状態] | [1. 2. 3.] | [期待される結果] | すべて | P1 |
| UAT-004 | エラー状態 | [無効な入力 / 障害] | [セットアップ状態] | [1. 2. 3.] | [エラーハンドリング] | すべて | P1 |
| UAT-005 | クロスプラットフォーム | [プラットフォーム固有の動作] | [セットアップ状態] | [1. 2. 3.] | [プラットフォームの期待] | 特定 | P1 |
| UAT-006 | アクセシビリティ | [スクリーンリーダー / キーボードナビゲーション] | [支援技術有効] | [1. 2. 3.] | [アクセシブルな結果] | すべて | P1 |
| UAT-007 | パフォーマンス | [ロード時間 / 応答性] | [標準状態] | [1. 2. 3.] | [予算内] | すべて | P2 |
| UAT-008 | オフライン/劣化 | [接続なし / 信号弱] | [機内モード / スロットル] | [1. 2. 3.] | [グレースフルハンドリング] | モバイル | P1 |
優先順位の定義:
- P0 — コア機能。これが失敗すると、機能は動作しません。リリースをブロックします。
- P1 — 重要な動作。これが失敗すると、機能は動作しますが、重大なギャップがあります。リリース前に修正必須。
- P2 — あると便利な検証。これが失敗しても、既知の問題として文書化してリリースできます。
3.3 環境チェックリスト
UATを開始する前に、テスト環境を検証します。環境が壊れていると、ステークホルダーの時間を無駄にし、信頼を損なう可能性があります。
UAT前環境チェックリスト
[ ] ステージング環境に正しいビルド/バージョンがデプロイされている
[ ] ビルドバージョンが文書化されている: _______________
[ ] UATスコープに対してフィーチャーフラグが有効:
[ ] フラグ: _____________ = ON/OFF
[ ] フラグ: _____________ = ON/OFF
[ ] テストデータがシードされている (アカウント、コンテンツ、トランザクション)
[ ] 必要なロール/権限を持つテストアカウントが作成されている
(アカウントプロビジョニングについては/test-accountsスキルを参照)
[ ] サードパーティ統合がテスト/サンドボックスモード:
[ ] Stripe: テストAPIキーを使用したテストモード
[ ] 決済処理業者: サンドボックス環境
[ ] メール/SMS: 傍受、またはテスト受信者を使用
[ ] 分析: dev/stagingプロパティ (本番環境ではない)
[ ] バックエンド/APIがステージング環境 (本番環境ではない) を指している
[ ] データベースに代表的なデータ量がシードされている
[ ] プッシュ通知がステージング環境用に設定されている
[ ] ディープリンク / ユニバーサルリンクがステージングドメイン用に設定されている
[ ] SSL証明書がステージング環境で有効
[ ] VPN/ネットワークアクセスがすべてのテスターに対して設定されている
3.4 ステークホルダーの役割テーブル
誰が何をするかを定義します。役割のあいまいさは、カバレッジのギャップを意味します。
| 役割 | 担当者 | 責任 | 承認権限 |
|---|---|---|---|
| UATリーダー | [名前] | UAT計画を所有し、セッションを調整し、バグをトリアージし、レポートを作成 | 最終的なGo/No-Go推奨 |
| プロダクトオーナー | [名前] | 受け入れ基準が満たされていることを検証し、ビジネスロジックシナリオをテスト | はい — ビジネス承認 |
| デザインリーダー | [名前] | ビジュアルの忠実度、インタラクションパターン、ブランドの一貫性を検証 | はい — デザイン承認 |
| 開発リーダー | [名前] | バグ調査、環境修正、技術的制約の説明が可能 | はい — 技術承認 |
| QAテスター | [名前] | テストシナリオを体系的に実行し、証拠とともに結果を文書化 | いいえ — UATリーダーに報告 |
| ドメインエキスパート | [名前] | ドメイン固有のワークフロー (金融、ヘルスケア、法律) をテスト | はい — ドメイン承認 |
| アクセシビリティテスター | [名前] | スクリーンリーダーパス、キーボードナビゲーション、WCAG AA検証 | 助言 — UATリーダーにエスカレーション |
最小限の承認には以下が必要です: プロダクトオーナー + 開発リーダー。他のすべての承認は推奨ですが、スコープに依存します。
ステップ4: UAT実行フレームワーク
詳細については、reference/details.md (セクション「Step 4: UAT Execution Framework」) を参照してください。
ステップ5: 承認とGo/No-Goゲート
5.1 Go/No-Go決定マトリックス
Go/No-Goの決定は、データ駆動型であり、意見駆動型ではありません。各基準をスコアリングし、加重結果を計算します。
GO / NO-GO 決定マトリックス
機能/リリース: _______________
日付: _______________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌──────────────────────────────────┬────────┬────────┬───────┬───────┐
│ 基準 │ 重み │ ステータス │ スコア │ 備考 │
├──────────────────────────────────┼────────┼────────┼───────┼───────┤
│ すべてのP0シナリオが合格 │ 30% │ GO/NOGO│ X/30 │ │
│ すべてのP1シナリオが合格 │ 25% │ GO/NOGO│ X/25 │ │
│ 未解決のP0バグがない │ 20% │ GO/NOGO│ X/20 │ │
│ 未解決のP1バグがない (またはリスク受容)│ 10% │ GO/NOGO│ X/10 │ │
│ アクセシビリティ合格 (WCAG AA) │ 5% │ GO/NOGO│ X/5 │ │
│ パフォーマンスが予算内 │ 5% │ GO/NOGO│ X/5 │ │
│ クロスプラットフォームの同等性を検証 │ 5% │ GO/NOGO│ X/5 │ │
├──────────────────────────────────┼────────┼────────┼───────┼───────┤
│ 合計 │ 100% │ │ X/100 │ │
└──────────────────────────────────┴────────┴────────┴───────┴───────┘
決定しきい値:
GO >= 90/100 すべてのP0基準がGOである必要があります。
CONDITIONAL 70-89/100 条件と解決のタイムラインを文書化してリリースします。
NO-GO < 70/100 リリースしないでください。修正して再テストしてください。
ハードブロッカー (スコアに関係なく自動的にNO-GO):
- 未解決のP0バグ
- データ損失または破損のシナリオ
- セキュリティ脆弱性 (認証バイパス、データ露出)
- 重要なユーザージャーニーでのクラッシュ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.2 承認テンプレート
ステークホルダー承認
機能/リリース: _______________
ビルド/バージョン: _______________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
┌──────────────────┬──────────────┬──────────┬────────────┬─────────┐
│ ステークホルダー │ 役割 │ 決定 │ 条件 │ 日付 │
├──────────────────┼──────────────┼──────────┼────────────┼─────────┤
│ [名前] │ プロダクトオーナー│ GO/NOGO │ [あれば] │ [日付] │
│ [名前] │ 開発リーダー │ GO/NOGO │ [あれば] │ [日付] │
│ [名前] │ デザインリーダー│ GO/NOGO │ [あれば] │ [日付] │
│ [名前] │ ドメインエキスパート│ GO/NOGO │ [あれば] │ [日付] │
│ [名前] │ UATリーダー │ GO/NOGO │ [あれば] │ [日付] │
└──────────────────┴──────────────┴──────────┴────────────┴─────────┘
条件付き承認とは、「GO。ただし、以下が[日付]までに解決されることを条件とする」ことを意味します:
1. [条件]
2. [条件]
いずれかのステークホルダーがNO-GOに署名した場合、その懸念が解決されるまでリリースはブロックされます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.3 ロールバック計画
すべてのリリースには、Go/No-Go決定の前にロールバック計画を文書化する必要があります。ロールバック計画がない = 自動的にNO-GO。
ロールバック計画
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
トリガー: [ロールバックをトリガーする条件 — 例: クラッシュ率 > 2%、本番環境でのP0バグ]
所有者: [ロールバックを開始する人]
手順:
1. [フィーチャーフラグを無効にする / デプロイをロールバックする]
2. [ロールバックが成功したことを確認する]
3. [ステークホルダーに通知する]
4. [ロールバック後30分間監視する]
データ: [データ移行のロールバックが必要か？ Firestoreドキュメントのバージョン管理は？]
連絡: [必要に応じて誰がユーザーに連絡するか — サポートチーム、ステータスページ]
事後分析: [ロールバックから48時間以内にスケジュール]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.4 リリースノート草案
UATの結果からリリースノートを生成します。この時点で、UATテスターは誰よりも機能をよく知っています。
リリースノート (UATの結果から)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
バージョン: _______________
日付: _______________
新機能
- [追加された機能/ケイパビリティ — ユーザー向けの言葉で]
改善
- [既存機能の強化 — ユーザーにとって何が良くなったか]
修正
- [UAT中に修正されたバグ — 何が壊れていて、今は解決されたか]
既知の問題
- [このリリースで出荷されるP2バグ — 回避策があれば]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ステップ6: UATレポート
すべてのセッションが完了し、承認が収集された後、完全なUATレポートを作成します。
═══════════════════════════════════════════════════════════════
UATレポート
機能/リリース: [名前]
バージョン/ビルド: [バージョン]
日付: [今日]
UATリーダー: [名前]
═══════════════════════════════════════════════════════════════
エグゼクティブサマリー
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
決定: GO / CONDITIONAL / NO-GO
総シナリオ数: [N]
合格: [N] ([X]%)
不合格: [N] ([X]%)
ブロック: [N] ([X]%)
未実行: [N] ([X]%)
未解決ブロッカー: [N] P0 / [N] P1 / [N] P2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
カテゴリ別合格率
┌──────────────────────┬──────────┬────────┬─────────┬────────┐
│ カテゴリ │ 合計 │ 合格 │ 不合格 │ 合格率 │
├──────────────────────┼──────────┼────────┼─────────┼────────┤
│ ハッピーパス │ [N] │ [N] │ [N] │ [X]% │
│ エッジケース │ [N] │ [N] │ [N] │ [X]% │
│ エラー状態 │ [N] │ [N] │ [N] │ [X]% │
│ クロスプラットフォーム │ [N] │ [N] │ [N] │ [X]% │
│ アクセシビリティ │ [N] │ [N] │ [N] │ [X]% │
│ パフォーマンス │ [N] │ [N] │ [N] │ [X]% │
│ オフライン/接続性 │ [N] │ [N] │ [N] │ [X]% │
├──────────────────────┼──────────┼────────┼─────────┼────────┤
…
[翻訳のために切り詰められました]
[翻訳のために切り詰められました]