100%的反對票。我上周問了10位工程負(fù)責(zé)人同一個問題：軟件團(tuán)隊(duì)該不該保留QA？結(jié)果10個人全說"不該"。

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

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

反對QA的核心論點(diǎn)很直白：工程團(tuán)隊(duì)?wèi)?yīng)該自己負(fù)責(zé)質(zhì)量。這派觀點(diǎn)把QA比作運(yùn)維（Operations）——以前工程師寫代碼、運(yùn)維人員部署維護(hù)，中間隔著一道移交墻，兩邊目標(biāo)不一致，出了問題互相甩鍋。

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

支持QA的人也不是沒有。傳統(tǒng)公司、強(qiáng)合規(guī)要求的行業(yè)，測試獨(dú)立性的價(jià)值被看得很重。但最意外的論點(diǎn)來自AI：自動化驗(yàn)證成了"杠桿放大器"，QA如果能駕馭AI測試工具，反而能創(chuàng)造超額價(jià)值。

兩邊都有理，但現(xiàn)實(shí)中QA的處境越來越尷尬。

測試金字塔的殘酷分層

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

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

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

更麻煩的是激勵結(jié)構(gòu)。QA按"發(fā)現(xiàn)bug"計(jì)功，工程師按"交付功能"計(jì)功。目標(biāo)錯位的團(tuán)隊(duì)，協(xié)作起來像拔河。

那位發(fā)起投票的工程負(fù)責(zé)人說得直接：如果從零搭建團(tuán)隊(duì)，他不會設(shè)QA崗。CI/CD（持續(xù)集成/持續(xù)部署）和測試自動化從第一天就內(nèi)置，質(zhì)量是工程的事，不是某個部門的專職。

QA的救命稻草：向左移，別當(dāng)守門員

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

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

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

那位負(fù)責(zé)人給QA領(lǐng)導(dǎo)者的建議很具體：別守著測試用例庫當(dāng)資產(chǎn)，那是死胡同。去寫自動化測試框架，去訓(xùn)練AI測試代理，去成為工程效率的乘數(shù)而非瓶頸。

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

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

你的團(tuán)隊(duì)還在用傳統(tǒng)QA模式嗎？最后一個問題留給讀者：如果工程師全責(zé)質(zhì)量，出生產(chǎn)事故時(shí)，誰來背鍋？