我们需要专职的QA吗？
在此之前，我想说明一下我观点里的这个“专职 QA”是怎么定义的。
- 其是很多公司成立的专门做测试的技术人员，仅测试不开发。
- 这些 QA 对于软件开发技术并不熟悉，甚至不懂。
我经历过一些公司都有专职的 QA 团队（专职的测试人员），自从上个公司我的开发团队在一个项目上被 QA 部门搞得一团糟，我越来越怀疑专职 QA 存在在意义。我的观点不一定对，但请让我鲜明地表达一下——我觉得是不需要全职的 QA 的，甚至不需要 QA 这一专职角色或部门，因为，不懂开发的人必然做不好测试。就像不懂开发的研发经理必然管不好研发团队一样。我越来越觉得 Dev 应该应该是做测试最合适的人选，这必然是未来的趋势 （因为我已经看到了中国程序员的进步，相比起 10 年前，今天的程序员已经是非常全面了，再来十年，必然证明我的观点是对的）。
在我正在展开说明之前，我想引用两篇文章：
两篇文章
一篇是 “On testers and testing”(中文翻译)，本文的作者 Sriram Krishnan 是一名程序员，曾在 Yahoo 和微软工作过，开发过很多软件，曾被纽约时报报道，写过一本书，本文是他的一篇博客。他在文章中表达了这几个观点——
大多数的开发团队并不需要一个独立的测试角色。即使要有，那么所有的开发时间比上所有的测试时间应该 >20:1的。。证据吗？光看看一些从古至今最成功的软件开发团队就知道了。不论是当今的 Facebook，还是 30 年前最初的 NT 团队，很多伟大的产品都是出自没有或很少测试人员的团队。
开发人员应该测试自己的代码。没什么可说的。背后的道理并不重要。这包括单元测试，全覆盖的自动化测试或手工测试或组合测试。如果你的开发人员不能/不愿意或认为这“不归我管”，那你需要更好的程序员。
另一篇文章是邹欣的“现代软件工程讲义 9 测试 QA 的角色和分工”，这是一篇很不错的文章。他在文章里提到了分工的必要性，比如第三方的鉴定机构，并且也指出了分工的一些问题，比如，画地为牢的分工，无明确责任的分工，等，这些问题直接命中了分工的要害。我隐约觉得，我和邹欣的很多观点是相同的，我们内容上是相同的，只是形式上还有分歧。另外，我的观点太鲜明了，从而容易导向极端的理解。
你看，我们都同意，Dev 要懂测试，QA 要懂开发，只不过分工不同，既然你中有我，我中有你，那就不要分彼此了，一起携手开发测试吧。（另外，我个人觉得不懂开发的测试人员不可能测试得好）
我的故事
我再说说我最糟糕的 QA 经历吧，这个公司的 QA 部门只做测试，他们的 leader 觉得所有的 test design 和 test 的过程都不需要 Dev 参与，他们是独立于 Dev 之外的部门，他们几乎不关心 Dev 的设计和实现，他们只关心能跑通他们自己设计的 test case。但是去执行 Test Case 的时候，又需要 Dev 的支持，尤其在环境设置，测试工具使用，确认是否是 bug 方面，全都在消耗着 Dev 的资源，最扯的是，他们对任何线上的问题不负责，反正出了问题由 Dev 加班搞定。
我有一次私自 review 他们的 test case 的时候，发现很多的 test case 这样写到 – “Expected Result：Make sure every thing is fine” ，WTF，什么叫“Every thing is fine”？！而在 test case design 的时候，没有说明 test environment/configuration 是什么？没有说明 test data 在哪里？Test Case、Test Data、Test Configuration 都没有版本控制，还有很多 Test Case 设计得非常冗余（多个 Test Case 只测试了一个功能），不懂得分析 Function Point 就做 Test Design。另外，我不知道他们为什么那么热衷于设计一堆各式各样的 Negative Test Case，而有很多 Positive 的 Test Case 没有覆盖到。为什么呢，因为他们不知道开发和设计的细节，所以没有办法设计出 Effective 的 Test Case，只能从需求和表面上做黑盒。
在做性能测试的时候，需要 Dev 手把手的教怎么做性能测试，如何找到系统性能极限，如何测试系统的 latency，如何观察系统的负载（CPU，内存，网络带宽，磁盘和网卡I/O，内存换页……）如何做 Soak Test，如何观察各个线程的资源使用情况，如何通过配置网络交换机来模拟各种网络错误，等等，等等。
测试做得也不认真，大量的 False Alarm，都是环境问题，比如：安装新版本后没有重启服务，没有使用新的配置文件，网络配置，等等，等等。
在项目快要上线前的一周，我又私自查看了一下他们的 Test Result，我看到 5 天的 Soak Test 的内存使用一直往上涨，很明显的内存泄露，这个情况发生在 2 个月前，但是一直都没有报告，我只好和我的程序员每天都加班到凌晨，赶在上线前解决了这个问题。但是，QA 部门的同学们就像没发生什么事似的，依然正常上下班。哎……
为什么会这样？我觉得有这么几点原因（和邹欣的观点一样）
- 给了 QA 全部测试的权力，但是没有给相应的责任，
- QA 没有体会过软件质量出问题后的痛苦（解决线上问题的压力），导致 QA 不会主动思考和改进。
- QA 对 Dev 的开发过程和技术完全不了解，增加了很多 QA 和 Dev 的沟通。
- QA 对软件项目的设计和实现要点不了解，导致了很多不有效的测试。
注：我无意在这里贬低 QA 的能力工作。只是我看到了 QA 因为没有参与开发的一些现实问题。
我的观点
邹欣对于分工出现的问题给出了两点解决方法：
- 充分授权和信任（Empower team members）
- 各司其职，对项目共同负责（Establish clear accountability and shared responsibility）
我的观点是，理论上正确，操作上太虚了。这就像我们国家喊的“为人民服务”的口号一样，没有具体的方法，根本无法落实。
我无意在这里贬低 QA 的工作，我也无意因为这个事走向另一个极端。但是，我在现在公司的经历，还有很多新兴公司的做法，我越来越觉得软件开发，真的不需要专职的 QA，更不需要只写代码不懂做测试的专职的 Dev。观点如下：
1） 开发人员做测试更有效
- 开发人员本来就要测试自己写的软件，如果开发人员不懂测试，或是对测试不专业，那么这就不是一个专业的开发人员。
- 开发人员了解整个软件的设计和开发过程，开发人员是最清楚应该怎么测试的，这包括单元测试，功能测试，性能测试，回归测试，以及 Soak Test 等。
- 开发人员知道怎么测试是最有效的。开发人员知道所有的 function point，知道 fix 一个 bug 后，哪些测试要做回归和验证，哪些不需要。开发人员的技术能力知道怎么才能更好的做测试。
很多开发人员只喜欢写代码，不喜欢做测试，或是他们说，开发人员应该关注于开发，而不是测试。这个思路相当的错误。开发人员最应该关注的是软件质量，需要证明自己的开发成果的质量。开发人员如果都不知道怎么做测试，这个开发人员就是一个不合格的开发人员。
另外，我始终不明白，为什么不做开发的 QA 会比 Dev 在测试上更专业？ 这一点都说不通啊。
2）减少沟通，扯皮，和推诿
想想下面的这些情况你是否似曾相识？
- QA 做的测试计划，测试案例设计，测试结果，总是需要 Dev 来评审和检查。
- QA 在做测试的过程中，总是需要 Dev 对其测试的环境，配置，过程做指导。
- QA 总是会和 Dev 争吵某个问题是不是 BUG，争吵要不要解决。
- 无论发现什么样的问题，总是 Dev 去解决，QA 从不 fix 问题。
- 我们总是能听到，线上发生问题的时候，Dev 的抱怨 QA 这样的问题居然没测出来，
- QA 也总会抱怨 Dev 代码太差，一点也不懂测试，没怎么测就给 hand over 给 QA 了。
- QA 总是会 push Dev，这个 bug 再不 fix，你就影响我的进度了。
- 等等，等等。
如果没有 QA，那么就没有这么多事了，DEV 自己的干出来的问题，自己处理，没什么好扯皮的。
而一方面，QA 说 Dev 不懂测试，另一方面 Dev 说 QA 不懂技术，而我们还要让他们隔离开来，各干各的，这一点都不利于把 Dev 和 QA 的代沟给填平了。要让 Dev 理解 QA，让 QA 理解 Dev，减少公说公有理，婆说婆有理的只站在自己立场上的沟通，只有一个方法，那就是让 Dev 来做测试，让 QA 来做开发。这样一样，大家都是程序员了。
3）吃自己的狗食
真的优秀的开发团队都是要吃自己狗食的。这句话的意思是——如果你不能切身体会到自己干的烂事，自己的痛苦，你就不会有想要去改进的动机。没有痛苦，就不会真正地去思考，没有真正的思考，就没有真正的进步。
在我现在的公司，程序员要干几乎有的事，从需求分析，设计，编码，集成，测试，部署，运维，OnCall，从头到尾，因为：
- 只有了解了测试的难度，你才明白怎么写出可测试的软件，怎么去做测试的自动化和测试系统。
- 只有自己真正去运维自己的系统，你才知道怎么在程序里写日志，做监控，做统计……
- 只有自己去使用自己的系统，你才明白用户的反馈，用户的想法，和用户的需求。
所以，真正的工程师是能真正明白软件开发不单单只是 coding，还更要明白整个软件工程。只明白或是只喜欢 coding 的，那只是码农，不能称之为工程师。
4）其它问题
- 关于 SDET。全称是 Software Development Engineer on Test。像微软，Google， Amazon 都有这样的职位。但我不知道这样的职位在微软和 Google 的比例是多少，在 Amazon 是非常少的。那么像这样的懂开发的专职测试可以有吗？我的答案是可以有！但是，我在想，如果一个人懂开发，为什么只让其专职做测试呢？这样的程序员分工合理吗？把程序分成两等公民有意义吗？试问有多少懂开发的程序员愿意只做测试开发呢？所以，SDET 在实际的操作中，更多的还是对开发不熟的测试人员。还是哪句话，不懂开发的人是做不好测试的。
- 如果你说 Dev 对测试不专业，不细心，不认真，那么我们同样也无法保证 QA 的专业，细心和认真。在 Dev 上可能出现的问题，在 QA 也也会一样出现。而出了问题 QA 不会来加班解决，还是开发人员自己解决。所以，如果 QA 不用来解决问题，那么，QA 怎么可能真正的细心和认真呢？
- 如果你说不要 QA 的话，Dev 人手会不够。你这样想一下，如果把你团队中现有的 QA 全部变成 Dev，然后，大家一起开发，一起测试，亲密无间，沟通方便，你会不会觉得这样会更有效？你有没有发现，在重大问题上，Dev 可以帮上 QA 的忙，但是 QA 帮不上 Dev 的忙。
- 第三方中立，你会说人总是测不好自己写的东西，因为有思维定式。没错，我同意。但是如果是 Dev 交叉测试呢？你可能会说开发人员会有开发人员的思维定式。那这只能说明开发人员还不成熟，他们还不合格。没关系，只要吃自己的狗食，痛苦了，就会负责的。
- 磨刀不误砍柴功。如果你开发的东西自己在用，那么自己就是自己天然的 QA，如果有别的团队也在用你开发的模块，那么，别的团队也就很自然地在帮你做测试了，而且是最真实的测试。
- 你可能会说吃狗食就是个笑话，因为如果是我，我把干烂的事，就离职走人了，让后来去吃我的狗食。这个的确是这样的，但是想一想，你为什么在一开始让他把事干烂了？另外，如果你的团队在设计评审和代码评审里没有把好关，让某人把事给干烂了，那么这个人的离职带来的问题还是这个团队来抗，于是整个团队都在吃自己的狗食，挺公平的。痛苦过一次，你的团队下次怎么干了，就不敢乱招人了，就不敢随意评审代码了，就不敢让人只做一块东西了。最终还是没有逃脱吃狗食的范畴。
- 关于自动化测试。所谓自动化的意思是，这是一个机械的重复劳动，我想让测试人员思考一下，你是否在干这样的事？如果你正在干这样的事，那么，你要思考一下你的价值了。但凡是重复性比较高的机械性的劳动，总有一天都会被机器取代的。
- 关于线上测试。我们都知道，无论自己内测的怎么样，到了用户那边，总是会有一些测试不到的东西。所以，有些公司会整出个 UAT，用户验收测试。做产品的公司会叫 Beta 测试。无论怎么样，你总是要上生产线做测试的。对于互联网企业来说，生产线上测试有的玩A/B测试，有的玩部分用户测试，比如，新上线的功能只有 10% 的用户可以访问得到，这样不会因为出问题让全部用户受到影响。做这种测试的人必然是开发人员。
好吧，我暂时写这么多，我会视大家的讨论再补充我的观点的。
转自：http://news.cnblogs.com/n/138376/