測試左移右移不是新術語，是你測試的時間點出了問題

測試左移右移不是新術語，是你測試的時間點出了問題 目錄 1. 為什麼我以前把測試當成最後一關 2. 左移是什麼，不是什麼 3. 右移是什麼，不是什麼 4. 我現在怎麼在兩個方向都動 5. 結尾 把測試當最後一關 剛入行的時候，我對測試的理解是：RD 做完，交給 QA，QA 測完，上線。 這個流程的問題是：當功能「做完了」交到我手上，所有的架構決策、API 設計、邊界條件的處理方式都已經固定了。我能做的只有驗證——它能動還是不能動。 如果我發現規格有問題，或者某個設計決策根本不合理，那個時候改的成本是最高的。IBM Systems Sciences Institute 的研究指出，在需求階段找到的缺陷，修復成本是上線後才發現的 1/100；美國 NIST 的軟體測試基礎設施研究也估計，軟體缺陷每年造成的損失中，超過一半本可透過更早介入的測試避免。RD 要重工，PM 要重排 timeline，所有人都很痛苦。 然後大家開始說：「QA 要更早介入。」 這就是測試左移。 左移是什麼 測試左移的核心概念只有一句話： bug 發現得越早，修復的成本越低。 這不是新觀念。2001 年就有人寫進期刊裡了。但「越早」這兩個字，在實務上意味著什麼？ 在我們團隊，測試左移實際上是這幾件事： 需求討論階段就進去 每次新功能的 spec 討論，我都會進去坐著。不是要「提早開始測試」，是要在這個階段就問：「這個情境下如果用戶做了 X，系統怎麼反應？這個沒有定義清楚。」 很多 bug 在 spec 就已經埋好了。RD 根據模糊的 spec 實作，QA 根據自己的理解測試，上線後用戶的行為又是第三種理解——三方不同步，bug 就是這樣來的。 和 RD 一起看 API 設計 功能還沒開始實作的時候，我會請 RD 讓我看一眼 API 的 contract 定義。問幾個問題： 「這個 error code 有哪幾種？」 「這個欄位的型別和範圍限制是什麼？」 「如果上游 API 超時，這邊怎麼處理？」 這些問題在 API 設計階段問，比在測試階段發現省了很多時間。 CI 上的自動化是左移的基礎設施 每次 push 自動跑測試，是讓測試真的「左移」的機制。沒有這個，就算 QA 再早介入，整合問題還是要等到最後才知道。 右移是什麼 左移讓你早點找 bug，右移讓你在真實環境裡觀察系統的行為。 測試右移的核心概念： staging 環境永遠模擬不了真實的 production。 用戶的網路條件、裝置型號、操作習慣、使用量的峰值——這些在 staging 上是假的。真實的問題只有在真實環境裡才會出現。 右移的具體做法包括幾種，我接觸過的是這些： Canary Release（金絲雀發布） 新版本不是一次性推給所有人，而是先推給 1%、5%、20% 的用戶，觀察這個比例的用戶有沒有異常，再決定要不要全量。 這讓你在真實用戶身上測試，但影響範圍可控。出了問題，rollback 只影響那 5%。 A/B Testing 同時跑兩個版本，看哪個版本的用戶行為數據更好。這不只是功能測試，是在真實環境裡驗證產品決策。 監控 + Alerting Shift Right 不是「放著讓用戶幫你測」，是建立一套觀測機制，讓你知道上線之後系統的真實狀態：錯誤率、latency、crash rate。如果這些指標異常，比用戶回報還早知道。 Chaos Engineering（混沌工程） 刻意在 production 製造故障，測試系統的恢復能力。Netflix 的 Chaos Monkey 是最有名的例子。這個對大多數中小型團隊太重，但概念是對的：你不能只測「正常運作」，要測「失敗發生時系統怎麼反應」。 兩個方向都動 左移和右移不是選一個，是互補的。 左移擋住的是：規格問題、邏輯 bug、整合問題。 右移發現的是：真實環境的效能問題、邊緣使用者行為、規模化之後才出現的問題。 只有左移：你在 staging 裡測得很漂亮，上線後遇到真實流量就掛了。 只有右移：你等用戶幫你踩 bug，代價是用戶的信任。 兩個方向都做，才是比較完整的品質覆蓋。 我的現況：左移比右移做得多 坦白說，我目前右移做得很有限。 我們有基本的監控（錯誤率、crash rate），有 canary release 的機制，但 chaos engineering 我們完全沒有做，A/B testing 也只在特定功能上才用。 左移的部分，我進需求討論、看 API 設計、CI 跑自動化——這些是每個 sprint 都在做的事。 右移需要更多的基礎設施支撐：observability、feature flag、回滾機制。這些不是 QA 一個人能推動的，需要整個工程團隊一起建。 如果你的團隊現在什麼都沒有，我的建議是：先從左移開始。進需求討論這件事你明天就可以做，不需要任何工具。然後慢慢建 CI 自動化。右移的那些工具和機制，等左移的習慣穩定了再推。 結尾 「測試左移」這個詞被說爛了，但在很多團隊裡，測試還是在功能做完之後才開始。這不是 QA 的問題，是整個開發流程的預設設計。 改變這件事需要從流程上動手：參加需求討論、跟 RD 一起看 spec、讓 CI 跑自動化。這些不是一次就到位的，是慢慢往左邊推的過程。 右移則需要等你有了右移的基礎設施才有意義：監控、canary、rollback。這些建好了，上線不再是把東西丟進黑盒子祈禱，而是一個有觀測、有控制的過程。 左移減少問題在上線前漏掉，右移讓你在上線後早點知道出了什麼事。兩件事都值得做，從你現在能做的那個方向開始。 參考資料 DORA 2024 State of DevOps Report The Economic Impacts of Inadequate Infrastructure for Software Testing NIST TestPyramid Martin Fowler Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Jez Humble Google Testing Blog