browser-qa

Browser QA — 自動化視覺測試與互動

使用時機

• 將功能部署到 staging/preview 環境後
• 需要驗證跨頁面的 UI 行為時
• 出貨前 — 確認版面、表單、互動確實正常運作
• 審查涉及前端程式碼的 PR 時
• 無障礙稽核與響應式測試

運作方式

使用瀏覽器自動化 MCP（claude-in-chrome、Playwright 或 Puppeteer）像真實使用者一樣與即時頁面互動。

安全第一 — 影響範圍（預設唯讀執行）

Browser QA 會操作真實的驗證與使用者流程，因此請明確界定影響範圍。
預設為唯讀：絕對不要對正式環境 URL 執行會變更資料的流程（結帳、付款、刪除、大量更新）— 需要明確的同意以及 staging/preview URL。使用預先建立的測試憑證，絕不使用真實的正式環境登入資訊，並在儲存任何螢幕截圖前遮罩憑證/代碼/PII。

第一階段：冒煙測試

1. 導航到目標 URL
2. 檢查主控台錯誤（過濾雜訊：分析工具、第三方）
3. 確認網路請求無 4xx/5xx
4. 在桌面與行動裝置視口截取首屏畫面
5. 檢查 Core Web Vitals：LCP < 2.5s、CLS < 0.1、INP < 200ms
   （INP 已於 2024 年 3 月取代 FID；閾值依 web.dev）

第二階段：互動測試

1. 點擊每個導覽連結 — 確認無死連結
2. 使用有效資料提交表單 — 確認成功狀態
3. 使用無效資料提交表單 — 確認錯誤狀態
4. 測試驗證流程：登入 → 受保護頁面 → 登出（僅測試憑證，絕不用正式環境）
5. 測試關鍵使用者流程（結帳、入門引導、搜尋）
   — 預設唯讀；僅在明確同意下對 staging 環境執行會變更資料的流程
     （參閱上方「安全第一」）

第三階段：視覺回歸

1. 在 3 個斷點（375px、768px、1440px）截取關鍵頁面
2. 與已提交的基準截圖比較
   — 無基準 ⇒ 回報 INCONCLUSIVE，絕不靜默 PASS
3. 標記版面偏移 > 5px、遺失元素、內容溢出
4. 若適用則檢查深色模式

第四階段：無障礙

1. 在每個頁面執行 axe-core 或同等工具
2. 標記 WCAG 2.2 AA 違規（對比度、標籤、焦點順序）
3. 確認鍵盤導航可完整運作
4. 檢查螢幕閱讀器地標

注意：axe-core 自動涵蓋約 30–40% 的 WCAG。通過檢測是必要條件，非充分條件 — 鍵盤導航、焦點順序與螢幕閱讀器測試仍需手動檢查。不要僅憑自動化檢測就回報「可存取」。

輸出格式

## QA 報告 — [URL] — [時間戳]

### 冒煙測試
- 主控台錯誤：0 個嚴重，2 個警告（分析工具雜訊）
- 網路：全部 200/304，無失敗
- Core Web Vitals：LCP 1.2s ✓、CLS 0.02 ✓、INP 89ms ✓

### 互動
- [✓] 導覽連結：12/12 正常
- [✗] 聯絡表單：無效 email 缺少錯誤狀態
- [✓] 驗證流程：登入/登出正常

### 視覺
- [✗] 英雄區塊在 375px 視口溢出
- [✓] 深色模式：所有頁面一致

### 無障礙
- 2 項 AA 違規：英雄圖片缺少替代文字、頁尾連結對比度不足

### 判定：附修正出貨（2 個問題，0 個阻擋）
# verdict ∈ SHIP / SHIP WITH FIXES / DO NOT SHIP；若無視覺基準則使用 INCONCLUSIVE

整合

可搭配任何瀏覽器 MCP：

• mChild__claude-in-chrome__* 工具（建議 — 使用您實際的 Chrome）
• 透過 mcp__browserbase__* 使用 Playwright
• 直接使用 Puppeteer 腳本

可與 /canary-watch 搭配進行部署後監控。