PM 說測試時間砍一半，我沒有砍測試，我換了測試順序

PM 說測試時間砍一半，我沒有砍測試，我換了測試順序 目錄 1. 「測試能不能快一點」 2. 我第一次的解法：跳過「不重要」的 3. 風險矩陣不是理論，是做決定的工具 4. 我現在怎麼分類測試 5. 結尾 測試能不能快一點 那個 sprint 的最後兩天，PM 來跟我說：「這次 release 比原定時程提早三天，測試這邊能不能配合？」 我手上有大概 200 個測試案例，照正常速度跑完要四天。 三天砍成一天，意思是我只能跑四分之一的測試。 我第一個反應是：「我要跳過哪些？」這個問題問錯了。 根據 Capgemini《2024 25 年世界品質報告》， 超過半數 的組織表示時間壓力是導致測試品質下降的首要原因——但「縮短測試時間」和「提高測試投報率」，是完全不同的兩件事。前者是被動妥協，後者是主動決策。 第一次的解法 我當時的做法是：把我覺得「這個功能最近沒改過、應該沒問題」的測試跳掉。 直覺上說得通，但問題是「最近沒改」不等於「沒風險」。 那次 release 之後，有一個客訴是：我們的 App 的計時功能在特定條件下結束後，硬幣沒有入帳。那個功能的確很久沒改，但它依賴一個獎勵計算 API，而那個 API 在這次 release 裡被後端偷偷動了回傳格式。 我跳過了那個測試。 如果我當時問的不是「這個功能有沒有改」，而是「這個功能如果壞掉，影響有多大、觸發的機率有多高」，我會做出不同的判斷。 風險矩陣 Risk Based Testing 的核心只有一個公式： 兩個維度各分三級，組成一個 3×3 的矩陣： 高風險：一定要測，資源再少都不能跳 中風險：有時間就測，可以簡化測試步驟 低風險：最後才測，甚至可以跳 測試界廣為引用的 Pareto 原則指出， 約 80% 的缺陷集中在約 20% 的功能模組 。Risk Based Testing 的威力，在於讓那 20% 高風險區域得到不成比例的測試資源，而不是把有限時間平均分散在所有功能上。 這不是新概念，但真正有用的地方在於：它讓「跳哪些測試」從「我的感覺」變成「一個有依據的決定」。 現在怎麼分類 每次 release 前我會做一件事：看這次改動了什麼，然後重新評估每個測試的風險值。 影響程度怎麼判斷： 高：主流程（登入、付款、核心功能）、金錢相關、資料不可逆操作 中：次要功能、影響特定用戶群 低：UI 細節、非主流程的輔助功能 發生機率怎麼判斷： 高：這個模組這次有改動、依賴的 API 有異動、過去曾在這裡出過 bug 中：間接依賴的模組有改動 低：這個功能近期完全沒有異動，依賴穩定 我把這個評估做成一個簡單的試算表，每個測試案例三個欄位： 花在這個評估上的時間大概 30 分鐘，但這 30 分鐘決定了接下來幾個小時的測試重心放在哪。 一個關鍵習慣：「依賴異動」比「直接改動」更重要 我現在每次 release 前都會問後端：「這次改動有沒有動到其他模組依賴的 API 或資料庫欄位？」 很多時候 bug 出在「沒有直接改動、但依賴的東西改了」的地方。功能本身的程式碼一行都沒動，卻因為下游的資料格式變了就壞掉了。這類風險光看 changelog 是看不出來的，要問。 時間壓力下的現實取捨 那次 sprint 之後我做了個粗略統計： 200 個測試案例裡，高風險大約 40 個（20%），中風險 80 個（40%），低風險 80 個（40%）。 如果時間只夠跑一天，我會把所有高風險跑完，挑幾個影響大的中風險案例跑，低風險直接跳。 跑 40–50 個案例，但覆蓋了 80% 最有可能出問題的地方。 不是零風險，是 已知風險的決定 。 這個差別很重要。「隨機跳測試」和「根據風險決定跳哪些」，結果可能類似，但後者你知道你承擔了什麼、跳掉了什麼，出了問題也知道是哪個判斷的結果。這讓 QA 的工作從「感覺」變成「決策」。 結尾 現在有人跟我說「測試時間不夠」，我不會先問「能不能多一天」，我會先問「這次改動了什麼」。 改動範圍決定風險分布，風險分布決定我把時間放哪裡。 測試從來不可能做到百分之百覆蓋。有限時間內讓每一個測試的投報率最高，是 QA 需要主動去想的事，不是等主管告訴你怎麼取捨。 那個硬幣入帳的 bug，我後來把它加進高風險清單了。下次不管計時功能看起來多穩定，只要獎勵計算依賴後端 API，就是高風險。 踩過一次，記住一次。 參考資料 1. ISTQB — Risk Based Testing （官方術語與方法論）：https://www.istqb.org/ 2. Capgemini — World Quality Report 2024 25 （測試時間壓力與品質影響）：https://www.capgemini.com/insights/research library/world quality report 2024 25/ 3. Ministry of Testing — Risk Based Testing Explained ：https://www.ministryoftesting.com/articles/risk based testing 4. Google Testing Blog — Risk Based Testing at Google ：https://testing.googleblog.com/ 5. DORA — 2024 State of DevOps Report （測試實踐與部署穩定性的相關性）：https://dora.dev/research/2024/dora report/