你的 QA 流程在哪個階段最浪費人力

你的 QA 流程在哪個階段最浪費人力 目錄 1. 把時間記下來之後，我嚇到了 2. 五個常見的浪費點 3. 怎麼診斷你的流程 4. 結尾 把時間記下來之後，我嚇到了 Capgemini《World Quality Report 2024 25》調查發現，QA 工程師平均只有不到 40% 的工作時間真正用在「執行測試」上，其餘時間消耗在環境準備、等待、溝通與重工。這不是少數人的困境，而是行業裡的普遍現象——只是很少有人把它記下來。 某個月我開始記錄自己每天的時間分配，粗略地：測試、寫測試案例、寫 bug report、等待（等 build、等環境、等 RD 回答問題）、溝通（Slack、會議）。 一個月後的結果： 測試：38% 等待：22% 溝通/補充說明：18% 寫測試案例：14% 寫 bug report：8% 我做 QA，實際在測試的時間只有 38%。超過 40% 的時間在等待和溝通。 這些數字不是 QA 個人效率的問題，是流程設計的問題。 五個常見的浪費點 1. 等 build 每次 feature 完成，要等 RD 打包 build，上傳到測試環境，確認環境沒有問題，QA 才能開始測試。 在 我們的 App，這個過程有時候要等半天。問題不在打包慢，在沒有 CI 自動觸發 build 和部署——每次都是 RD 手動操作，有時候忘了，有時候環境有問題，來來回回。 改善方法：PR merge 自動觸發 CI build + 部署到 staging。QA 不需要問「build 好了嗎」，有通知就知道可以測了。 2. 環境問題 Staging 環境的資料狀態不一致、服務偶爾掛掉、測試帳號的前置條件需要手動設定——這些加起來，每次測試開始之前要花 15–30 分鐘準備環境。 我們的 App 有幾個測試情境需要「全新帳號，沒有種植紀錄」，每次我都要手動建一個新帳號。後來我們建了一個 seed script，一行指令重置測試帳號到指定狀態。 省下來的時間不多，但累積起來每個 sprint 大概省 2–3 小時。 3. Bug report 的來回溝通 每次開完 bug，RD 問：「你的環境是什麼？」「你能不能再操作一次讓我看？」「你的 App 版本是幾？」 這些資訊本來應該在 bug report 裡，但如果每次都要被問，代表 bug report 的格式不夠完整。 改善方法：建立 bug report 模板（前置條件、步驟、實際結果、預期結果、環境資訊），每次開 bug 都按這個格式填。 前面我有一篇文章專門寫這個。來回溝通的時間，我後來大幅降低了。 4. 重工：功能做了才發現 spec 問題 有幾次，功能做到一半，QA 測試的時候發現 spec 有模糊地帶，RD 不知道那個情況應該怎麼處理，停下來等 PM 確認，PM 確認後 RD 修改實作，QA 重新測試。 這個來回有時候要花兩三天。 改善方法：QA 在 sprint 開始就參與 spec review，把模糊地帶提前消滅。這個成本是每個 sprint 多花 30 分鐘，但省掉的重工往往是好幾倍。 5. 手動回歸 每次 release 前跑一遍回歸測試，涵蓋所有主要功能。如果全手動，我們的 App 大概要 6–8 小時。DORA 2024 的研究顯示，在高效能交付團隊中，回歸測試的自動化比例明顯更高，這是讓測試窗口可以縮短而品質不下降的關鍵槓桿之一。 自動化回歸把核心路徑覆蓋了之後，手動回歸縮到 1.5 小時，而且覆蓋範圍更穩定、更完整。 剩下的 6–7 小時，可以用在真正需要人工判斷的探索性測試。 怎麼診斷你的流程 不需要精確的時間追蹤，幾個簡單的問題就能找到浪費點： 1. 每個 sprint，你花最多時間在什麼非測試的事情上？ 2. 你最常在 Slack 上被問或問別人的是什麼問題？ （反映了哪些資訊沒有被系統化） 3. 測試開始之前，你需要手動做哪些準備工作？ 4. 你最常因為等待而中斷測試的是什麼？ 5. 每次 release 前，有沒有「我沒有時間測，但應該要測」的感覺？哪些功能？ 這五個問題的答案，會指向你的流程裡最大的浪費點。每個問題對應的改善方向： 1. 非測試事務 → 看能不能自動化或建立自助流程 2. 常見 Slack 問題 → 建立文件、template 或 wiki 頁面 3. 準備工作 → seed script、環境自動化 4. 等待 → CI/CD 自動化、通知機制 5. 測試不完 → Risk Based Testing，配合自動化回歸 結尾 那個月我把時間記錄拿給主管看，他看了 22% 的等待時間之後說：「這個可以改善。」 三個月後，等待時間降到了 9%。不是因為我工作更努力，是因為我們改善了 CI 自動部署、建立了 bug report 模板、寫了 seed script。 QA 的效率問題，90% 是流程問題，不是人的問題。人再努力，如果流程在浪費時間，效果有限。找到流程的瓶頸，一個一個改，比要求 QA 「更認真」有用得多。 參考資料 1. Capgemini World Quality Report 2024 25 — QA 時間分配、自動化採用率與流程效率的全球調查 2. DORA 2024 State of DevOps Report — 自動化測試比例與軟體交付效能的相關性研究 3. Google Testing Blog — Test Infrastructure — CI/CD 自動化與測試環境管理的工程實踐 4. Martin Fowler — Continuous Delivery — 持續交付中的流程設計與浪費消除原則 5. Ministry of Testing — Process Improvement — QA 流程優化的社群實戰案例與方法論討論