QA 怎麼量化自己的價值，給主管看的那種數字

QA 怎麼量化自己的價值，給主管看的那種數字 目錄 1. 「你們 QA 到底貢獻了什麼」 2. 無效的指標 3. 真正有意義的數字 4. 怎麼開始收集這些數字 5. 結尾 到底貢獻了什麼 那次季度 OKR 回顧，主管問了一句話：「你們 QA 這季做了什麼？」 我說：「測了 23 個功能，開了 178 個 bug，自動化覆蓋率提升到 42%。」 主管沉默了一下，說：「我問的是對產品的影響，不是你們做了多少事。」 我那時候沒有很好的答案。 後來我花了一段時間想這件事：主管在意的不是 QA 的工作量，是 QA 的存在讓產品的品質改善了多少、讓開發的成本降低了多少。這兩件事，工作量數字沒辦法說明。 根據 BetterQA 的研究， 在生產環境修復一個 bug 的成本，平均是測試階段的 15 倍、需求討論階段的 100 倍 。QA 的價值不在於「做了多少事」，而在於「在對的階段擋住了多少代價高昂的問題」——這才是主管想聽到的那種影響。 無效的指標 大部分 QA 在報告的指標，對主管來說資訊量很低： Bug 數量 開了 178 個 bug，聽起來很多。但主管想知道的是：這些 bug 如果沒有 QA 擋住，會造成什麼影響？178 個都是 UI 排版問題，和 178 個包含核心功能崩潰，是完全不同的事。 測試案例數量 寫了 500 個測試案例，跑了 300 個。這個數字沒有說清楚：500 個案例的密度夠嗎？跑了哪 300 個？沒跑的 200 個是否有風險？ 自動化覆蓋率 42% 的自動化覆蓋率——覆蓋的是哪 42%？如果覆蓋的都是低風險的 UI 操作，高風險的業務邏輯全部是手動的，這個數字沒有意義。 這些數字反映了 QA 的活動量，不反映 QA 的價值。 真正有意義的數字 1. Bug 逃逸率（Escape Rate） 上線後被用戶回報的 bug，相對於測試階段發現的 bug，比例是多少？ 我們的 App 的目標是把逃逸率控制在 10% 以下。這個數字讓主管理解：QA 在測試階段擋住了多少比例的問題。 逃逸率下降，代表 QA 的覆蓋越來越有效。逃逸率上升，代表某個地方出了問題——可能是測試時間被壓縮，可能是高風險功能沒有被優先測試。 根據 DORA 2024 年報告，Elite 等級的工程團隊 變更失敗率（change failure rate）低於 5% ，而低效能團隊則超過 46%。逃逸率是 QA 版本的這個指標——它說的是同一件事：你的品質保護，有多有效。 2. Bug 按嚴重程度的分布 逃逸的 bug 是什麼嚴重程度的？ 如果 Critical / High 的 bug 全部在測試階段被擋住，Medium / Low 的 bug 偶爾逃逸，這是可以接受的 trade off。 如果 Critical 的 bug 上線後才被發現，就需要檢討測試策略。 這個分布讓主管理解：QA 在有限資源下，是否優先保住了最重要的事。 3. Bug 發現的階段分布 每個 bug 是在哪個階段被發現的？ 需求討論階段（spec review） 開發完成 / code review 階段 測試階段 Staging / pre release 階段 上線後 越往左（越早）發現，修復成本越低。如果 QA 有在需求討論階段參與，這個分布應該會看到「spec 問題」的數字——這些是在還沒有一行 code 的情況下被擋住的問題。 4. 回歸 bug 率 同一個功能，修了之後又壞的比例是多少？ 這個數字衡量的是回歸測試的有效性。如果每次 release 都有功能是「修了又壞」，代表回歸測試的覆蓋不足，或者修 bug 的方式沒有徹底解決根本問題。 5. 關鍵路徑的自動化覆蓋率 不是總體覆蓋率，而是「核心業務流程」的自動化覆蓋率。 我們的 App 的核心路徑：登入 → 計時 → 種樹 → 硬幣入帳 → 訂閱購買。這幾條路徑有多少比例是有自動化覆蓋的？ 這個數字比「總體 42%」更有意義，因為主管能理解這些路徑的重要性。 怎麼收集 這些數字不需要複雜的系統，一張試算表就夠： Bug 逃逸率 ：每個 sprint 結束後，記錄測試階段發現的 bug 數，上線後在 Firebase Crashlytics 或用戶回報裡統計逃逸的 bug 數。 Bug 按嚴重程度分布 ：Jira / Linear 的 bug 都要標 severity，定期跑一個 query 就有分布圖。 Bug 發現階段 ：每個 bug 加一個自定義欄位「發現階段」，每次填 bug 的時候順手填。 回歸 bug 率 ：每次 release 後，統計有多少 bug 是「已修復功能再次出現問題」。 關鍵路徑自動化覆蓋率 ：先列出你定義的關鍵路徑，對照自動化 test suite，計算比例。 這些數字每個 sprint 收集一次，季度 review 的時候有趨勢圖，比任何工作量報告都說得清楚。 結尾 我現在每季報告的開頭是這樣的： 「這季我們的 bug 逃逸率從 18% 降到 9%，其中 Critical / High 的逃逸率是 0%。Core flow 的自動化覆蓋率從 35% 提升到 68%，預估每次 release 節省手動回歸測試時間約 4 小時。」 主管的回應是：「這樣說我看得懂。」 量化 QA 的價值不是在替自己辯護，是用數字讓主管能做更好的資源決策：多少人力投入測試是合理的、哪個地方的品質風險最高、測試基礎設施值不值得投資。 這些決策需要數字，而提供這些數字是 QA 自己的責任，不能等別人來問。 參考資料 1. BetterQA — Bug Fixing Costs Throughout the SDLC ：https://betterqa.co/bug fixing costs throughout sdlc/ 2. DORA — 2024 State of DevOps Report （change failure rate 與 DORA 四大指標）：https://dora.dev/research/2024/dora report/ 3. Capgemini — World Quality Report 2024 25 ：https://www.capgemini.com/insights/research library/world quality report 2024 25/ 4. Martin Fowler — Cannot Measure Productivity ：https://martinfowler.com/bliki/CannotMeasureProductivity.html 5. ISTQB — Glossary: Defect Escape Rate ：https://glossary.istqb.org/