QA 被叫做「擋路的人」：這個標籤怎麼來的，怎麼擺脫它

QA 被叫做「擋路的人」：這個標籤怎麼來的，怎麼擺脫它 目錄 1. 那次被 RD 說「你在擋我們」 2. 這個標籤怎麼來的 3. 讓 QA 從擋路者變成夥伴的幾件事 4. 結尾 那次被 RD 說「你在擋我們」 那個 sprint 的最後一天，我有三個 bug 還是 open 的，三個都是我認為需要修才能上線的問題。 下午五點，PM 的 Slack：「我們要在六點 release，這三個 bug 能不能先上？」 我說：「其中一個 Critical，我覺得要修。」 RD 的回應：「那個 bug 的觸發條件很少見，我這邊要改的話還要一個小時，能不能先上再說？你每次都這樣擋我們。」 「你每次都這樣擋我們。」 這句話讓我想了很久。 是我在擋他們，還是 bug 在擋他們？QA 回報問題，和 QA 製造問題，是完全不同的事。但為什麼 RD 的感受是「被 QA 擋」，而不是「被 bug 擋」？ 這個標籤怎麼來的 「QA 是擋路者」這個觀感，在業界出乎意料地普遍。Capgemini《World Quality Report 2024 25》的調查顯示，接近四成的開發人員認為 QA 流程拖慢了交付速度——但深入分析後，這個感受的根源往往不是 QA 發現了問題，而是問題被發現的時機和溝通方式出了問題。 「QA 是擋路者」這個觀感，通常來自幾件事： 1. QA 介入得太晚 功能做完了，RD 說「可以測了」，QA 才開始看。這個時候，所有的架構決策都已經定了，code 都寫完了，RD 已經在心理上認為「這個功能做完了」。 QA 這時候找到問題，在 RD 的感受裡是「倒退」——他以為完成了，現在又要重工。 如果 QA 在 spec 階段就介入，找到問題只是「討論」，不是「退版」。DORA 的研究顯示，在需求和設計階段就介入品質討論的團隊，其 change failure rate 比後期才介入測試的團隊低顯著幅度——早期介入不只省成本，也省了緊急修復帶來的信任損耗。 2. 每個 bug 都說很嚴重 如果 QA 開的 bug，severity 不分輕重，每個都說很重要，開發的反應就是：「他開的 bug 有多少是真的嚴重的？」 當你說「這個 Critical，必須修」，RD 的第一反應是查你的歷史：「他上次說 Critical 的是什麼？真的是嚴重的嗎？」 Severity 用壞了，你的判斷就失去信用。 3. 只報問題，不幫解決 「這個功能壞了，你修一下。」 還是：「這個功能在 X 情境下有 Y 問題，影響的是這些用戶，我有個方向可能是 Z，你覺得呢？」 前者讓 RD 覺得 QA 是在找麻煩；後者讓 RD 覺得 QA 是在幫忙解決問題。 4. 溝通的方式 「你的功能壞了」和「這個功能在某個情境下有問題，我想確認預期行為是什麼」，傳遞的資訊一樣，但前者讓人防衛，後者讓人合作。 讓 QA 從擋路者變成夥伴的幾件事 1. 更早出現在開發流程 最有效的改變是：在功能還在討論的階段就參與。不是要 QA 去管 RD 怎麼實作，是要在 spec 層面就把問題問清楚。 「這個情境下用戶如果做了 X，系統怎麼反應？」——這個問題在 spec 階段問，是幫助大家想清楚；在測試階段問，是在回報 bug。 2. 讓 Severity 有信用 Critical 只用在「主流程完全壞掉」。如果每次 sprint 你只有一兩個 Critical，開發會相信你說 Critical 是真的 Critical。 把真正不嚴重的問題老實標成 Low/Medium，這讓你的 High 和 Critical 有分量。 3. 先溝通，再開 ticket 不是所有問題都要立刻開成 bug。有些問題可以先問一句：「這個情境下的行為，是你預期的嗎？」 很多時候 RD 的回答是「喔，這個沒想到」，這就是在開 ticket 之前就解決問題。沒有 ticket，沒有統計，但也沒有「被 QA 擋」的感覺。 4. 給出你的判斷，而不只是問題 「這個 bug 的影響範圍是 X，嚴重程度是 Y，我的建議是 Z（上線/不上線/下個 sprint 修）」——這讓 PM 和 RD 知道你有在考量業務因素，而不是只追求「零 bug」。 你給的是建議，最終決定是 PM 做的。但你給出判斷的那一步，讓你從「回報問題的人」變成「幫忙決策的人」。 那次的結果 那個 Critical bug，我解釋了影響範圍（估計 10% 的用戶，特定條件觸發）和可能的後果（用戶資料有小機率損毀）。 PM 聽完問 RD：「修的成本是一小時？」 RD 說：「對。」 PM 說：「那修一下，七點 release。」 這次沒有拉鋸，因為資訊清楚了，決定就快。 RD 之後沒有再說「你在擋我們」，因為那次他看到的是：QA 給了一個清楚的風險評估，PM 根據那個評估做了決定，最後大家都接受。 那不是 QA 擋路，是 QA 幫忙做決定。 結尾 「擋路者」這個標籤，很多時候是溝通方式和介入時機的問題，不是 QA 這個角色本身的問題。 QA 找到問題，是他的工作。讓這件事對開發流程是助力而不是阻力，需要在什麼時候說、怎麼說、說什麼下功夫。 最難的部分不是技術，是讓人相信你和他們站在同一邊——你想讓產品好，不是想讓 release 延遲。這個信任是建立起來的，不是宣告的。 參考資料 1. Capgemini World Quality Report 2024 25 — QA 與開發協作的全球現況調查，包含 QA 角色感知數據 2. DORA 2024 State of DevOps Report — 高效能團隊的協作、文化與測試實踐特徵研究 3. Ministry of Testing — Articles & Resources — QA 職涯、溝通技巧與協作實踐的社群資源 4. Google Testing Blog — 測試文化、工程師協作與品質思維的實踐分享 5. ISTQB — Software Testing Certification — 測試工程師職能框架與產業標準參考