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模式吗？最后一个问题留给读者：如果工程师全责质量，出生产事故时，谁来背锅？
热门跟贴