驗證修復與回歸：別只測那一個點

驗證修復與回歸：別只測那一個點 RD 說「改好了」，你開票、找到 bug 的那個步驟，點進去，確認修好，就關票。這個流程看起來很完整，實際上是最容易讓 bug 逃走的地方。 問題不在你沒測，而在你只測了「壞掉的那個點」，沒有測「改動連帶影響的地方」。修一個 bug、帶出三個新的，幾乎每個 QA 都踩過這坑。 缺陷的一生 一張 bug ticket 的完整狀態通常長這樣：New → Assigned → Open → Fixed → Retest → Closed。 每一個狀態都有對應的責任人。Assigned 是排到 RD 手上；Open 是確認要修；Fixed 是 RD 說改完了； Retest 是 QA 的主場 ，你要驗修好了沒；Closed 才是這張票真的結束。 QA 的責任到 Closed，不是到 Fixed。很多人在 RD 標 Fixed 後測一下沒問題就關票，Retest 形同跳過。同一批改動帶出來的新問題，就在下一版或上線後才浮出來，這叫回歸逃逸。跳過 Retest，就是把逃逸的門打開。 我追過一隻很典型的：iOS 上計時結束後 App 自動登出，重新登入同步，大部分資料回來了，但那段時間的幾筆紀錄就是永久不見。它在某個版本被標成已修復，兩個月後，一模一樣的描述又被回報，前後跨了三個版本週期還在修，顯示當初的修復沒有完整覆蓋。 問 RD 改了哪段 RD 標 Fixed 的時候，多問一句：「這次動了哪部分的程式碼？」 你不用 code review，只是要知道 測試要往哪裡延伸 。RD 改的範圍往往比你想的大：可能修一個計算邏輯，順手調了一個共用的 utility function；可能改了一個 API response 的欄位，同時影響了三個呼叫它的頁面。 如果你只知道「購物車金額計算 bug 修了」，你只會去測購物車顯示的數字對不對。但如果 RD 告訴你「我改了 calculatePrice() 這個函數」，你就知道所有用到這個函數的地方都要連帶確認。那一句話，可以省掉你事後的救火時間。 漣漪效應與波及範圍 改一處，水波會往外擴。你要問的是：「這個改動，漣漪能打到哪裡？」 以購物車計算邏輯為例，直觀上你測：該商品的金額顯示正不正確。但計算邏輯動了，以下這些都可能一起跑歪： 折價券 ：滿額折扣有沒有算對新的商品金額？ 免運門檻 ：跨過門檻的判斷邏輯有沒有連動更新？ 稅金 ：稅是乘以含稅金額還是含稅前金額？如果計算順序改了，稅金數字會跟著錯。 結帳彈窗 ：購物車的小計，和結帳頁最終顯示的金額有沒有一致？ 一個改動，對照要回歸的點： | 改動 | 要順帶測的功能 | | | | | 購物車計算邏輯 | 折價券、免運門檻、稅金、結帳金額一致性 | | 登入 token 刷新機制 | 所有需要登入才能操作的功能、自動登出時機 | | 圖片上傳模組 | 頭像、商品圖、貼文附圖——所有用到這個模組的入口 | 怎麼決定回歸範圍 回歸範圍的抓法：有系統地往外推一層相依功能。 操作步驟很簡單：從改動的模組出發，問「誰用了它？」往外推一層，那一層就是最低限度的回歸範圍。如果改動的是核心共用邏輯（金流、帳號、權限），往外推的層數要更多，風險權重也要更高。 高風險的改動——例如跨多模組的重構、底層 API 結構調整——建議在回歸測試之前先跑一輪冒煙測試，確認主流程沒有斷掉，再展開全面回歸。冒煙先擋住大洞，回歸再補細節，兩個層次不要混在一起跑。 這個系列從找 bug、釘住它，走到把它關好；驗修復與回歸，就是關門的那個動作。