為什麼加快 release 頻率之後，bug 反而變多了

為什麼加快 release 頻率之後，bug 反而變多了 目錄 1. 「我們要兩週一次 release」 2. 加快之後發生了什麼 3. 根本原因不是 QA 測不完 4. 怎麼在快速 release 裡維持品質 5. 結尾 「我們要兩週一次 release」 根據 DORA 2024 研究，頂尖的軟體交付團隊（Elite performers）部署頻率比低效能團隊高出 182 倍，但變更失敗率卻低 3 倍。速度和品質不必然衝突——問題是，大多數團隊只調整了發布頻率，卻沒有同步調整讓速度可持續的那些流程。 那次決策是 PM 推動的。 原本 我們的 App 大概六到八週發一次版，PM 說用戶反饋太慢，競爭對手動作更快，要改成雙週 sprint，sprint 結束就 release。 從工程側來說，這個決策沒有問題。雙週發版是很正常的節奏，許多成熟的產品都在這個頻率。 問題是：發版頻率變成兩倍，但測試資源沒有跟著變成兩倍，測試流程也沒有重新設計。 加快之後發生了什麼 第一個月，我們沒有感覺到太大的問題，因為功能還在開發，測試的東西不多。 第二個月，sprint 的功能量恢復正常，但測試窗口從本來的兩週縮成了四天。 我開始每個 sprint 末都在趕：高風險的功能能測完就好，回歸的部分能跳就跳。 接下來兩個月的 bug 逃逸率從 8% 上升到 19%。 主管問：「為什麼 bug 變多了？」 我說：「測試時間不夠。」 主管說：「那 release 頻率是問題嗎？」 這個問題問得好。release 頻率本身不是問題，是問題的起點。 根本原因不是 QA 測不完 「加快 release → 測試時間少 → bug 逃逸增加」這條線看起來很直接，但它是症狀，不是根本原因。 根本原因是： 加快 release 頻率，意味著整個開發流程都需要調整，不只是「測試時間縮短」這一件事。 當 release 頻率提高，有幾件事需要同時發生： 自動化回歸必須跟上 雙週發版，你沒有時間每次手動跑完所有回歸測試。如果沒有自動化回歸，要維持相同的測試覆蓋，你需要兩倍的 QA 人力。 我們的 App 加快 release 頻率的時候，自動化回歸只覆蓋了核心路徑的 35%。那 65% 是手動的，每次 release 都需要手跑，在四天的測試窗口裡根本跑不完。 QA 要更早介入 開發後期才介入測試，問題發現得晚，修復需要時間，壓縮了測試窗口。 雙週 sprint 要能順暢運作，QA 必須在 sprint 開始就參與 spec review，在開發中期就開始測試已完成的部分，而不是等所有功能做完才開始。 Feature freeze 的時機要改 以前 release 前三天才停止新功能，加快 release 之後這個緩衝根本不夠。 我們後來把規則改成：sprint 最後五天不合新功能，只允許 bug fix。這讓測試有穩定的目標，不會測到一半又有新東西進來。 Definition of Done 要包含「可測試」 Capgemini《World Quality Report 2024 25》指出，超過 55% 的測試延誤源自「功能名義上完成，但測試環境或前置條件尚未就緒」。這個問題在壓縮測試窗口的情況下會被放大，幾天的測試窗口，有一天消耗在等環境，損失的是整個 sprint 的品質緩衝。 RD 說「功能做完了」，不代表它已經可以進入測試流程。如果沒有 staging 環境的資料、API 還需要依賴未完成的其他模組、缺少測試帳號的前置條件——這個功能對 QA 來說還不算「可測試」。 這個定義在測試窗口短的情況下特別重要，一個功能等了兩天才能測，就耗掉了一大段測試窗口。 怎麼維持品質 我們後來做了幾件事，讓雙週發版的品質回到可接受範圍： 1. 核心路徑全部自動化 花了兩個 sprint 把核心的種樹流程、帳號登入、IAP 購買自動化。這三條路徑加起來覆蓋了大約 60% 的最高風險情境，現在每次 build 都自動跑，節省了手動回歸的大半時間。 2. 手動測試集中在新功能和高風險區域 每個 sprint 的手動測試，我只測「這個 sprint 新增或修改的功能」加上「歷史上曾經出過 bug 的高風險區域」。穩定的功能交給自動化，手動的精力放在最值得的地方。 3. 建立快速的 smoke test checklist release 前一小時，5 分鐘內跑完 10 個最關鍵的手動確認點。不是完整測試，是確認「基本功能沒有爛」的最後一道防線。 4. Bug 逃逸做事後分析 每個上線後被回報的 bug，我都會問：「這個 bug 是在哪個阶段本可以被抓到的？」 這個分析幫助我們不斷調整優先級——哪些功能下次需要更認真測，哪些自動化的覆蓋有缺口。 結尾 加快 release 頻率之後 bug 變多，是很多團隊都會經歷的過程。原因通常不是「QA 測不夠認真」，是整個開發流程在加速之後，每個環節都需要重新調整，但通常只有 release date 被調整，其他的沒有。 兩倍的 release 頻率，需要的不是兩倍的 QA 人力，而是自動化成熟度、流程調整、和更早的 QA 介入。這些投資的成本在前期，但長期換來的是在更快的節奏下維持穩定的品質，而不是速度和品質之間永遠的拉鋸。 參考資料 1. DORA 2024 State of DevOps Report — Elite 團隊與低效能團隊在部署頻率、變更失敗率上的實證對比 2. DORA — Deployment Frequency — 部署頻率作為軟體交付效能指標的研究說明 3. Capgemini World Quality Report 2024 25 — 全球測試現況，含快速發布週期下的品質挑戰 4. Martin Fowler — Continuous Integration — CI 的核心原則與快速 release 的前提條件 5. Google SRE Book — Release Engineering — Google 如何在高頻部署下維持穩定性的工程實踐