怎麼改善公司品質

<h1 怎麼改善公司品質</h1 <p 工具換了一輪又一輪，測試框架從這個換到那個，品質還是一樣爛。</p <p 因為工具從來不是問題。問題是整個組織沒有把品質當成自己的事。</p <p 這些場景你一定見過：spec 寫完沒人維護、需求改了沒通知 QA、重構直接推上正式環境、業務邏輯沒有任何文件、測試只剩三天但版本有五個。</p <p 每一個看起來都像流程問題、時間問題、工具問題。但追到底，它們有一個共同的根源：整個團隊下意識地把品質當成 QA 的事。</p <p 開發改完就推、PM 改需求沒更新文件——不是因為他們不在乎，是因為在他們的認知裡，「品質的事情交給 QA 處理就好」。</p <p 這就是為什麼換工具沒用。你換再好的測試框架，spec 還是不會自己更新。你跑再多自動化，沒被通知的 hotfix 一樣繞過你。</p <h2 第一步：進入決策發生的地方</h2 <p 設計評審、架構討論、需求拆解會議——品質工程師要出現在這些場合，不是去把關，是去影響。提早發現模糊的需求比事後補 spec 快十倍。在架構還可以調整的時候指出可測試性問題，比功能完成後回頭重構便宜太多。</p <p Google 的做法是把測試工程師嵌入產品團隊的設計流程，當架構還在白板上的時候就開始問：「這個設計怎麼測？這個 API 如果回傳錯誤，誰負責處理？」可測試性不是事後 checklist，是設計條件之一。</p <p 以身作則也在這裡發生。你自己在 code review 留下品質相關的 comment、你自己把 test coverage 的討論帶進設計階段，別人才會開始意識到這是每個人的責任，不只是 QA 的清單。</p <h2 第二步：制定讓品質可持續的測試流程</h2 <p 光靠個人影響力不夠，需要結構來承載。Netflix 的 Chaos Monkey 是最有名的例子——他們不等 outage 才知道系統有問題，而是主動在正式環境裡隨機關掉服務，逼整個工程組織把故障容錯當成日常工作。工具只是手段，背後是「你自己的服務你自己負責穩定」的文化機制。</p <h3 從現狀盤點開始，不要從工具開始</h3 <p 多數團隊制定測試流程的方式是錯的——從「我們要用什麼工具」開始，而不是「我們現在最痛的地方是哪裡」。</p <p 先問幾個問題：現在的測試分布在哪幾層？最常漏掉的是什麼類型的 bug？測試環境最常在哪裡壞掉？找到最大的瓶頸，那就是改善的起點。</p <p Google 的測試金字塔是業界常用的分層起點——70% unit tests、20% integration tests、10% E2E tests。Unit test 成本低速度快，應該是主力；E2E test 慢且脆弱，只覆蓋最關鍵的核心路徑。比例不是教條，但思路是對的：越下層越穩越便宜，越上層越脆越貴。</p <h3 讓「進出條件」變成共識</h3 <p 流程要能運作，整個團隊必須知道規則是什麼。</p <p Entry criteria 是 PR 進到測試階段的前提，例如 unit test 全過、code review 完成、環境就緒。Exit criteria 是什麼狀態可以上線，例如 P0/P1 bug 歸零、regression suite 通過、效能指標在範圍內。</p <p 這兩件事講清楚，「直接推上正式環境沒通知 QA」的情況就有了可以對話的依據——不是抱怨，是流程定義。</p <h3 從最痛的地方開始推，不要一次改太多</h3 <p 導入新流程的最大阻力來自「改變需要成本」。</p <p 有效的方式是從最痛的瓶頸切入，先解決一個問題、展示成效，再擴大範圍。比如團隊最常抱怨 regression 跑很久，就先自動化最核心的幾條路徑，讓速度快起來，然後用這個成果去說服下一步的投資。</p <p 找到一兩個願意一起試的開發或 PM，讓他們成為流程改善的共同作者，而不是被推行的對象。</p <h2 第三步：讓不在乎品質的人開始在乎</h2 <p 這是最難的部分。</p <p NIST 的研究估算，在需求階段修一個 bug 的成本，到了正式環境之後會放大 30 倍。這個數字在主管面前比「品質很重要」有說服力得多——它把品質換算成他們能理解的語言：成本。</p <p 利害關係人管理不是去「教育」主管，是找到品質和他們在乎的事之間的連結。工程主管在意上線速度，就用數據說明品質問題怎麼拖慢速度。業務在意用戶留存，就把 bug 率和流失率放在同一張圖上。</p <p 溝通和談判在這裡是真實的技能需求。你能不能在一次 30 分鐘的會議裡讓 PM 同意在 sprint 計畫裡留出 QA 的時間，取決於你有沒有辦法讓他看見這件事對他有什麼好處。</p <h2 文化不是喊出來的</h2 <p 上游有你的聲音、組織有你建的機制、主管有你提供的決策依據——久了，品質就不再是 QA 部門的 KPI，而是整個團隊交付時理所當然的一部分。</p <p 這個轉變不是從換工具開始，是從你決定不再只是「執行測試的人」那一刻開始。</p