一篇文章《我们需要专职的QA吗》引发的思考
http://coolshell.cn/articles/6994.html《我们需要专职的QA吗》
http://www.zhihu.com/question/22947392《国外知名 IT 企业是如何做测试的？》
观点如下：作者觉得是不需要全职的QA的，甚至不需要QA这一专职角色或部门，因为，不懂开发的人必然做不好测试。就像不懂开发的研发经理必然管不好研发团队一样。但是，请注意前提，作者观点里的这个“专职QA”是这么定义的：
- 其是很多公司成立的专门做测试的技术人员，仅测试不开发。
- 这些QA对于软件开发技术并不熟悉，甚至不懂
有点中枪了对不对？同时，作者觉得开发才是做测试最合适的人选，并预估这一观点十年后将被证明。QA们，有没有菊花一紧？我们的测试生涯只剩下8年的光景了。
先来说说作者的故事。我只能说，作者很不幸遇到了一个很不靠谱的QA团队。从作者列举的种种，这些QA们完全不称职。逐条来看作者分析为什么有这样的不靠谱的QA团队：
1. 给了QA全部测试的权利，但是没有给相应的责任。
事实上，QA不但拥有全部测试的权利，也要承担为质量负责的责任。质量一直都是衡量QA performance的最重要标准，也是被Lead和manager强调最多的。如果一个QA测过的feature被发现有bug，QA都会第一时间去了解什么情况。是design的问题？business欠缺？还是真的没有cover？分析问题找出原因避免再犯。严重的漏测比如客户发现比较严重的问题，还会有专门的Root Cause Analysis，从manager到Lead到QA都会一起分析，当然，这种事故对QA的performance必然有很大的影响。
2. QA没有体会过软件质量出问题之后的痛苦，导致QA不会主动思考和改进。
如上所说，QA要为质量负责，所以必然对软件质量问题非常敏感，迫使QA必须思考改进。有一种观点认为，软件的质量从开发结束就已经决定了，因为Bug是开发人员开发过程中产生的，QA没办法对质量负责，只能通过测试改善质量。从哲学角度看好像是这么个理，可是QA是干什么的？就是发现软件中的bug并得到fix。虽然测试过的软件依然有bug，但QA的目标是尽可能无限接近完美。
3. QA对Dev的开发过程和技术完全不了解，增加了很多QA和Dev的沟通。
目前多数QA确实对开发过程技术不了解，黑盒测试本来就是这样，不用了解过程而只看输入输出，所以各种必要的沟通成本无法避免。但是黑盒QA要基于用户角度对产品设计了然于胸并能够给出建设性的意见，在测试过程中提高沟通效率掌握沟通技巧也是一门学问，所谓的teamwork嘛。
4. QA对软件项目的设计和实现要点不了解，导致很多不有效的测试。
这一点确实是实际情况。QA测试的标准是参考设计文档，围绕设计文档做调查写case，但是谁都不能保证测试完成就一定没有Bug。所以QA都会尽可能在时间允许的情况下做更多的测试，哪怕可能是无效的，这总比漏测强吧。另一方面，QA如果能积极学习开发相关的技术，知道实现机制，也能更准确的定位测试范围，减少无效测试。我印象中有一次发现一个bug，开发在debug的过程中发现这个bug居然是在fix另外一个模块中的bug引起的，当时那个bug的开发和测试怎么也没想到还能影响到这么八竿子打不着的地方，真的是万万没想到啊。
再来看作者认为不需要全职QA的观点：
1. 开发人员做测试更有效。
我非常同意作者所列举的这样认为的原因。开发最清楚应该怎么测，最明白怎么测最有效。
在本文最后有篇文章链接，很学术性，讲QA的角色和分工。有几句话倒是一阵见血：如果你这样认为，要么人太牛，要么事太小，要么人手不够。我之前工作的那个产品的Dev manager，就是牛人一个，我经常看到他报了一些代码级别的Bug，然后自己报自己fix，Assign给QA吧，QA要问好多细节然后再判断对哪块business有影响，太麻烦了，算了，自己测下close吧。真牛！还好，这样的开发并不是特别多。
事太小，现在很多人业余开发移动App，都是自个搞吧。火爆一时的FlappyBird不就一个人嘛，不需要专门找个QA。但是复杂的产品就不是这样了。
人手不够，恩，很多创业团队最初就只有开发，一方面资金有限没多余的闲钱招测试，另一方面，太新的产品变化太多，可能只是个模型，专职的QA完全没必要。
2. 减少沟通，扯皮和推诿。
前面说过，沟通不可避免，但扯皮推诿不会吧，都是一条线上的蚂蚱。测试把TP发给开发review是希望得到反馈避免遗漏，因为开发最清楚coding了什么；QA和Dev应该是合作更多，QA帮Dev搭建环境重现问题，Dev帮QA查找问题的原因，还是很和谐的。如果有争论到底是不是Bug,可以问产品经理啊，不必你死我活。
作者还列出了很多原因，捡几条我能发表意见的：
3. 关于SDET。测试开发工程师，Google就有这样的职位，主要职责参见《How Google Tests Software-Summary》一文有写到。这是一个100%coding的角色，可以支持开发做单元测试，提供测试框架，也有的公司设置这样的职位来开发自动化工具，其实这应该是一个开发职位。在Google，这个职位描述的比较高大上，说这个职位既要懂开发还要懂测试。
4. Dev有思维定式，自己测试自己的feature也难免有盲点，那开发互相Cross testing嘛。实际上这样是可行的，我相信在只有开发的小团队里就是这样做测试的。但是我觉得，开发人员应该不可能像专职的QA那样去做大量的黑盒测试，更别说系统集成测试，兼容性测试，性能压力测试。他们更倾向于单元测试就能解决测试问题（开发可以反驳，这确实是我的臆测）。另外，开发又要coding自己的feature又要测试别人的feature，现实情况是，开发比测试工资高啊，让开发做测试，这样老板不干吧！
3. 关于SDET。测试开发工程师，Google就有这样的职位，主要职责参见《How Google Tests Software-Summary》一文有写到。这是一个100%coding的角色，可以支持开发做单元测试，提供测试框架，也有的公司设置这样的职位来开发自动化工具，其实这应该是一个开发职位。在Google，这个职位描述的比较高大上，说这个职位既要懂开发还要懂测试。
4. Dev有思维定式，自己测试自己的feature也难免有盲点，那开发互相Cross testing嘛。实际上这样是可行的，我相信在只有开发的小团队里就是这样做测试的。但是我觉得，开发人员应该不可能像专职的QA那样去做大量的黑盒测试，更别说系统集成测试，兼容性测试，性能压力测试。他们更倾向于单元测试就能解决测试问题（开发可以反驳，这确实是我的臆测）。另外，开发又要coding自己的feature又要测试别人的feature，现实情况是，开发比测试工资高啊，让开发做测试，这样老板不干吧！
正如《QA的角色和分工》一文所说，任何产业成熟到一定阶段的时候，独立的质量保证角色是不可避免的。而且，是否需要专职QA也因产品而异，文中说到Facebook貌似没有全职测试人员，而微软的开发测试比例是1:1。引用此文的结束语：分工是社会和行业进化的结果，开发和测试是软件工程的两个分支，不同的软件和服务需要不同方式和程度的测试，独立专业的测试等同于第三方代表客户对产品认证。
这里有篇知乎的讨论，可以看看。http://www.zhihu.com/question/22947392《国外知名 IT 企业是如何做测试的？》
TAG:
