實習的時候，我負責一套多頁表單系統的完整回歸。跑一輪要一整個工作天。
那份清單每個 sprint 都會變長一點。新功能上線，加幾條；出過事的地方，加幾條。
從來沒有人刪過任何一條。
我當時覺得那叫嚴謹。
真正的難在別的地方。
你有沒有看過一條從來沒失敗過的測試，後來才發現它測的功能兩年前就下架了？你有沒有想刪掉某一條，最後收手，因為「萬一出事我要扛」？
刪除的成本不在技術，在當責。
而且還有一層更現實的：在多數團隊裡，提出「我們該精簡」的那個人，就會被指派去執行。
你得證明每一條都真的沒用、你得承擔刪錯的後果、你得在出事的時候被回頭問。
這正好是 Day 6 講的非晉升性任務的教科書案例：做了沒有人稱讚，沒做也不會怎樣，但只要出一次事，名字就在你身上。
三個計分條件一個都沒有，風險倒是全齊。
所以清單只會變長。這不是誰偷懶，是誰都沒有理由動它。
Day 8 講測試是抽樣。一份清單從 100 條長到 1000 條，看起來覆蓋變好了，實際上要看那 900 條加在哪裡。
如果它們全部堆在同一條主流程上，那你只是在同一個位置重複下勺，樣本量變大，代表性沒有變。維護成本倒是實實在在地翻了十倍。
我後來看到一個說法，把這件事講得很清楚：篩子理論。
把 bug 想成掉進漏斗的碎石和沙塵，測試是一層一層的篩網。
單元測試網目最細，在開發階段就攔掉大部分的小邏輯錯誤，成本最低。整合測試攔模組接起來的裂縫。UI 自動化和回歸測試在最後一層，網目最粗，本來只該負責攔核心路徑的漏網之魚。
回歸清單之所以臃腫，通常是因為前面的篩網破洞了。
因為對早期的測試沒信心，我們會產生補償心理，想在最貴、最慢、也最脆弱的那一層，架一張密不透風的鋼絲網。
換句話說：我們在最後一關，承擔了前面所有階段的失職。
我實習的時候扛的那一整天，很大一部分就是在補別人那層網的洞。而我以為那是我的本分。
UI 層外部變因太多——網路、非同步、動畫時序。在那一層跑出來的失敗，有相當比例重現不了。
而每一次你報一個無法穩定重現的 bug，都在消耗 RD 對測試的信任。次數多了，你報的東西會先被預設成「又是環境問題」。
這件事跟 Day 10 那句「我改好了，你測測看」是同一組關係的兩端。信任是雙向的，兩邊都在消耗，也都在累積。
與其在 UI 層反覆追那 1% 重現機率的東西，不如把它推回單元測試，在受控的環境裡穩定捕捉。
刪掉舊的很難，那至少別讓新的隨便長出來。
第四句最狠，也最有用。很多條在這一問之下站不住。
你手上那份只會變長的清單，不是因為它每一條都有價值。
是因為刪掉一條需要有人負責，而沒有人被指定要負這個責。
你未必有權限去刪。但你可以做一件事：把「這條為什麼存在」寫下來，寫在它旁邊。
那句話會變成以後某個人敢刪它的理由。
明天聊：篩選條件測出一個空白的結果，那到底算對還是錯。
iThome鐵人賽
看影片追技術