# Milktea Skills Usage Scenario QA

> 由 Implement Coordinator 在本次工作啟用使用情境 QA 時委派，實際操作本次成果及直接受影響流程，找出情境缺漏、不合理結果、恢復困難與使用者動向設計缺陷。只回報附證據與燈號的發現，不修改產品。

- Skill: `royalmilkteamaster/milktea-skills-usage-scenario-qa` (Agent Skill)
- Install (CLI): `npx skillmds@latest add royalmilkteamaster/milktea-skills-usage-scenario-qa`
- Raw SKILL.md: https://api.skillmd.com/api/skills/royalmilkteamaster/milktea-skills-usage-scenario-qa/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: RoyalMilkteaMaster (https://skillmd.com/u/royalmilkteamaster)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/royalmilkteamaster/milktea-skills-usage-scenario-qa

---


# 使用情境 QA

從使用者想完成的任務出發，檢查他實際操作、改變主意、
犯錯或遭遇中斷時，產品能否合理承接，並協助開發者完成基礎的 UX 檢查。

不只檢查程式是否符合 Spec，也留意 Spec 沒涵蓋的必要使用情境。

## 輸入與範圍

使用 Coordinator 提供的 Spec、變更摘要、最終 Snapshot、
既有驗收證據、產品入口與測試環境。

只檢查本次變更與直接受影響流程，沿用已有可靠驗收證據，
不重做完整技術 Review，也不掃描無關舊功能。

輸入不完整時，完成仍可驗證的部分並記錄限制；
只有無法確定目標、操作範圍或必要權限時，
才回報缺口並停止相關操作。

## 工作方式

1. 先了解使用者要完成什麼，以及這次新增或修改了哪些功能。如果不同角色、權限或使用條件會影響操作或結果，再分別測試；相同的流程不用重複測。

2. 選擇值得實測的情境，簡短說明選擇理由。
   優先測試使用者經常會做的操作、出錯後影響很大或難以復原的操作，以及這次新增或修改、先前還沒有驗證過的使用方式。

3. 按照使用者實際使用產品的方式操作。有前端介面的功能，就從使用者看得到的畫面、按鈕、選單與輸入欄位操作，不能只靠直接呼叫 API 代替實測。產品本身是命令列工具或提供 API／SDK 時，才從對應入口測試。

   除了正常完成任務，也依本次功能測試使用者改變操作順序、返回、取消、重試或輸入不合預期的內容時，產品會如何反應。發現問題後，再針對相關操作確認原因與影響。

開始、進行、完成、改變主意、犯錯、中斷、重試與再次使用，
是挑選情境的思考角度，不是每次必須跑完的清單。
不固定測試數量，也不無目的地枚舉所有操作組合。

## 判斷與證據

每個問題都要說清楚：使用者想做什麼、實際怎麼操作、發生了什麼，以及這會對使用者造成什麼影響。

依核准需求、任務目標、產品承諾、行為一致性或適用的平台慣例
判斷問題；不能因為 Spec 沒寫，就忽略有證據的使用情境缺漏。

如果發現的問題需要開發者決定產品應該怎麼做，就說明目前行為、使用者可能遇到的影響與建議，並標示「需要開發者決定」，不要把建議當成已核准的需求。

實測時一併檢查使用者動向設計缺陷，例如操作步驟是否過於複雜或多餘、按鈕是否太小或難以找到、重要操作是否不夠醒目，以及文字或操作後的提示是否清楚。也要留意使用者想返回、取消或從錯誤中恢復時，是否有容易找到的做法。

涉及畫面呈現的問題，要查看實際畫面，不能只讀程式碼或按鈕名稱就下結論。

## 執行邊界

- 開始測試前，先確認目前開啟的產品已包含這次修改，避免測到舊版本。
- 確認本次測試必要的停止與重設方式，只操作允許的測試資料。
- Agent 可以使用開發或測試工具調查問題、脫困或重設環境，
  但不能把使用者無法使用的工具操作，當成產品流程正常的證據。
- 卡住時先保存可取得的證據，再使用允許的救援方式；
  救援成功不代表產品問題已解決。
- 重複操作沒有新資訊時停止重試，繼續其他可驗證部分。
- 不修改產品、Spec 或 Tickets，不自動新增測試或安裝工具。
- 零發現是有效結果；未能驗證的部分不得宣稱通過。

## 燈號

依使用者影響與可恢復性標示，並附一句理由：

- 🔴 嚴重：重要任務無法完成、使用者卡住且無合理恢復方式，
  或造成重大非預期後果。
- 🟠 明顯影響：任務仍可完成，但需要繞路、反覆試錯、
  額外協助，或容易造成誤操作。
- 🟡 輕微改善：有具體但輕微的操作負擔、標示不明顯等
  使用者體驗問題，不妨礙完成任務，且容易恢復。

燈號表示影響程度，不代表證據確定程度。
無法驗證或尚不能判斷影響的項目標示「待確認」，不硬分燈號。
沒有發現問題時寫「本次未發現問題」，不建立湊數項目。

## 回報

回報測試版本、實際檢查範圍、發現與驗證限制。

每項發現包含：

- 燈號與標題。
- 情境：使用者想完成什麼，為什麼可能這樣操作。
- 證據：必要前置條件、操作步驟、實際結果與證據位置。
- 影響：任務、資料、理解、控制或恢復受到什麼影響。
- 判斷：已觀察問題／有依據的風險／需要開發者決定。
- 改善方向：應讓什麼使用者結果成立，不綁定完整實作方案。

把結果交回 Coordinator，供完成報告與後續 Grill-me 使用。
不自行修正、擴大需求或決定是否交付。