一個 QA 搭幾個 RD 才夠用？我的判斷依據

<h1 一個 QA 搭幾個 RD 才夠用？我的判斷依據</h1 <hr <h2 目錄</h2 <ol <li <p <a target=" blank" rel="noopener noreferrer nofollow" href=" %E6%B2%92%E6%9C%89%E6%A8%99%E6%BA%96%E7%AD%94%E6%A1%88" 沒有標準答案，但有判斷框架</a </p </li <li <p <a target=" blank" rel="noopener noreferrer nofollow" href=" %E4%BA%94%E5%80%8B%E5%9B%A0%E7%B4%A0" 影響這個比例的五個因素</a </p </li <li <p <a target=" blank" rel="noopener noreferrer nofollow" href=" %E9%85%8D%E6%AF%94%E6%BC%94%E8%AE%8A" 我們的 App 的配比演變</a </p </li <li <p <a target=" blank" rel="noopener noreferrer nofollow" href=" %E8%87%AA%E5%8B%95%E5%8C%96%E6%94%B9%E8%AE%8A%E6%96%B9%E7%A8%8B%E5%BC%8F" 自動化成熟度改變了這個方程式</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 你 Google「QA to developer ratio」，會找到各種數字：1:5、1:8、1:10、甚至 Google 說 1:15。</p <p Capgemini《World Quality Report 2024 25》的調查顯示，全球企業的 QA 與開發比例從 1:4 到 1:12 都有，差異主要取決於產品風險等級、自動化成熟度和發布頻率，而不是產業慣例。換句話說，沒有一個「標準比例」，只有「適合當下條件的比例」。</p <p 這些數字都沒有錯，也都沒有用，因為背後的條件差太多了。Google 有高度成熟的自動化基礎設施、有 SRE 在 production 把關、有數億用戶幫他們做 beta testing。你的團隊不是 Google。</p <p 更有意義的問題是：<strong 在你的產品、你的風險承受度、你的發布頻率下，現在的配比是否夠用？</strong </p <p 這個問題沒有辦法用一個數字回答，但可以用幾個指標來判斷。</p <hr <h2 五個因素</h2 <p <strong 1. 產品的複雜度和風險程度</strong </p <p 我們的 App 是一個 focus timer app，核心功能是計時、種樹、硬幣。這些功能對用戶造成的最大傷害是「計時沒有正確計算」或「硬幣沒有入帳」——糟糕，但不是災難性的。</p <p 如果你的產品是金融交易、醫療系統、或者有大量用戶資料的社交平台，同樣的配比完全不夠用，因為一個逃逸的 bug 的代價完全不同。</p <p <strong 2. 發布頻率</strong </p <p 每週發布和每個月發布，QA 的工作量完全不同。</p <p 每週發布意味著每次測試的時間視窗更短，自動化的比重必須更高，否則 QA 會成為瓶頸。每月發布有更多時間做手動探索性測試。</p <p 我們的 App 的節奏是雙週 sprint，這個頻率下 1 個 QA 對 4–5 個 RD 是大概可以維持的配比——但這建立在有一定程度的自動化回歸的基礎上。</p <p <strong 3. 自動化成熟度</strong </p <p 有完整的 CI 自動化回歸，每次 build 都跑完核心路徑：1 個 QA 可以覆蓋更多 RD，因為手動工作量被自動化分擔了。</p <p 完全手動、沒有自動化：1 個 QA 能覆蓋的範圍很有限，每次 release 都要從頭手動跑所有案例。</p <p <strong 4. 功能還是維護</strong </p <p 衝新功能的階段：每個 sprint 都有新功能要測，QA 的工作量高。</p <p 進入維護穩定期：主要是回歸測試，自動化能承擔大部分，手動工作量下降。</p <p 同樣的配比，在不同產品階段的壓力不一樣。</p <p <strong 5. Bug 逃逸率</strong </p <p 這是最直接的指標：如果你的 bug 逃逸率持續高於你的接受標準，是配比不足或測試策略有問題的信號。DORA 2024 研究指出，高效能交付團隊的變更失敗率（change failure rate）中位數約為 5%，而低效能團隊則超過 46%。Bug 逃逸率和變更失敗率高度相關，都是測試覆蓋與流程成熟度的直接指標。</p <p 如果逃逸率很低、QA 的工作量有明顯的 slack（空閒時間），可能是配比偏多。</p <hr <h2 我們的 App 的配比演變</h2 <p 早期（beta 版，小團隊）：1 個 QA，3 個 RD。 這個配比很緊，主要靠降低測試範圍和接受更高的 bug 逃逸率來平衡。</p <p 成長期（功能快速擴張）：1 個 QA，5 個 RD，引入第二個 QA。 這段時間最痛苦：需求量大、測試時間短、兩個 QA 還在磨合協作方式。</p <p 穩定期（現在）：2 個 QA，8 個 RD。 自動化回歸覆蓋核心路徑，手動測試集中在新功能和高風險情境，這個比例目前是可以維持的。</p <p 如果 我們的 App 開始做重大的架構調整或新平台（比如 Web 版、Android 版大改），這個配比需要重新評估。</p <hr <h2 自動化成熟度改變了這個方程式</h2 <p 1 個 QA 對 5 個 RD，在沒有自動化的情況下，是非常緊張的。但同樣的配比，如果有：</p <ul <li <p CI 每次 push 都跑 unit test</p </li <li <p 每次 release 自動跑核心流程的 E2E test</p </li <li <p API 層的 contract test 自動驗證格式</p </li </ul <p QA 的手動工作量大幅下降，可以集中在真正需要人工判斷的部分。</p <p 所以這個比例問題的正確解法，不是一直招 QA，而是：</p <ol <li <p 先投資自動化基礎設施</p </li <li <p 自動化成熟後，相同的人力可以覆蓋更多的開發產出</p </li <li <p 在自動化無法替代的部分（探索性測試、新功能、邊界情境），保留足夠的手動測試人力</p </li </ol <hr <h2 結尾</h2 <p 如果主管問「我們需要幾個 QA」，我的回答通常是：「取決於你能接受多少品質風險，以及你的自動化基礎設施有多成熟。」</p <p 這不是在迴避問題，是在說：配比是一個結果，不是一個起點。你先定義品質標準、先建自動化基礎設施、先評估風險，配比自然就出來了。</p <p 用一個固定數字配人，然後發現不夠用或太多，是從結果往回推的錯誤方式。</p <hr <h2 參考資料</h2 <ol <li <p <a target=" blank" rel="noopener noreferrer nofollow" href="https://www.capgemini.com/insights/research library/world quality report 2024 25/" Capgemini World Quality Report 2024 25</a — 全球 QA/RD 配比現況、自動化成熟度與測試人力規劃的調查報告</p </li <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://sre.google/sre book/eliminating toil/" Google SRE Book — Eliminating Toil</a — 自動化如何改變人力需求結構，以及 Google 的 SRE/RD 配比思維</p </li <li <p <a target=" blank" rel="noopener noreferrer nofollow" href="https://survey.stackoverflow.co/2024/" Stack Overflow Developer Survey 2024</a — 全球工程師對測試工作量、自動化比例與團隊組成的調查數據</p </li <li <p <a target=" blank" rel="noopener noreferrer nofollow" href="https://www.istqb.org/" ISTQB — Test Management</a — 測試資源規劃、風險導向測試策略與 QA 人力評估框架</p </li </ol <p </p