寫一份 RD 一分鐘看懂的缺陷報告

寫一份 RD 一分鐘看懂的缺陷報告 你提了一張 bug，兩天後工程師回覆：「我這邊重現不了，可以給步驟嗎？」你再補步驟，他說：「哪個環境？用什麼帳號？」你回，他又問：「版本是哪一支？」——一個本來可以半天修完的問題，在往返裡燒掉三天。 這種損耗，多半是報告沒備齊「讓人一眼看懂、立刻開工」的資訊。好的缺陷報告，要讓接手的人不用回頭問你就能動手。 這不是個案。我們回頭整理過一批線上問題回報，335 筆裡有 311 筆（92.8%）連「能不能重現」都沒標；有些只有一行字，像「後台有數據但前台看不到」「活動紀錄卡在 59 分鐘」，連該歸到哪個模組都判斷不了，得回頭找原始回報補細節。問題多半有被回報，卡住的是回報沒辦法轉成可執行的步驟。 報告骨架 一份能獨立運作的缺陷報告，至少要包含七個區塊： 標題 ：在哪裡、做什麼、發生什麼事（下一節細講） 嚴重度 ：Blocker / Critical / Major / Minor——讓 PM 和 RD 知道這張要不要插隊 環境 ：平台、版本、瀏覽器或裝置型號、測試站點 前置條件 ：到達測試起點前，帳號、資料、系統狀態需要是什麼 重現步驟 ：編號條列，每步只做一件事，動詞開頭 預期結果 vs 實際結果 ：並排寫，讓差距一眼就看到 佐證 ：截圖、錄影、log、network response——選能直接看到問題的那份 看一個完整範例： 標題 ：[購物車] 商品超過 100 件結帳跳 HTTP 500 嚴重度 ：Critical 環境 ：Chrome 124、staging 站（https://staging.example.com）、後端版本 v2.4.1 rc3 前置條件 ：已登入一般會員帳號；購物車已加入同一商品 100 件 重現步驟 ： 1. 前往購物車頁 2. 點擊「前往結帳」 3. 確認付款資訊並點擊「確認訂單」 預期結果 ：進入訂單確認頁，顯示訂單編號 實際結果 ：頁面顯示「系統錯誤，請稍後再試」；DevTools Network 顯示 POST /api/orders 回傳 HTTP 500 佐證 ：附上 DevTools Network 截圖（含 response body）、前端 console log 七個區塊缺一不可。前置條件寫清楚，工程師就不會用沒加商品的帳號測一次回來說重現不了。佐證直接貼 response body，比截圖畫面少猜很多。 標題三要素 RD 在 Jira 或 Linear 上看列表，只看標題就要能判斷這張是不是他負責的範圍、值不值得現在打開。 好標題包含三個要素： 在哪裡、做什麼、發生什麼事 。 對比看就清楚： ❌ 「結帳壞了」——在哪個入口？什麼情況下壞？壞成什麼樣？ ❌ 「購物車有問題」——哪種問題？觸發條件？ ✅ 「[購物車] 商品超過 100 件結帳跳 500」——位置、操作、現象三者全在 格式建議：[模組] 做什麼操作 → 出現什麼現象。有數字就放數字（「超過 100 件」比「大量商品」精確），有錯誤碼就放錯誤碼（「跳 500」比「出錯」好搜尋）。標題不是新聞標題，不需要吸引人，需要讓人「掃一眼就知道要不要點進去」。 客觀描述，別下診斷 最常見的一個壞習慣：在描述區把觀察和推測混在一起。 「結帳時頁面白畫面， 應該是後端掛了 」——「後端掛了」是推測，不是你看到的事實。工程師讀到這句，可能直接去後端找問題，但實際原因是前端 JS throw error，根本沒送到後端。你的推測浪費了他的時間。 正確做法是把觀察和推測拆開： 實際觀察 ：點擊「確認訂單」後，頁面顯示白畫面；DevTools console 有 Uncaught TypeError: Cannot read properties of undefined；Network 沒有任何 API 請求發出 推測（選填） ：懷疑是前端在取 cartItems 時遇到 undefined，導致 JS crash 在送出 API 之前——待 RD 確認 把推測標明「這是推測」並與觀察分開，工程師可以自己評估推測值不值得先看，不會被你的猜測帶著跑。你看到什麼就寫什麼，看不到的就誠實說「未知」，比寫一半猜一半更有用。 佐證的選擇也是同樣邏輯：附上能直接看到問題的證據，不是附最多張截圖。一段十秒錄影包含操作到錯誤出現的完整過程，勝過五張只有結果的截圖。