在辨識出三種假綠燈、並以突變測試思維判斷我們的測試能否真正偵測到壞掉的行為之後,另一個挑戰浮現了:並非每一個有用的測試都值得永遠執行,也不是每個測試都需要在每次 commit 時執行。一套迴歸測試套件會消耗 CI 時間、基礎設施、維護心力與開發者的注意力。因此 QA 成熟度的下一個階段,是做出決定:

哪些案例能贏得永久席次?哪些應該退役?而倖存者應該多久執行一次?

1. 膨脹套件的真實成本

更多迴歸測試可能讓人感覺有更多保護,但數量終究會帶來自己的風險。龐大的套件執行時間更長、增加基礎設施成本、需要更多維護,而且可能產生足以掩蓋真正失敗的雜訊。緩慢的回饋也會改變團隊行為:當開發者預期迴歸測試要跑太久,他們可能降低執行頻率,或把失敗視為例行的干擾,而不是有用的訊號。

想想 Aurora Shop。隨著時間過去,每一個正式環境的臭蟲、每一次功能發布、每一個邊界案例,都可能留下另一個測試。個別來看,每個案例當初可能都有其正當性,但經年累月的堆積可能產出大量彼此重疊、驗證的其實是同樣行為的情境。因此,目標不應該是保留盡可能龐大的套件,而是維護對有意義的產品風險仍能提供充分證據的最小套件。

2. 保留與退役的判準

一個迴歸測試應該因為它所保護的行為與風險而留下——而不是只因為過去有人寫了它。歷史價值有其意義:一個曾經抓到嚴重正式環境缺陷的案例,提供了「這種失敗確實會發生」的證據。涵蓋金錢、安全、授權、法規遵循或經常變動功能的測試,也有更強的理由留下。

退役同樣應該經過深思。當一個測試當初的需求已不存在、另一個更強的測試已涵蓋相同意圖、它的維護成本超過它所守護風險的價值,或它的情境已與當前產品無關時,它就成為退役候選。僅憑一段長時間通過的紀錄,並不足以刪除它;有時那種穩定,正是迴歸保護想要保住的東西。

對 Aurora Shop 而言,這意味著要定期追問的不只是*「這個測試還會通過嗎?」而是*「如果我們移除它,我們的偵測能力會失去哪一個獨特的失敗?」**如果團隊說不出一個,這個案例可能已經不再配得上它的位置。

3. 測試金字塔對上測試獎盃

迴歸策略也受到測試放在哪一層的影響。傳統的測試金字塔偏好大量快速且隔離的測試、較少的整合測試,以及少數昂貴的端對端測試。它的強項是快速回饋:簡單的行為可以用低成本檢查,不必反覆執行整個應用程式。

測試獎盃則更強調整合測試,主張有意義的信心往往來自驗證元件確實能一起運作。在檢視過假綠燈之後,這一點尤其相關:過度的隔離與 mocking 可能造出通過、但真實互動仍未被驗證的測試。

對 Aurora Shop 而言,最好把兩種模型都當成策略,而不是死板的公式。簡單的計算可以在較低層有效率地檢查,服務之間的互動可以透過 API 與整合測試驗證,而一小組端對端情境可以確認關鍵的顧客旅程確實運作。適當的層級應該取決於在哪裡能最可靠、最經濟地偵測到失敗。

迴歸分級表補上了什麼

迴歸分級規則表把這些原則變成一套可運作的政策。它依所保護的風險,將迴歸案例分為 P0、P1、P2 三層,訂出保留或退役的條件,並指派與重要性相稱的執行頻率。與正式環境缺陷、財務或法規遵循風險、擋發布行為相關的關鍵案例,獲得最強的保護;高風險或最近變動的區域,獲得頻繁但不那麼激進的執行。邊界案例、長尾情境、報表與次要路徑保持可用,卻不會拖累每一次變更。最重要的是,每個新案例都必須同時宣告它的層級與它所守護的特定風險,防止測試只因為「它存在」就進入永久迴歸套件。

在假綠燈分析問「這個測試真的證明了什麼嗎?」、突變測試問「如果行為錯了,這個測試會察覺嗎?」之後,迴歸分級再加一個問題:「如果這個測試有價值,它實際上贏得了我們測試預算中的多少?」