Shift-left 之後，RD 變得更累，品質也沒有變好

Shift left 之後，RD 變得更累，品質也沒有變好 目錄 1. Shift left 的承諾 2. 但現實是這樣的 3. AI 程式碼讓問題更嚴重 4. 把測試推給 RD，但沒有給他們工具 5. Shift left 沒有錯，執行方式有問題 6. QA 在這裡能做什麼 Shift left 的承諾 這幾年業界最常聽到的測試趨勢就是 Shift left ：把測試往開發流程的左邊推，越早發現問題越便宜，越晚發現問題越貴。 這個邏輯沒有錯。一個在 code review 抓到的 bug，修復成本遠低於上線後才發現的同一個 bug——IBM 系統科學研究所的研究指出，在生產環境才修的 bug，平均成本是需求階段發現的 15 倍。所以我們要早測、要讓 RD 寫 unit test、要在 PR 階段就開始驗證。 Gartner 預測 2026 年 60% 的工程組織會採用 shift left，現實裡確實也有很多團隊往這個方向走。 然而，有一件事在這個趨勢裡被忽略了： 測試往左移，但 RD 的工作量沒有往左移。 但現實是這樣的 在一個採用 shift left 的團隊，一個 RD 的日常長這樣： 開發新功能 寫 unit test（因為現在這是 RD 的責任） Review AI 生成的程式碼（因為 AI coding tool 讓 PR 數量大增） 處理 flaky test（因為測試基礎建設還在追趕中） 跟 QA 對齊測試範圍（因為現在大家要「共同負責品質」） 每一件事單獨拿出來都合理，但全部疊在一起，RD 的認知負載已經超出了正常人能維持品質的上限。 結果呢？Unit test 寫了，但覆蓋率是假的——選最容易通過的 path 寫，hard case 跳過。PR 合併了，但有人真的看了嗎？Shift left 的精神在那裡，但執行變成了走流程。 AI 程式碼讓問題更嚴重 2026 年 AI coding tool 全面普及之後，一個新的數據讓人驚醒： 使用 AI coding tool 的開發者，每個月合併的 PR 數量多了約 60%——但這些 PR 裡的問題數量，是純人工撰寫的 1.7 倍。 意思是：程式碼產出速度快了，但問題密度也高了。 RD 在用 AI 快速生成功能的同時，也快速生成了更多潛在的 bug。而 shift left 的邏輯是「RD 要在早期自己把關」——但他們現在要看的程式碼量比以前多 60%，每一份又更容易有問題。 要 RD 在這個情況下維持原本的測試品質，本質上是在把一個已經超載的人再壓更多石頭。 把測試推給 RD，但沒有給他們工具 Shift left 失效的另一個原因，是「責任轉移了，但支援沒有跟著轉移」。 很多團隊說「測試是大家的責任」，實際的意思是： QA 依然負責找問題 RD 另外負責寫 unit test 但沒有人負責讓測試基礎建設穩定 沒有人負責定義「什麼叫做足夠的測試覆蓋率」 沒有人告訴 RD 哪些情境他們測不到、哪些要靠 QA 在責任不清晰的情況下，每個人都覺得別人應該管——最後沒有人真正在管。Capgemini《World Quality Report 2024 25》的調查印證了這個現象：超過半數受訪組織表示「測試責任邊界不清」是品質改善的首要障礙，這也解釋了為何 shift left 在許多團隊只停留在口號層面。 Shift left 沒有錯，執行方式有問題 我不是在說 shift left 是錯的。 早期介入確實有效，只是「早期介入」不等於「把所有測試工作都推給 RD」。 Shift left 真正有效的形式，是 QA 更早出現在開發流程裡 ，而不是消失掉： 在需求階段，QA 幫忙找 spec 的模糊地帶 在設計階段，QA 提出可測試性（testability）的考量 在開發階段，QA 定義驗收條件（acceptance criteria）讓 RD 有清楚的目標 在 PR 階段，QA 做輕量的確認，不是當守門人，是當同行評審 這樣的 shift left，RD 的認知負載沒有增加，但問題抓得更早。 QA 在這裡能做什麼 如果你的團隊也在走 shift left，但 RD 越來越累、品質沒有變好，你可以從這幾件事開始調整： 1. 把驗收條件寫清楚，讓 RD 不用猜 RD 寫測試寫不好，很多時候不是不想寫好，是不知道「什麼叫好」。如果 QA 能在開發前就把測試要驗的情境列出來，RD 的 unit test 品質會好很多。 2. 建立可以重用的測試工具，降低 RD 的進入門檻 如果寫測試很麻煩——環境設定複雜、測試資料難建立、跑一次要三分鐘——RD 自然會跳過。QA 可以做的是讓測試「容易跑」，而不只是要求「要跑」。 3. Flaky test 由 QA 負責處理，不要丟給 RD Flaky test 是測試信任度最快崩潰的來源。RD 跑測試跑到一半出現隨機失敗，他下次就不跑了。這個坑 QA 要自己填。 4. 定期跟 RD 對齊「這次誰測什麼」 不是要開很多會，而是要讓 RD 知道：這個功能 QA 會覆蓋，你不用測這些；這個邊界情境你要在 unit test 裡處理，因為 QA 的層級到不了那裡。 Shift left 的最終目標是讓品質更好，不是讓 RD 更累。如果達成了後者但沒達成前者，我們需要重新看一下到底哪裡走偏了。 參考資料 1. DORA 2024 State of DevOps Report — 關於 elite performer 在測試實踐和交付效率的研究數據 2. Capgemini World Quality Report 2024 25 — 全球品質趨勢調查，涵蓋 shift left 落地現況與測試責任分配問題 3. Martin Fowler — TestPyramid — 測試分層的基礎概念，說明各層測試的角色與比例 4. Google Testing Blog — Google 工程團隊在測試文化與實踐上的第一手分享 5. Shift Left Testing Strategy 2026 ContextQA — Shift left 執行模式與常見落地問題分析