使用者驗收測試（UAT）
涵蓋計畫生成、執行、利害關係人簽核及 Go/No-Go 發布閘道的端到端 UAT 框架。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 | 功能開發完成，合併至 staging 環境 | 涵蓋 PRD/使用者故事的驗收標準、完整快樂路徑及邊界案例 | 2-5 個工作天 |
| 回歸 UAT | 重大重構、相依套件升級或平台遷移 | 重新驗證關鍵使用者旅程，確認無行為回歸 | 1-3 個工作天 |
| 候選版本 UAT | 發布分支建立，所有功能整合完畢 | 完整發布範圍 — 每個功能、整合點及跨平台行為 | 3-5 個工作天 |
| 熱修復驗證 | 線上問題修復，修補程式部署至 staging 環境 | 範圍狹窄 — 驗證修復，確認對相鄰流程無副作用 | 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/產品負責人 | 誰來測試、誰簽核、誰擁有否決權 |
| 目標環境 | 是 | 工程團隊 | Staging URL、建置編號、特徵旗標 |
| 平台 | 是 | 工程團隊 | Android、iOS、Web 或其組合 |
| 法規遵循需求 | 選填 | 法務/資安團隊 | HIPAA、SOC 2、PCI-DSS、GDPR 對測試資料的限制 |
| 已知風險或限制 | 選填 | 工程團隊 | 技術債、已知問題、未完成的整合 |
| 先前 UAT 結果 | 選填 | QA/PM | 用於回歸比較的基線 |
| 發布截止日期 | 是 | PM | 硬性日期 vs. 彈性日期 — 影響 Go/No-Go 的壓力 |
若驗收標準不存在，請暫停並先使用 /sdlc 技能建立它們。缺乏驗收標準的 UAT 是基於個人意見的測試，無法證明任何事情。
步驟 3：UAT 計畫生成
3.1 驗收標準萃取
從所有來源提取驗收標準，並將其標準化為可測試的陳述句。
格式：Given [前提], When [動作], Then [預期結果]
來源優先順序：
1. PRD 驗收標準（權威來源）
2. 使用者故事驗收標準（詳細）
3. 設計規格/原型（視覺與互動行為）
4. API 契約（回應結構、錯誤代碼）
5. 程式碼審查或 /feature-audit 中識別出的邊界案例
每項驗收標準會轉化為一個或多個測試情境。若某項標準無法手動測試，請標記並指定自動化驗證方式。
3.2 測試情境矩陣
建立完整的情境矩陣。每個情境有且僅有一個預期結果。
| 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 前環境檢查清單
[ ] Staging 環境已部署正確的建置/版本
[ ] 建置版本已記錄：_______________
[ ] 已啟用 UAT 範圍內的特徵旗標：
[ ] 旗標：_____________ = 啟用/停用
[ ] 旗標：_____________ = 啟用/停用
[ ] 測試資料已建立（帳號、內容、交易）
[ ] 已建立具備所需角色/權限的測試帳號
（請參閱 /test-accounts 技能進行帳號佈建）
[ ] 第三方整合設定為測試/沙箱模式：
[ ] Stripe：測試模式，使用測試 API 金鑰
[ ] 金流服務：沙箱環境
[ ] Email/SMS：中繼攔截或使用測試收件者
[ ] 分析工具：使用開發/staging 屬性（非正式環境）
[ ] 後端/API 指向 staging（非正式環境）
[ ] 資料庫已植入具代表性的資料量
[ ] 推播通知已為 staging 環境設定
[ ] 深層連結 / Universal Links 已為 staging 網域設定
[ ] SSL 憑證於 staging 環境有效
[ ] 所有測試人員的 VPN/網路存取已設定
3.4 利害關係人角色表
定義誰負責什麼。角色不明確會導致涵蓋範圍出現缺口。
| 角色 | 人員 | 職責 | 簽核權限 |
|---|---|---|---|
| UAT 負責人 | [姓名] | 擁有 UAT 計畫，協調測試場次，分類問題，產出報告 | 最終 Go/No-Go 建議 |
| 產品負責人 | [姓名] | 驗證驗收標準是否達成，測試業務邏輯情境 | 是 — 業務簽核 |
| 設計負責人 | [姓名] | 驗證視覺保真度、互動模式、品牌一致性 | 是 — 設計簽核 |
| 工程負責人 | [姓名] | 可進行問題調查、環境修復、解釋技術限制 | 是 — 技術簽核 |
| QA 測試人員 | [姓名] | 系統性地執行測試情境，附上證據記錄發現 | 否 — 向 UAT 負責人報告 |
| 領域專家 | [姓名] | 測試特定領域的工作流程（金融、醫療、法律） | 是 — 領域簽核 |
| 無障礙測試人員 | [姓名] | 螢幕報讀軟體測試、鍵盤導航、WCAG AA 驗證 | 諮詢性質 — 向上呈報至 UAT 負責人 |
最低可行簽核需包含：產品負責人 + 工程負責人。所有其他簽核為建議性質，但取決於範圍。
步驟 4：UAT 執行框架
請參閱 reference/details.md（「步驟 4：UAT 執行框架」章節）以獲取完整細節。
步驟 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。
有條件發布 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。
回滾計畫
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
觸發條件： [觸發回滾的條件 — 例如：Crash 率 > 2%、線上環境出現 P0 問題]
負責人： [誰發起回滾]
步驟：
1. [停用特徵旗標 / 還原部署]
2. [驗證回滾成功]
3. [通知利害關係人]
4. [回滾後監控 30 分鐘]
資料： [是否需要還原任何資料遷移？Firestore 文件版本控制？]
溝通： [若需通知使用者，由誰負責 — 支援團隊、狀態頁面]
事後檢討： [安排於回滾後 48 小時內進行]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5.4 發布說明草稿
根據 UAT 發現產出發布說明。此時 UAT 測試人員比任何人都更了解該功能。
發布說明（來自 UAT 發現）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
版本：_______________
日期：_______________
新增
- [新增的功能/能力 — 以使用者語言描述]
改進
- [對現有功能的增強 — 對使用者來說改善了什麼]
修正
- [UAT 期間修復的問題 — 之前什麼東西壞了，現在已解決]
已知問題
- [隨此發布一起上線的 P2 問題 — 若有替代方案則提供]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
步驟 6：UAT 報告
在所有測試場次完成並收集簽核後，產出完整的 UAT 報告。
═══════════════════════════════════════════════════════════════
UAT 報告
功能/版本：[名稱]
版本/建置：[版本]
日期：[今天日期]
UAT 負責人：[姓名]
═══════════════════════════════════════════════════════════════
摘要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
決策： GO / 有條件發布 / 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]% │
├──────────────────────┼──────────┼────────┼─────────┼────────┤