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

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