釐清異常：把 bug 交對人

釐清異常：把 bug 交對人 發現異常，截個圖，在群組貼一句「這個壞掉了」，然後等 RD 問你細節——這條路你走過幾次？每走一次，就消耗一次協作信任，還多一輪來回。 釐清異常，是讓你開口時給的是有效情報，別人不用再花三十分鐘還原現象。交對人、給對線索，是 QA 最能直接加快修 bug 的地方。 分前端還後端 打開瀏覽器 DevTools，切到 Network 面板 ，這是區分問題層的第一步。 觸發異常，看那個請求的狀態碼和 Response： API 回了 4xx 或 5xx，或 Response 的資料結構錯了 （欄位漏了、型別不對、回空陣列但應該要有資料）——這是後端的事。Request 的 URL、Method、Payload、Status Code、Response body，全截下來一起附。 API 回了 200，但畫面顯示錯了 （沒渲染、顯示舊資料、版面跑版）——這是前端的事。附 Console 裡的 error 訊息，比截圖畫面更有用。 根本沒有 Network 請求發出去 ，按鈕按下去什麼都沒觸發——也是前端，邏輯沒有走到發請求那一步。 先看 Network，判斷 API 層有沒有問題，就不用再問「這要找前端還是後端」。 排除環境汙染 異常不一定是新 bug。在開單前，先花五分鐘做三件事： 清快取、換瀏覽器重試 。舊的 JS bundle 被快取住，你看到的行為可能是三個版本前的程式碼在跑。強制重新整理（Cmd+Shift+R）或無痕模式先試一輪。 確認測試資料有沒有被改過 。測試帳號的狀態被其他人跑測試時改掉、訂單被人工處理過、金額被上一個測試案例消費掉——這些都會讓你看到「異常」，但其實是資料已經不在預期的起始狀態。 確認環境本身是不是穩定的 。staging 有時候服務剛好在重啟、DB migration 執行到一半、環境配置和 production 不一致——先問一句「環境現在正常嗎」，比開單再被退票省事。 反過來也要小心：有些 bug 只在特定帳號狀態下出現，一般測試帳號重現不出來，於是被誤判成環境問題。我們分析過一批線上回報，其中一類根因就是帳號的歷史狀態：用過試用又回來的、刪了帳號重建的、訪客轉成正式帳號的。測試帳號通常只覆蓋靜態身份，這些有歷史的狀態從來沒被測到。所以「換一個乾淨帳號就好了」只能用來判斷是不是帳號的問題，不能拿來結案。 偽 bug 開單有成本。信任是有限的；一個「重開瀏覽器就好了」的單，會讓你之後開的真 bug 被多看兩眼。 對事不對人 描述 bug 的語言，決定了對方收到的是「線索」還是「指控」。 ❌「你的登入壞掉了，寫得很有問題。」 ⭕「測試帳號（[email protected]）登入時，API 回 403 Forbidden，Response body 是 {"error":"account disabled"}。帳號狀態在 DB 看起來是 active，麻煩確認一下後端的權限邏輯。」 差別不在客氣不客氣，在資訊密度。前者讓 RD 從零開始還原；後者讓他打開 log 直接找。 主動附上這些線索： Request ID （有的話）：直接串 log，不用再靠時間戳去對。 Payload ：你送了什麼進去，RD 才能重現。 Stack Trace ：Console 或 Crash log，複製原文比截圖好，因為 RD 可以搜尋。 重現步驟 ：具體到「第幾步、操作什麼、在哪個環境、用哪個帳號」。 把 RD 需要問你的問題，在開單前就回答掉。