從踩過的 Bug 整理出測試啟發，同一類問題不再重來

從踩過的 Bug 整理出測試啟發，同一類問題不再重來 又是時區問題。 這季的跨日結算又因為 UTC／本地時間搞錯出包，跟去年那次幾乎一樣，只是換了個功能。工程師修掉了，開了 retro，列了根因，大家點頭稱是。三個月後，同一類 bug 換了個地方、換了個人，又出現了一次。 團隊修掉的是「這一個 bug」，不是「這一類 bug」。 為什麼 Retro 學不到教訓 團隊有檢討，只是檢討的結果沒有進到下次測試的流程。 Retro 筆記記的是上次發生了什麼，可是設計 case 的時候，沒人會回頭翻 retro。它放在另一個地方，格式也不是「下次測 X 類功能要記得什麼」，它是事後報告，拿來設計測試不好用。 bug 在那邊累積，case 設計在這邊照舊，中間沒有接起來。同樣的根因每次都從零撞上，問題出在記錄的格式跟使用的場合對不上。 往上抽三層：從原始 Bug 到測試啟發 第一層：原始 bug 紀錄。 完整的 context：什麼操作、什麼環境、什麼預期、什麼實際結果。這是原料，也是最長的一層。好的 bug 報告在這裡就要寫清楚，紀錄模糊，後面每一層都抽不準。 第二層：根因模式。 抽掉這個 bug 的特定細節，問一個更大的問題：「這一類錯誤的共通結構是什麼？」不是「跨日結算的時區邏輯寫錯了」，而是「凡是牽涉時間的計算，UTC 與本地時間的轉換邊界都可能出錯」。注意這裡丟掉的東西：功能名稱、特定情境、這次出錯的細節。留下的，是可以搬到其他功能的骨幹。 第三層：可重用的測試啟發。 再往上壓縮一次，目標是一句設計 case 時能直接觸發的提示。例：「測到任何時間相關功能，檢查跨時區、跨日界、夏令時間三個邊界。」這句話不依附在「跨日結算」這個功能上，任何有時間計算的地方都成立。 每往上一層，細節更少，可遷移性更高。最後那一句，才是下次設計 case 時用得上的東西。 抽出來的啟發要進得了流程 抽出來的啟發如果只放在 retro 筆記裡，跟沒抽一樣。Retro 文件只有回顧的時候才會被翻到，設計 case 的時候，沒人會打開它找提示。 這條啟發要放進測試零件庫，跟 S04 講的啟發式清單放在一起。下次設計時間相關功能的 case，掃清單時就會掃到它。 我現在的做法是：bug 結案後，整理成知識寫回知識庫。這一步我覺得最不能省，bug 裡的經驗是產品專屬的，AI 從任何公開資料都學不到。 不是每個 Bug 都值得整理 判準很簡單：這個 bug 的根因，換個功能會不會再踩到？ 會，就值得整理。典型的例子有時區與跨日邊界、並發與競爭條件、權限邊界、狀態殘留、空值與預設值處理，這些根因不依附在特定功能，換個功能、換個工程師照樣踩。 不值得整理的：低級筆誤、一次性的設定搞錯、特定測試環境汙染。根因解決了就消失，換個地方不會出現，不需要抽成啟發。 每次修完 bug 可以問自己一個問題：「如果這個功能是另一個人設計的，他會不會踩到一樣的坑？」會，就抽。不會，就讓它停在 bug 記錄就好。 同一類 bug 一直重複出現，有時候測試跟得再緊也沒用，是團隊裡有什麼一直在製造這類問題。如果某條啟發要一再提醒，值得多問一句：為什麼這類錯誤在我們團隊特別容易發生？測試能讓問題被看見，根源還是要往上游找。 可以從最近一個「感覺以前踩過」的 bug 開始：根因換個功能會不會再出現？會的話，寫成一句「以後測 X 類功能要檢查 Y」，放進你的啟發清單。 下一篇：知識都建起來了，新人接手還是三個月都在問基本業務邏輯。怎麼讓第二大腦變成 onboarding 地圖，新人不靠老鳥也能自己找到答案？