QA 從零建立：新創公司沒有 QA 流程，第一件事做什麼

QA 從零建立：新創公司沒有 QA 流程，第一件事做什麼 目錄 1. 「我們之前都是 RD 自己測的」 2. 常見的錯誤起點 3. 正確的順序 4. 三個月能建好的基礎 5. 結尾 「我們之前都是 RD 自己測的」 這是很多新創公司的狀況：產品做起來了，用戶增加了，bug 開始讓人頭痛，所以招了第一個 QA。根據 Capgemini《World Quality Report 2024 25》，超過 55% 的中小型組織沒有正式的 QA 流程——而在這些組織中，品質問題往往要等到用戶開始流失，才被視為需要優先處理的事。 第一個 QA 最常遇到的情況是：沒有 test case、沒有 bug tracking 流程、RD 和 PM 對「什麼是 QA 的工作」有各自不同的理解，而且大家都期待 QA 能「馬上解決品質問題」。 這個期待和現實的落差，讓很多第一個 QA 在前三個月就精疲力竭，或者做了很多沒有長期價值的事（寫了一千個 test case、建了複雜的自動化框架，但流程還是很混亂）。 常見的錯誤起點 錯誤一：先建自動化 「我們需要自動化測試」——這句話沒有錯，但第一個月就建自動化是錯誤的優先級。 自動化需要：穩定的功能（還在快速迭代的功能，自動化維護成本極高）、清楚的測試策略（要自動化什麼）、基礎的 CI/CD 設施。 這些在新創的第一個月通常都不成熟。先建自動化的結果是：花了大量時間建了一套自動化，但功能一直在改，維護成本高，最後棄用。 錯誤二：先寫大量 test case 「我要把所有功能的 test case 都整理出來」——聽起來很負責任，但如果功能還在快速變動，test case 寫完可能就過期了。 先寫 test case 的問題：沒有測試什麼是最重要的判斷標準，可能花了一週在整理低風險功能的 test case，高風險的地方反而沒有覆蓋。 錯誤三：嘗試一次解決所有問題 「我要把 bug tracking、test planning、release 流程全部建好」——這需要整個團隊的配合，不是 QA 一個人能推動的。 嘗試一次改太多事，每件事都沒有做透，效果不彰，還容易在團隊裡留下「QA 在搞很多行政作業」的印象。 正確的順序 第一個月：理解現狀，找到最大的痛點 讀完所有現有的 bug report（不管在哪裡） 訪談 PM 和 2–3 個 RD：「過去最常讓用戶抱怨的是什麼？」「哪個功能最容易出問題？」 把自己當成新用戶，完整體驗一遍產品 不要馬上開始改流程，先觀察 輸出：一份「高風險區域清單」，列出哪些地方最容易出問題。 第二個月：建立最小可用的流程 從最小的地方開始： 1. Bug tracking：選一個工具（Jira / Linear / Notion），建立統一的 bug report 格式（前置條件、步驟、實際結果、預期結果、環境） 2. 每個 release 前的 smoke test：5–10 個最核心的手動確認點，每次 release 前跑完 3. Severity 標準：定義 Critical/High/Medium/Low 的判斷標準，讓大家對齊 這三件事，不需要說服很多人，是 QA 自己能直接做的。 第三個月：高風險功能的測試覆蓋 根據第一個月建的「高風險區域清單」，優先設計那些區域的測試案例。 不是全部功能都覆蓋，是最容易出問題的 20% 的功能，先有系統性的覆蓋。 三個月能建好的基礎 結束三個月後，你應該有： 統一的 bug report 格式，大家都在用 每個 release 前跑的 smoke test checklist 高風險區域的測試案例（不是全部功能，是最重要的那些） 一份你知道哪些地方是弱點的「已知風險清單」 和 PM/RD 的基本信任：他們知道你在做什麼，你的 bug report 有可信度 這個基礎建好之後，自動化、更完整的 test suite、更系統的流程，才有穩固的地方可以長。 在這個基礎建好之前就去蓋自動化，是在沙地上蓋房子。 我們的 App 的情況 我加入 我們的 App 的時候，前半年是唯一的 QA。 我做的第一件事：把過去一年所有用戶回報的 bug 整理成清單，按照「同一個功能出現幾次問題」排序。 結果很清楚：訂閱相關的邏輯問題佔了 34%、計時器計算錯誤佔了 28%、帳號同步問題佔了 21%。 這三個區域佔了 83% 的用戶問題，但加起來只有全部功能的 15%。 前三個月我只做了一件事：把這三個區域的測試案例建完，讓每次 release 之前這些地方一定有被覆蓋。 bug 逃逸率在第四個月開始下降。不是因為我測了更多，是因為我測了更對的地方。DORA 的長期研究驗證了這個邏輯：有系統性測試覆蓋的團隊，部署頻率和系統穩定性反而高於那些跳過測試直接追求速度的團隊——品質和速度不是對立的，有效的測試策略讓兩者同時改善。 結尾 在沒有 QA 流程的公司建立 QA，最重要的不是帶進最好的工具或最完整的方法論，是找到「做什麼能讓品質最快改善」，然後只做那件事。 先找痛點，再建流程，再擴大覆蓋。這個順序違背了很多人「先建好基礎再開始做事」的直覺，但在資源有限、功能快速變動的新創環境，它是唯一現實的路徑。 參考資料 1. DORA 2024 State of DevOps Report — 測試覆蓋、部署穩定性與交付效能的長期研究數據 2. Capgemini World Quality Report 2024 25 — 中小型組織 QA 流程成熟度與品質挑戰的全球調查 3. Ministry of Testing — Articles & Resources — QA 從零建立、流程設計與測試策略的社群實踐分享 4. Google Testing Blog — 測試優先級、風險導向測試策略的工程實踐 5. ISTQB — Software Testing Certification — 測試流程建立、風險導向測試與測試計畫的標準框架