🎯 什麼情境該想到我
當你「測試一紅，團隊第一個念頭是『再跑一次看看』而不是『去修』」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：把手動測試盡量自動化，但只自動化值得信任的測試——因為不可靠的測試會讓整套自動化結果被無視。
做法要點：
- 目標是靠自動化測試套件找出盡量多的程式錯誤，降低對手動測試的依賴，讓測試者（當然包含開發者）去做無法自動化的高價值活動：探索性測試、改善測試流程本身。Elisabeth Hendrickson（2013 Flowcon,「On the Care and Feeding of Feedback Cycles」）：「Although testing can be automated, creating quality cannot. To have humans executing tests that should be automated is a waste of human potential.」
- 但單純把所有手動測試都自動化會產生不良後果：我們不要不可靠、會產生 false positive 的自動化測試（程式功能其實正確、應該通過，卻因效能太慢導致 timeout、起始狀態不受控、或因使用資料庫 stub 與共用測試環境造成非預期狀態而失敗）。
- 不可靠測試造成的損害：浪費時間（逼開發者重跑以判斷到底有沒有問題）、增加執行與判讀測試結果的總成本，而且常導致壓力下的開發者乾脆完全忽略測試結果，或把自動化測試關掉專心寫程式。結果永遠一樣：更晚發現問題、更難修、客戶體驗更差、整條價值流承受壓力。
- 核心原則：少量可靠的自動化測試，幾乎總是優於大量的手動測試或不可靠的自動化測試。
- 因此只自動化那些真正驗證我們要達成的業務目標的測試。
- 若捨棄某個測試導致了生產缺陷，就把它加回手動測試套件，並以「未來終將自動化它」為目標。
- 從少量可靠的自動化測試起步，隨時間持續增加，逐步建立「一有變更把我們帶離可部署狀態就能被快速偵測」的保障水準。
量化案例（Gary Gruver，前 Macys.com 品質工程／發布工程／維運 VP）
- 改造前：一個大型零售電商網站，每十天跑 1,300 個手動測試。
- 改造後：每次 code commit 只跑 10 個自動化測試——「跑少數幾個我們信得過的測試，遠比跑一堆不可靠的測試好。」
- 之後：這套測試套件隨時間成長到數十萬個自動化測試（hundreds of thousands）。
原文：「To mitigate of this, a small number of reliable, automated tests are almost always preferable over a large number of manual or unreliable automated tests.」（L5428–5429）
原文：「we went from running 1,300 manual tests that we ran every ten days to running only ten automated tests upon every code commit—it’s far better to run a few tests that we trust than to run tests that aren’t reliable. Over time, we grew this test suite to having hundreds of thousands of automated tests.」（L5437–5440）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 「少即是多」不是永久狀態，而是起點：Macys 的 10 個測試最後長成數十萬個，砍測試不是終點。
- 捨棄測試是有代價的決定，必須配一個回收機制——導致生產缺陷就加回手動套件，而不是就這樣消失。
- 只自動化「驗證業務目標」的測試是取捨判準，不是省事藉口；判準是可信度與價值，不是好不好寫。
🔗 相關工具
- 測試金字塔（測試的分層與早期攔截，這條負責它的可信度）
- 虛擬安燈繩（false positive 造成的失敗，該測試應被改寫或移除）
- 主幹開發（每次 commit 都跑測試，測試可信度直接決定 CI 能不能運作）
- 工具-部署管線與持續交付（沒有可靠的自動化測試，CD 只是更快地送 bug 上線）
- DevOps手冊