对《我们需要专职QA吗？》的回应

 

说实话，在我看来，左耳朵耗子的《我们需要专职的QA吗？》这篇文章的观点并不算过激。最多就是一篇从开发工程师的角度来商讨是否需要设立“专门做测试的岗位”，让“不熟悉或是不懂开发的人”来做测试工作。如果这个问题摆在我的面前，在大多数情况下，我的答案可能和左耳朵耗子一样：“不需要”。

作为一个在测试行业工作了10多年的“老人”，在这里赞同左耳朵耗子的观点似乎是对自己过去这么多年工作的否定，但实际上，正是因为有这么多年的经验，我才真正能够深刻的体会专职测试工程师在工作中的局限和不足。

为了避免本文引发类似“混淆了QA和测试角色”之类的毫无营养的评价，在下文中，我一概使用“测试人员”来指代从事“专职测试”工作的角色，那些喜欢拿“QA层次更高，是管过程的”各位看管请自行绕道（顺便说一句，我在google的时候，是十分反感自己的团队被称作QA团队的，如果有人这样说，我一定会认真的纠正：“不，我们不是QA，我们是测试工程师”，关于google有没有QA，各位可以自行google）。

“软件需要测试”应该是不会有人反对的观点。问题是，设置专职的“测试人员”是否会比“让开发做测试”更能有效的做好测试。从1998年开始，在华为我开始了自己的测试生涯。关于为什么需要测试工程师，在我的测试工程师职业生涯中，听到得最多的是两种论调：其中之一是“测试工程师需要的技能与开发工程师不同，测试工程师需要的是发现问题的能力”，另一种是“开发人员无法保证产品质量，因此需要测试人员”。后一种论调其实是有很大的问题的，“开发人员无法保证质量”不意味着测试人员就可以保证质量，在大多数企业中，说的不客气一点，“保证质量”通常只是测试部门可以继续存在的表面上的理由而已。至于说到开发工程师与测试工程师所需技能的不同，这一点倒是存在的事实。在一个组织中，测试人员通常会花主要的精力去设计测试用例，评价覆盖度，尝试从不同的角度攻击应用，从表面上看，的确，测试和开发需要的技能很不同。

但是，我要问两个问题：

1. 这些技能开发工程师不能具备吗？
2. 设计测试用例，评价覆盖率这类工作是否真的需要专职的人员去做？

所谓的黑盒测试技术，有多大的难度？平心而论，一个智商正常的具有较好计算机基础的人，一个下午就能完全理解常用的黑盒测试技术，白盒测试技术也不会难到哪里去。只要开发工程师愿意，这些工作他们完全可以承担。只所以开发工程师没有承担这些任务，原因恐怕不是他们不能做，而是像在《我们需要专职的QA吗？》文章后的评论中某位做开发的仁兄说的那样：“如果有一个比较专业的QA来帮助我们，我们就能把自己的时间花在更有用的地方”。

社会分工的细化自然是提供效率的方式，但社会的发展并不只伴随着分工的细化，由于开发工具和开发基础的变化，分工的“合并”也是一个一直在持续的趋势。几年前，大多数公司都倾向于有单独分工的“前端工程师”和“后端工程师”，但现在的趋势不也是在融合？至少，Facebook就要求自己的工程师能同时承担前后端的任务，google也是如此。测试工作和开发工作难道就不能融合？让开发人员做测试怎么就不行？

其实，《我们需要专职的QA吗？》中的不少观点我都非常赞同，鉴于左耳朵耗子已经写了这么大一篇，我就不再重复这些观点了，作为对这些观点的一些佐证，我来说说我自己经历过的几件事情。

故事1

在Google中国的时候，我们团队负责的某个项目，开发工程师每天忙死忙活的加新功能，赶上线，整个团队的开发和SET（Software Engineer in Test）都忙得不行。从传统的对测试工程师的角度来评价的话，这个团队唯一的一个SET工作得十分出色：她几乎能发现所有的缺陷，她几乎把自己所有的时间都投入到项目中去发现缺陷；她是整个开发团队最喜欢和最感激的人，因为“没有她，这个产品简直不可能发布”。但是，这个产品在发布了一段时间后，每个RC的缺陷始终居高不下，这位尽职的SET几乎投入了全部时间和精力，仍然无法让这个产品的质量提高分毫。为什么？因为开发人员从来就没有意识到他们的代码有多烂！当有一个可以帮你发现所有错误的人的时候，我相信，你犯错的勇气一定会更大。这个问题最后是如何解决的？说起来很讽刺，解决这个问题的第一步就是让开发意识到“你们需要自己为代码质量承担责任”，当这位SET改变工作方式，不再尝试把自己的业务时间全部投入来发现无尽的缺陷之后，开发人员立刻意识到自己遇到了大麻烦。然后，他们主动来找我商讨解决方案，当他们最终发现自己不得不改变自己的做法，自己来控制自己错误的时候，事情立刻开始好转。当他们的单元测试达到40%的覆盖率的时候，所有人都变得更轻松了。这位SET负责推动了单元测试，推动了为了让代码具有良好可测试性而进行的重构，设立了组织的代码提交规则（强制提交的新代码必须包含单元测试），然后，产品质量在接下来的一段时间内持续上升。

故事2

Google内部有一个Test Certified的认证，该认证是针对开发团队进行的。认证的主要要点都是基于单元测试覆盖率，基于持续集成建立的开发规则，自动化测试（以小测试为主）。这个认证分为5个级别，1级最低，5级最高。Test Certified和CMMI一样有5个级别，可是出发点却大不相同。这个认证中涉及的全部事情都能（且主要是）由开发工程师搞定，越接近高的级别，需要的专职SET越少。（详细内容参见James最近出版的《How google test software》，虽然书中的观点有些和我不一致，但在Test Certified的描述上是完全没有问题的）

故事3

最后一个故事是最近我遇到的一个测试工程师的故事。她从一开始就表明自己有很强的“做自动化测试”的意愿，因此，她所在的项目团队的技术负责人很高兴地给她分配了一些技术性的任务，包括使用工具监控应用的内存使用情况，找到一个方案能够方便的定位crash发生等等，谁知道这位测试工程师的第一反应是，“这难道不是开发工程师的活吗？”，在她看来，测试工程师完全不应该了解程序是如何工作的，所谓的自动化测试应该是“使用某种手段把自己现在的手工劳动重复下去”。

专职测试人员是否毫无存在的必要？当然不是。至少，我们必须承认，在有些必须大量依靠“体验”进行测试的行业，如游戏行业中，专职的测试人员是有存在的必要的。但我想，在类似google，facebook这样的环境中（我猜测在左耳朵耗子所在的环境中也差不多），不能深刻理解开发和具有深入的开发技术的测试人员（SET）的确没太多价值。真诚的希望各位测试工程师在读左耳朵耗子的文章时，不要纠结于他的结论，而去看看他提到的问题，是不是真的切中了专职测试的痛处。至少对我来说，文章中提到的这些熟悉的问题每一个都能让我想起一些故事。

对于我从事了10多年的测试行业，即使我现在的角色有所变化，这个行业的每一个变动和变革都会让我关注。这种感情是不可能割舍的。所以，真诚的希望每一位测试的工作者，能够真正思考我们如何做的更好。测试和开发之间有更多配合，更多相亲相爱，把测试当成提高和推动质量的手段，不正应该是测试的方向吗？