最近在 Ministry of Testing (MoT) 論壇看到一個值得深思的討論：「我們是否跑了比實際需求更多的回歸測試？」
在手動測試、自動化測試領域，我們很容易陷入「數量迷思」。當腳本從 100 條增加到 1000 條時，表面上覆蓋率更高、更有安全感，但現實往往是：維護成本呈倍數增長，而發現關鍵問題的效率卻在下降。
一、 想刪，但誰敢刪？—— 當責的缺失
我深刻體悟到：刪除一個測試案例，技術上容易，但心理上困難很多。
- 你有沒有遇過一個從來沒失敗過的測試，後來發現它測的功能早就下架了？
- 你有沒有想刪某個測試，卻因為擔心「萬一出事要扛責」而收手的經驗？
- 團隊裡是否曾為了衝 KPI，產出大量「為了綠燈而綠燈」的低價值腳本？
這些場景背後都指向同一個核心：沒有人為這些測試「當責」。 如果一個測試失敗了，卻沒人知道它當初存在的理由；如果一個測試永遠綠燈，卻沒人有權限決定它是否該被淘汰，這個測試就變成了技術債。論壇建議每個測試都應由專人負責，但在現實職場中，提出「精簡」的人往往會被指派去執行。這不只需要技術判斷，更需要一點勇氣。
二、 篩子理論：篩網破洞的雙重代價：對內臃腫、對外失去信任。
要解決數量迷思，必須回頭看測試的本質 ——「篩子理論 (Sieve Theory)」。
想像 Bug 是掉進漏斗裡的碎石與沙塵：
- 第一層（單元測試）：網目最細，能攔截 80% 的微小邏輯錯誤，開發階段即測即改，成本最低。
- 第二層（整合測試）：負責攔截模組串接間的裂縫。
- 最後一層（UI 自動化 / 回歸測試）：網目最粗，理應只負責攔截核心路徑的「漏網之魚」。
很多時候回歸測試之所以臃腫，是因為我們前面的「篩網」破洞了。因為對早期測試沒信心，我們產生了補償心理，試圖在最昂貴、最慢、也最脆弱的 UI 層架設一張密不透風的鋼絲網。我們在最後一關，承擔了前面所有階段的失職。
回歸測試臃腫的另一個副作用，是它製造了大量難以重現的失敗，進而侵蝕 RD 對測試的信任。《單元測試的藝術》給我的啟發是：當 QA 頻繁報出無法穩定重現的 Bug，其實正在一點一滴消耗 RD 的信任。
這種「不可重現性」往往源於 UI 層級過多的外部變因（網路、非同步處理）。書中建議：與其在 UI 層級反覆測試那 1% 的重現機率（這也是無意義回歸測試的來源），不如透過單元測試在受控環境下穩定捕捉邏輯異常。
當篩網的密度在早期就建立好，QA 遇到的「靈異事件」自然減少，雙方的專業信任感也隨之提升。
三、 實踐中的改變：新增腳本前的四個自問
作為 QA，面對堆積如山的回歸測試，我們能做的微小改變是，在未來添磚加瓦，新增任何一條腳本前，先問自己：
- 可解釋性：如果測試失敗，我能 1 分鐘內定位是哪層邏輯出錯嗎？
- 重複性：這個功能點在 API 或單元測試層級測過了嗎？
- 維護性：我有信心在 UI 變動時快速修復它，而不讓它變成 Flaky Test 嗎？
- 存在感：如果這個測試明天消失了，會有人感覺到品質下降嗎？
四、 結語：斷捨離的代價，由誰來扛？
回歸測試不應是 QA 的心理安慰劑，而應是精準的導航雷達。
身為基督徒，我常想起約瑟在埃及的智慧。約瑟在豐年時囤積五穀，是為了荒年時不至於混亂。測試也是一樣——在開發早期補好篩網、建立穩固的單元與整合測試，正是為了上線前不必靠海量回歸測試來壯膽。
精簡測試，本質上是在挑戰眾人的「舒適圈」。它可能會讓習慣「看綠燈安心」的人不舒服，也可能讓提出精簡的人承受壓力。但我期待自己能成為團隊裡的「品質定心丸」—— 這份安全感不是來自於我跑了幾千條腳本，而是來自於我能精準告訴大家：哪些地方我們測透了，哪些地方還有風險。
你願不願意當那個站出來推動改變的人？我自己也還在猶豫，但至少我開始想了。
現在 2026 四月，距離我 2023 三月退伍已經悄悄過了三年。下部隊的那兩個月我在某個營區，主要在幫忙輔導長做些政戰的差事。那個職位的行政瑣事並不少，輔導長常常加班加到周末，我有思考過為什麼沒有人去精簡這些基層的冗長行政流程，但最後的答案是——這不一定符合上頭的利益，我猜測輔導長的上頭要升官，更多要靠的是大量的行政流程確保底下的人不出事。不知道那位輔導長是否順利二十年告退去開大貨車了。
推動斷捨離不只在職場會遇到阻力。四年前，我待的教會每次開預算規劃會議，常常討論得很冗長、沒有結尾，或是聊天聊太久。後來有人推動改變，順利推進成我們這個世代比較想要的樣子——開會就只討論會議的議題，一個小時內就結束了。但那段過程也造成了教會幾個青年人流失，對於十幾人的教會，每一個人的離開都是巨大的損失。
改變會有代價。精簡流程不一定會滿足上頭的利益，還可能會踩到既得利益者的腳，刪掉測試會讓習慣「看綠燈安心」的人不舒服。
*參考討論：
Ministry of Testing - Are we running too many regressions than required?
《單元測試的藝術》(The Art of Unit Testing)