QA该何去何从

今天聊的这个话题要从一段对话开始。

“快到年底了，今年要评绩效了”
“哦，有啥好评的，我们QA的工作就是测试，有啥绩效可以讲？”
“QA就没有绩效可以讲吗？”
“QA就像守门员，守住了，算是工作到位，没守住，就是失职，背锅啊”
“......”

质量管理的工作，在软件行业就是测试，远在瀑布式研发的时代，QA部门是一个单独的部门，部门的职能就是负责软件的质量保证，但是真正落下来的事情就是测试。最原始的测试是体力活，雇佣几个人，按照事前准备好的测试用例，进行手工测试。这个时候，因为是瀑布式的研发方式，研发环节是和职能部门一一对应的，因此测试也是一个部门，只不过在领导的眼里，产品部门能够设计出好产品，研发部门能将产品落地，测试部门产出了啥？貌似最后只有测试报告，显得也没啥好说的。

质量管理这个概念是很重要的，你说哪个企业不重视质量？造车的，盖楼的，铺路的，制药的，但是为什么软件行业中质量从业者就没有话语权呢？

一个普遍的认识是，大家认为，质量保证工作是融合在研发工作中的，这二者是不能分离的。
也就是说，如果研发团队中有人懂质量保证，那么可能就不需要单独的QA了。如果在汽车制造的过程中，研发团队已经懂得如何才能造出高质量的汽车，那QA的价值就降低了。其实这个看法也不错。

在软件工程领域，随着敏捷研发的发展，质量保证的方面也讲究build quality in，即在研发过程中嵌入质量保证的手段，比如TDD，CI等具体的措施，而这个时候，留给QA的工作就是探索性测试，或者弥补自动化测试力所不及的部分。在汽车制造领域，我们知道一个高质量的耐用的机器，对于拧紧每一颗螺丝都是至关重要的，每一颗螺丝需要拧几圈，需要拧多紧都是有明确规定的，因此在制造汽车的生产线的时候，就把这些规则加了进去，之后生产线的工人拿着螺丝枪拧螺丝，螺丝枪里就设定了这些关键的质量指标，工人的工作就变的简单很多。最后的QA虽然也要做检测，但是做检测之前，质量保证工作就已经做了很多了。

所以你说质量保证工作重不重要，那自然是很重要的。只是这个工作在已经由多个部门共同在做了，如果只做最后一公里的测试，那么自然价值含量就会大打折扣。

因此，像google这样的公司，一个研发团队中，QA和开发的比例比1:8还要低。相反，据说微软windows的研发团队，测试比例研发是2:1，还是蛮高的。

质量保证和测试是两个不同级别的概念，测试是质量保证的一个手段，而质量保证需要在流程、制度、技术上、能力上一起进行规划和执行。就是因为涉及到流程和制度，因此这类事情一般是研发总监或者公司级操心的事情，留给“测试部门”的就只有测试了。

所以当测试人员抱怨说没前途的时候，也可以理解，光做测试肯定是没前途，做质量保证才有前途，不过一般的软件公司没有这样单独的职位。我相信随着技术的发展，纯粹的软件测试人员会越来越少，而质量保证的工作不会减少，大概率会融入到研发过程中，而质量管理的工作会由少数一些人担任或者兼职担任。

QA的工作会不会消失呢？从结构上来讲，管理层还是需要一个部门来对研发进行监督，作为最后一道关口，部门不会消失，可能更多的职责会变成监督。