10個技術Leader全票反對QA，這崗位真要涼了？

100%的反對票。我上周問了10位工程負責人同一個問題：軟件團隊該不該保留QA？結果10個人全說"不該"。

這個數字放在五年前幾乎不可能出現。QA（質量保證）曾是軟件開發的標配，現在卻成了"老派做法"的代名詞。但投票歸投票，真到了執行層面，事情沒這么簡單。

QA的困境：從守門員變成累贅

反對QA的核心論點很直白：工程團隊應該自己負責質量。這派觀點把QA比作運維（Operations）——以前工程師寫代碼、運維人員部署維護，中間隔著一道移交墻，兩邊目標不一致，出了問題互相甩鍋。

現代工程文化把這視為毒瘤。DevOps運動就是要拆掉這堵墻，讓工程師對全生命周期負責。QA在很多人眼里，就是下一座該拆的墻。

支持QA的人也不是沒有。傳統公司、強合規要求的行業，測試獨立性的價值被看得很重。但最意外的論點來自AI：自動化驗證成了"杠桿放大器"，QA如果能駕馭AI測試工具，反而能創造超額價值。

兩邊都有理，但現實中QA的處境越來越尷尬。

測試金字塔的殘酷分層

要理解QA的角色危機，得先看測試金字塔。底層是單元測試，快、確定性強；往上是集成測試；最頂層是UI測試，慢、脆弱、維護成本高。

工程圈有個共識：單元測試和集成測試必須工程師自己寫，沒得商量。

爭議只在金字塔尖——端到端UI測試。有些公司把這扔給QA，讓他們從用戶視角驗收；有些公司要求工程師全包。QA的領地，就剩這最窄的一層。

更麻煩的是激勵結構。QA按"發現bug"計功，工程師按"交付功能"計功。目標錯位的團隊，協作起來像拔河。

那位發起投票的工程負責人說得直接：如果從零搭建團隊，他不會設QA崗。CI/CD（持續集成/持續部署）和測試自動化從第一天就內置，質量是工程的事，不是某個部門的專職。

QA的救命稻草：向左移，別當守門員

但QA真要消失了嗎？未必。投票結果有個關鍵限定詞——"mostly"（大部分情況下）。10位負責人都留了口子：特定場景、邊緣案例，QA仍有存在價值。

問題是，大多數QA沒活成那個"例外"。他們卡在流程末端，等代碼寫完才介入，像工廠質檢員。這種"向右移"的模式，正是被攻擊的靶心。

解法是"向左移"（Shift Left）。QA要嵌入工程團隊，從需求階段就參與，把測試思維注入設計環節。不是等房子蓋完檢查漏水，而是在畫圖紙時就問：這個屋頂坡度會不會積水？

那位負責人給QA領導者的建議很具體：別守著測試用例庫當資產，那是死胡同。去寫自動化測試框架，去訓練AI測試代理，去成為工程效率的乘數而非瓶頸。

換句話說，QA得證明自己不是成本中心，而是杠桿支點。

一個細節值得玩味：投票的10位負責人里，有人剛裁掉整個QA部門，有人正在招QA——但招的是能寫代碼、能搭測試平臺的"混合型"人才。舊崗位在消亡，新角色在模糊地帶生長。

你的團隊還在用傳統QA模式嗎？最后一個問題留給讀者：如果工程師全責質量，出生產事故時，誰來背鍋？