QA 測試的第一週結束後,一位產品經理問了一個看似簡單的問題:「品質有沒有變好?」

誘惑是打開儀表板,找幾個數字,然後立刻回答。發現了五個缺陷。迴歸測試耗時 26 分鐘。一個版本完成測試。有幾個測試持續穩定通過。這些數字看起來可以衡量,但只過了一週,它們還不一定能呈現出趨勢。好的 QA 指標不是把每一格都填上數字,而是收集最終能支持一個可靠結論的證據。

四項測試指標

這張表點出了四個實用的起始指標:缺陷密度、缺陷逃逸率、測試執行時間與不穩定率(flaky rate)。它們共同檢視品質的不同面向。缺陷密度關心的是:相對於程式碼變更量,出現了多少缺陷。逃逸率問的是:有多少缺陷撐過了測試、抵達了使用者面前。執行時間衡量迴歸回饋能多快產出,而不穩定率則揭示測試本身值不值得信任。

第一個挑戰是選出能回答有用問題的指標。單純數 bug 可能造成誤導。假設 A 團隊在變更 50,000 行後找到 20 個缺陷,而 B 團隊只變更 2,000 行就找到 10 個。只憑缺陷數就說 A 團隊「品質問題比較多」,忽略了變更規模的差異。缺陷密度正是為了把這種比較正規化,將缺陷與變更的程式碼量聯繫起來。

但這帶出第二個挑戰:定義必須保持一致。什麼算一個缺陷?重複的算不算?重新開啟的議題算一次還是兩次?「變更行數」指的是新增行、新增加刪除行,還是整個受影響的檔案?對缺陷逃逸率而言,「發布後」是只指生產環境,還是在 release candidate 中發現的缺陷也算逃逸?

兩位工程師可以用同一個指標名稱,卻因為定義不同而得出完全不同的數字。計算可能在數學上正確,比較卻在概念上無效。因此,一個指標需要的不只是公式;它需要穩定的定義、來源、收集方法與量測期間。

當團隊開始比較不同週次時,這一點尤其重要。想像缺陷逃逸率在第一週用生產環境缺陷計算,第二週卻用生產環境加 UAT 缺陷計算。儀表板可能顯示品質正在下滑,儘管產品的實際行為並沒有什麼有意義的變化。一致性讓指標可比較;沒有一致性,歷史圖表可以在沒有證據的情況下製造信心。

第一週的問題

現在回到原本的問題:第一週之後,品質有沒有變好?

最準確的答案可能是:目前還沒有足夠的證據判定趨勢。

這不是 QA 量測的失敗,而是負責任的報告。

表格清楚地展示了這一點。一週內收集到的五個缺陷,樣本太小,無法建立有意義的缺陷密度。一個版本提供的證據不足以支撐可靠的逃逸率趨勢。三次重跑提供了對測試穩定性的早期觀察,但歷史還不夠,無法有信心地刻畫整套測試的不穩定率。與其編造百分比,這份報告正確地記錄了**「尚未確定」**,並標明樣本過小。

測試執行時間稍有不同。兩次迴歸執行產出了 26 分鐘的示例耗時。這作為初步的基線資料是有用的,但不應該立刻變成效能目標。也許接下來幾次會因為基礎設施負載或測試資料的差異,分別跑出 24、38 和 29 分鐘。在決定「正常」的執行時間究竟是什麼意思之前,需要更多觀察。

這個區別之所以重要,是因為儀表板常常帶來「把空格填滿」的壓力。QA 工程師可能在一個版本之後就算出「0% 逃逸率」,並把它當作品質優異的證據。嚴格來說,目前確實還沒有通報的逃逸缺陷——但一個版本加上幾天的觀察,無法確立流程正在改善。「觀察到零個缺陷」並不自動等於「零品質問題」的證明。

因此,第一週之後,QA 報告的重點應該是建立基線,而不是宣告改善。它可以說:基於兩次觀察到的執行,迴歸目前約耗時 26 分鐘;初始量測期間記錄了五個缺陷;而缺陷密度、逃逸率與不穩定率現有的樣本,還不足以進行趨勢分析。

*「品質有沒有變好?」*這個問題的真正答案,會隨時間越來越有用。一旦多個版本、多次 CI 執行、多次程式碼變更與發布後的觀察,都能用相同的定義來量測,QA 就能比較不同期間,尋找有意義的變動。

這才是品質指標的目的:不是讓儀表板看起來完整,而是讓變化變得可見。當證據還不成熟時,「尚未確定」往往是比一個資料還撐不起來、卻看起來精確的數字,更專業的 QA 結果。