為什麼 RD 把你當路障？QA 如何從被防禦變成被信任

為什麼 RD 把你當路障？QA 如何從被防禦變成被信任 目錄 1. 那個讓我第一次意識到問題的時刻 2. RD 把 QA 當路障的根源 3. KPI 衝突：我們天生站在對立面 4. 五件事讓 RD 開始信任 QA 5. 信任建立之後，工作會變成什麼樣子 那個讓我第一次意識到問題的時刻 有一次我回報一個 bug，RD 的第一反應不是「謝謝，我看一下」，而是：「這個有影響到什麼嗎？一定要修嗎？」 當下我有一點愣住。 後來我才慢慢理解，那個問題背後的意思是：「你又來了，我快上線了，你找的東西是真的有問題還是在為難我？」 那不是一個壞的 RD，那是一個對 QA 的信任已經被消耗殆盡的 RD。 而那個時候的我，還沒搞清楚這件事是怎麼發生的。 RD 把 QA 當路障的根源 這個關係的破裂，通常不是因為哪一次衝突，而是長時間累積的結構性問題： QA 太晚進場 RD 把功能寫完，覺得自己做完了。這時候 QA 進來，找到一堆問題，要他改。他的感受不是「QA 幫我抓到了問題」，而是「我以為完成了，但 QA 說我沒完成」。 每次都這樣，RD 自然開始把 QA 跟「又要重工」連結在一起。 Bug report 品質不好 如果 QA 回報的 bug 有一半是環境問題、或是「我在這台手機上復現不了但你去試試看」，RD 會花大量時間去追一個不存在的問題。追了幾次，他就學會了：先防禦，再看。 QA 找到 bug 好像在「贏」 有一種不健康的團隊文化，是 QA 找到 bug 被當成「績效」，而 RD 的 bug 被拿出來討論好像是在展示他的失敗。在這種文化下，bug 變成一場比賽，而不是大家一起解決的問題。 從來沒有人定義過共同的目標 開發團隊有 feature 交付速度的壓力，QA 有品質的要求，但這兩件事有沒有被整合成同一個目標——「在這個時間點交付這個品質的功能」——很多團隊其實沒有清楚說過。 目標不一致的時候，協作很容易變成對抗。 KPI 衝突：我們天生站在對立面 這個問題更深層的原因是： RD 和 QA 的績效評量標準天生是衝突的。 根據 Capgemini《2024 25 年世界品質報告》，有超過半數的受訪組織表示，QA 與開發團隊之間的目標不一致，是品質問題的主要來源之一。這種結構性衝突，在沒有共同品質目標的團隊中幾乎無可避免。 在這個框架下： RD 越快上線，得分越高 QA 越多找到 bug，得分越高 所以 QA 的「成功」，在 RD 眼裡就是「讓我上不了線」 這不是個人問題，是系統設計的問題。但系統不是你我能馬上改變的，可以改變的是你怎麼在這個系統裡讓關係變好一點。 五件事讓 RD 開始信任 QA 1. 早點出現，不要只在 bug 出現的時候出現 RD 對 QA 的印象是「那個在最後來踩煞車的人」，是因為 QA 確實只在最後出現。 如果你能在需求討論就問一句「這個情境如果用戶做了 X 怎麼處理？」，RD 會開始感覺到你是在幫他想，而不是在等他犯錯。 早點進場不需要多做很多事，是需要在對的時間點出現。 2. Bug report 要讓 RD 一眼知道嚴重程度 RD 看到 bug report 最需要知道的是：這個東西我現在要放下手邊的事嗎？ 標題要說清楚影響範圍，不要只說「XXX 功能有問題」。好的標題：「訂閱用戶在 iOS 16 以下無法完成購買（100% 復現）」——他看完標題就知道嚴重性和影響對象。 複現步驟要精確，裝置和版本要寫。不能複現的 bug，對 RD 來說等於沒有 bug。 3. 區分「我回報的」和「你必須修的」 不是每個 bug 都一樣重要。如果 QA 把所有問題用同等力道回報，RD 會開始覺得 QA 沒有判斷力，什麼雞毛蒜皮都來煩他。 學著在回報時說清楚：「這個 P1，上線前必須修。這個 P3，這次版本可以先記 backlog。」你幫他分類了，他才能快速決策，而不是每次都要跟你討論優先序。 4. 當 RD 說「這是 spec 設計」，不要馬上對抗 有時候你找到的問題，RD 說「這是按照 spec 做的」，然後你說「但這個行為用戶不會懂」，然後他說「那去找 PM」，然後你們什麼也沒解決。 更有效的方式是帶著問題去，而不是帶著答案：「我看到這個行為，用戶可能會在這裡卡住，你覺得我們可以怎麼處理？」讓他參與解決問題，而不是讓他感覺在被評判。 5. 有時候說「這個沒問題」 這聽起來很奇怪，但信任的建立不只靠「你幫他找到問題」，也靠「你告訴他沒問題的時候他可以放心」。 如果 QA 每次測完都有一堆 bug，RD 不知道什麼時候才是真的完成了。如果你測完說「這個功能主要流程沒有問題，有兩個小 issue 我已經開票了，可以上」——他會感謝你，因為你給了他一個可以往前走的信號。 信任建立之後，工作會變成什麼樣子 我自己有一個感受是，當 QA 和 RD 的關係從「防禦」變成「信任」，工作的質感會完全不同。 不是因為 bug 消失了，而是 bug 被處理的方式變了。 RD 找到問題會主動告訴你：「我剛改了一個地方，你要不要測一下那個流程。」 你發現問題，他的第一反應是「哦，謝謝，我看一下」，不是「一定要修嗎？」 討論一個邊界情境，他不再是防禦姿態，而是跟你一起想最好的處理方式。 這種狀態下，品質才是真的由大家共同負責，不是 QA 一個人在擋。 達到這個狀態不快，也不是靠一兩個動作就能建立的。但每一次你提早出現、每一次你的 bug report 幫他省了時間、每一次你說「這個可以上線了」，都是在存一點信任進去。 參考資料 1. Capgemini — World Quality Report 2024 25 ：https://www.capgemini.com/insights/research library/world quality report 2024 25/ 2. DORA — 2024 State of DevOps Report ：https://dora.dev/research/2024/dora report/ 3. Dev.to — How to Build a QA Team Engineers Actually Want to Work With ：https://dev.to/cydavid/how to build a qa team engineers actually want to work with 34d7 4. Medium — QA vs. Developers: Breaking the Toxic Cycle ：https://medium.com/@shashanka10/qa vs developers breaking the toxic cycle for better software 375485e1ed02 5. Google Testing Blog — Just Say No to More End to End Tests ：https://testing.googleblog.com/2015/04/just say no to more end to end tests.html