測試策略怎麼跟 PM 對齊？從需求會議就開始的 QA 工作

測試策略怎麼跟 PM 對齊？從需求會議就開始的 QA 工作 大多數 QA 的工作從「開發完成，請測試」才開始。這是一個代價很高的習慣。 IBM Systems Sciences Institute 的研究數據經常被引用：在需求階段發現的缺陷，修復成本是生產環境的 1/100 。這不只是數字，是一個系統性問題——QA 越晚介入，可以改變的空間越小，只剩下「找出問題」的角色，沒有「預防問題」的機會。 這篇文章談的是：QA 要怎麼在與 PM 的對話中，把測試策略嵌進去，而不只是等需求文件寫完再說。 為什麼 PM 和 QA 容易對不上 PM 思考的是： 功能能不能上線？用戶能不能用？ QA 思考的是： 哪些情況下它會壞？ 這兩個視角天然有張力。PM 傾向樂觀估計（功能完成就好），QA 傾向悲觀估計（找到所有邊界情況）。沒有共同語言，這個張力會變成衝突：QA 覺得 PM 不重視品質，PM 覺得 QA 在阻礙進度。 解法不是說服對方接受自己的視角，而是找到共同的衡量框架—— 風險 。 以風險為基礎的對話 在需求會議中，QA 能帶入的最有價值的視角是：「如果這個壞了，影響是什麼？」 這個問題把討論從「功能是否完整」拉到「失敗的代價」，PM 自然會參與進來，因為這直接影響他的 OKR 和用戶滿意度。 實際操作： 用一個簡單的風險矩陣來分類功能： | 風險等級 | 發生機率 | 影響程度 | 測試策略 | | | | | | | 高 | 高 | 高 | 全面自動化 + 手動探索 + 上線監控 | | 中 | 低 | 高 | 手動測試 + 關鍵路徑自動化 | | 低 | 高 | 低 | 煙霧測試 + 回歸測試 | | 可忽略 | 低 | 低 | 不測試或樣本抽測 | 「金流結帳」屬於高風險——出錯直接影響營收，值得投入大量測試資源。「個人偏好設定的排序」屬於低風險——出錯頂多讓用戶不方便，不需要完整測試套件。 把驗收條件寫得可以測試 需求文件上最常出現的問題不是太少資訊，而是資訊 無法量化 ： ❌「系統要夠快」→ 多快？在什麼設備？多少並發用戶？ ❌「結帳流程要流暢」→ 流暢的定義是？步驟數？錯誤回饋時間？ ❌「要符合用戶期望」→ 哪些用戶？什麼期望？如何驗證？ Mike Cohn 在《User Stories Applied》中強調，好的驗收條件（Acceptance Criteria）應該是 SMART 的——Specific、Measurable、Achievable、Relevant、Time bound。 QA 可以在 Sprint Planning 或需求釐清會議中，主動把模糊的條件轉換成具體的測試場景： PM 說： 「結帳流程要順暢」 QA 問： 「我們可以把『順暢』定義成：在標準 4G 網路下，從加入購物車到訂單確認頁面不超過 3 秒，且錯誤訊息要在 500ms 內顯示嗎？」 這個問題不是在刁難，而是在幫 PM 把隱性的期望變成可以驗證的標準。做不到這個標準，大家早點知道比上線後才發現好。 三個問題，在需求會議就要問 QA 帶著這三個問題進需求會議，就能把測試策略的根基打好： 1. 「最壞的情況是什麼？」 這個問題讓 PM 思考失敗場景，也讓你了解這個功能的風險等級。 金流失敗？用戶資料遺失？功能不能用？這些答案決定了你需要投入多少測試資源。 2. 「什麼情況下我們會回滾（Rollback）這個功能？」 這是個很實際的問題，卻很少人問。回滾條件不清楚，上線後遇到問題時，工程、PM、QA 會花大量時間在「這算嚴重嗎」上面爭論。 先定義回滾條件，等於提前定義了「可接受的品質下限」。 3. 「這個功能影響哪些現有功能？」 PM 通常聚焦在新功能本身，QA 的職責是想到橫向影響。改了購物車邏輯，會不會影響優惠券計算？新增了用戶角色，會不會影響現有的權限控制？ 這些問題在需求階段問，成本是一次討論。在上線後才發現，成本是一次事故。 讓 PM 看到測試的商業價值 技術語言讓 PM 覺得 QA 是「技術部門的事」。要讓 PM 重視測試策略，需要轉換語言。 不說： 「我們需要更多的測試覆蓋率。」 說： 「目前這個功能沒有自動化測試保護，如果下次改動觸發回歸，我們可能要多花兩天才能找到原因。」 不說： 「這個需求不夠明確，無法測試。」 說： 「這個驗收條件有兩種解讀方式，我列出來，你確認哪個是我們要的——這樣我才能設計正確的測試場景，也避免上線後發現方向不對。」 Atlassian 的研究顯示，開發團隊花在修復 bug 上的時間平均佔總工作時間的 25% 。把這個數字換算成人力成本給 PM 看，測試策略的投資立刻變得具體。 上線後：把監控納入策略 測試策略不應該止於上線。好的 QA 會在需求階段就跟 PM 談： 上線後怎麼知道這個功能是好的？ 需要追蹤哪些指標？（轉換率、錯誤率、響應時間） 異常閾值是什麼？（錯誤率超過 1% 要警報） 誰負責監控？ 把這個對話在需求階段就展開，PM 才會把監控需求納入功能定義，而不是上線後才發現沒有足夠的可觀測性。 結語 測試策略跟 PM 對齊，本質上是語言的轉換：把測試的語言翻譯成風險、成本、用戶體驗的語言。 QA 最大的槓桿不是在測試階段找到更多 bug，而是在需求階段把模糊變清晰，把風險講明白，把驗收標準定下來。 這樣做，你就不再是「測試的人」，而是「讓功能定義更精準的人」。 延伸閱讀： Mike Cohn — User Stories Applied (2004) IBM Systems Sciences Institute — Relative Cost of Fixing Defects (引用自 Barry Boehm 研究) Atlassian — The True Cost of Bugs (2019) Janet Gregory, Lisa Crispin — More Agile Testing (2014) 參考資料 Mike Cohn — User Stories Applied: For Agile Software Development — Acceptance Criteria 寫法與 QA 配合的標準參考 ISTQB — Test Strategy and Planning — 測試策略制定的國際標準框架 Agile Alliance — Definition of Done — DoD 的定義與團隊共識建立方式 Elisabeth Hendrickson — Test Heuristics Cheat Sheet — 測試覆蓋邏輯的速查工具 Three Amigos — Agile Alliance — PM、RD、QA 需求對齊的實踐方法