以下为文章原文：
http://www.iteye.com
这个文章必然是有争议的，我在我的微博上讨论过很多次了，每次都是很有争议的。对于不同的观点，有争论总是一件好事，这样可以引发大家的思考。所以，对于我的这篇博文，如果你赞同我的观点，我会感到高兴；如果你会去认真地深入思考，我也会高兴；如果你反对，没关系，可以讨论。
在此之前，我想先说明一下我观点里的这个“专职QA”是怎么定义的：
很多公司成立的专门做测试的技术人员，仅测试不开发。
这些 QA 对于软件开发技术并不熟悉，甚至不懂。
我之前供职过的公司几乎都有专职的QA团队（专职的测试人员）。自从在上个公司，我的开发团队在一个项目上被QA部门搞得一团糟后，我就越来越怀疑专职QA存在的意义。我的观点不一定对，但请让我鲜明地表达一下——企业不需要全职的QA，甚至不需要QA这一专职角色或部门。因为，不懂开发的人必然做不好测试，就像不懂开发的研发经理必然管不好研发团队一样。现在，我越来越觉得Dev应该应该是做测试最合适的人选，而这也必然是未来的趋势（因为我已经看到了中国程序员的进步，相比起10年前，今天的程序员已经是非常全面了，再来十年，必然证明我的观点是对的）。
一、两篇文章
在我正在展开说明之前，我想先引用两篇文章。一篇是《On testers and testing》(点击查看中文翻译)。本文的作者Sriram Krishnan是一名程序员，曾在Yahoo和微软工作过，开发过很多软件，写过一本书，并曾接受过纽约时报的采访。本文是他的一篇博客。他在文章中表达了以下这几个观点：
开发人员应该测试自己的代码。这没什么可说的。背后的道理并不重要。这包括单元测试，全覆盖的自动化测试、手工测试或组合测试等。如果你的开发人员不能、不愿意或认为这“不归我管”，那你需要更好的程序员。
另一篇文章是邹欣的《现代软件工程讲义9 测试 QA 的角色和分工》。这是一篇很不错的文章。他在文章里提到了分工的必要性，比如第三方的鉴定机构。并且也指出了分工的一些问题，比如画地为牢的分工、无明确责任的分工等等。这些问题直接命中了分工的要害。我隐约觉得，我和邹欣的很多观点是相同的，我们在内容上是相同的，只是形式上还有分歧。另外，我的观点太鲜明了，从而容易引起极端的理解。
你看，我们都同意，Dev要懂测试，QA要懂开发，只不过分工不同。既然你中有我，我中有你，那就不要分彼此了，一起携手开发测试吧。另外，我个人觉得不懂开发的测试人员不可能测试得好。
二、我的故事
我再说说我最糟糕的QA经历吧。之前我在一家公司工作，这家公司的QA部门只做测试。他们的leader觉得所有的test design和test 的过程都不需要Dev参与，他们是独立于Dev之外的部门，他们几乎不关心Dev的设计和实现。他们只关心能跑通他们自己设计的测试用例。但是去执行测试用例的时候，又需要Dev的支持，尤其在环境设置、测试工具使用、确认是否是bug方面，全都在消耗着Dev的资源。最让我感到绝望的是：他们对任何线上的问题不负责，反正出了问题由Dev加班搞定。
我有一次私自review他们的测试用例的时候，发现很多的测试用例这样写到：“Expected Result：Make sure every thing is fine”。什么叫“Every thing is fine”？！而在测试用例设计的时候，没有说明测试环境是什么，没有说明测试数据在哪里，测试用例、测试数据、测试配置都没有版本控制，还有很多测试用例设计得非常冗余（多个测试用例只测试了一个功能），不懂得分析Function Point就做测试设计。
另外，我不知道他们为什么那么热衷于设计一堆各式各样的负向测试用例，而有很多正向测试用例没有覆盖到。为什么呢，因为他们不知道开发和设计的细节，所以没有办法设计出高效的测试用例，只能从需求和表面上做黑盒。
在做性能测试的时候，需要Dev手把手的教怎么做性能测试，如何找到系统性能极限，如何测试系统的latency，如何观察系统的负载（CPU、内存、网络带宽、磁盘和网卡I/O、内存换页……），如何做Soak Test，如何观察各个线程的资源使用情况，如何通过配置网络交换机来模拟各种网络错误等等，等等。
测试做得也不认真，大量的False Alarm，都是环境问题。比如：安装新版本后没有重启服务，没有使用新的配置文件，网络配置等等，等等。
在项目快要上线前的一周，我又私自查看了一下他们的测试结果，我看到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，知道修复一个bug后，哪些测试要做回归和验证，哪些不需要。开发人员的技术能力知道怎么才能更好的做测试。
很多开发人员只喜欢写代码，不喜欢做测试，或者如他们所说，开发人员应该关注于开发，而不是测试。这个思路相当的错误。开发人员最应该关注的是软件质量，需要证明自己的开发成果的质量。开发人员如果都不知道怎么做测试，这个开发人员就是一个不合格的开发人员。
另外，我始终不明白，为什么不做开发的QA会比Dev在测试上更专业？ 这一点都说不通啊。
2、减少沟通、扯皮和推诿
想想下面的这些情况你是否似曾相识？
QA做的测试计划、测试案例设计、测试结果，总是需要Dev来评审和检查。
QA在做测试的过程中，总是需要Dev对其测试的环境、配置和过程做指导。
QA总是会和Dev争吵某个问题是不是bug，争吵要不要解决。
无论发现什么样的问题，总是Dev去解决，QA从不解决问题。
我们总是能听到，线上发生问题的时候，Dev抱怨QA这样的问题居然没测出来。
QA也总会抱怨Dev代码太差，一点也不懂测试，没怎么测就给hand over 给QA了。
QA总是会催促 Dev：这个bug再不修复，你就影响我的进度了！
如果没有QA，那么就没有这么多事了，DEV遇到自己的问题，自己处理，没什么好扯皮的。
一方面，QA说Dev不懂测试；另一方面Dev又说QA不懂技术。而我们还要让他们隔离开来，没有沟通。我们应该让Dev理解QA，也要让QA理解Dev，减少公说公有理，婆说婆有理的现象出现。
3、吃自己的狗食
真正优秀的开发团队都是要吃自己狗食的。这句话的意思是：如果你不能切身体会到自己糟糕的开发成果带来的痛苦，就不会真正地去思考；没有真正的思考，就没有真正的进步。
在我现在的公司，程序员要干几乎所有的事：需求分析、设计、编码、集成、测试、部署、运维、OnCall。因为：
只有了解了测试的难度，你才明白怎么写出可测试的软件，怎么去做测试的自动化和测试系统。
只有自己真正去运维自己的系统，你才知道怎么在程序里写日志、做监控、做统计……
只有自己去使用自己的系统，你才明白用户的反馈、用户的想法和用户的需求。
所以，优秀的程序员深知这一点：软件开发不单单只是编码，还更明白整个软件工程。只明白或是只喜欢编码的，那只能称之为码农，不能称之为软件工程师。
4、其它问题
关于SDET（全称是Software Development Engineer on Test）。像微软、Google、Amazon都有这样的职位。但我不知道这样的职位在微软和Google的比例是多少。那么像这样的懂开发的专职测试可以有吗？我的答案是可以有！但是，我在想，如果一个人懂开发，为什么只让其专职做测试呢？这样分工合理吗？把程序员分成两等公民有意义吗？试问有多少懂开发的程序员愿意只做测试开发呢？所以，SDET在实际的操作中，更多的还是对开发不熟的测试人员。
如果你说Dev对测试不专业、不细心、不认真，那么我们同样也无法保证QA的专业、细心和认真。Dev遇到的的问题，QA可能也会遇到。而出了问题QA不会来加班解决，还是开发人员自己解决。所以，如果QA不用来解决问题，那么，QA怎么可能真正的细心和认真呢？
如果你说不要QA的话，Dev人手会不够。你这样想一下，如果把你团队中现有的QA全部变成Dev。然后，大家一起开发，一起测试，亲密无间，沟通方便，你会不会觉得这样会更有效？你有没有发现，在重大问题上，Dev可以帮上QA的忙，但是QA帮不上Dev的忙。
第三方中立，你会说程序员总是测不好自己写的东西，因为有思维定式。没错，我同意。但是如果是Dev交叉测试呢？你可能会说开发人员会有开发人员的思维定式。那这只能说明开发人员还不成熟，他们还不合格。没关系，只要吃自己的狗食，痛苦了，就会负责的。
磨刀不误砍柴功。如果你开发的东西自己在用，那么自己就是自己天然的QA；如果有别的团队也在用你开发的模块，那么，别的团队也就很自然地在帮你做测试了，而且是最真实的测试。
你可能会说吃狗食就是个笑话，倘若换成我，项目做得不好，就离职走人，让后来者去吃我的狗食。这个的确是这样的，但是想一想，你为什么在一开始不提醒他？另外，如果你的团队在设计评审和代码评审里没有把好关，让某位程序员蒙混过关，那么这为程序员离职后带来的问题还是要由你的团队来解决。于是整个团队都在吃自己的狗食，这很公平。痛苦过一次，你的团队就不敢随意招人、不敢随意评审代码、不敢让某位员工只做一块东西了。而这最终还是没有逃脱吃狗食的范畴。
关于自动化测试。这是一个机械的重复劳动。我想让测试人员思考一下，你是否在做这样的事？如果你正在做这样的事，那么，你要思考一下你的价值了。但凡是重复性比较高的机械性劳动，总有一天要被机器所取代。
关于线上测试。我们都知道，无论自己内测的怎么样，到了用户那边，总是会有一些测试不到的东西。所以，有些公司可能会做用户验收测试（做产品的公司会叫Beta测试）。无论怎么样，你总是要上生产线做测试的。对于互联网企业来说，生产线上测试有的玩A/B 测试，有的玩部分用户测试。比如，新上线的功能只有10%的用户可以访问得到，这样不会因为出问题让全部用户受到影响。做这种测试的人必然是开发人员。
评论：
30 楼 javer 2012-04-16 17:11
29 楼 surelei 2012-04-14 21:38
QA和测试还没搞清楚。。。
28 楼 liusu 2012-04-13 13:34
确实开发人员的工作重心决定了他不可能完整而且系统的对整个系统的进行巨细无遗的测试。但是有个关键是现在好的测试人员太难找了。 我经过的两个项目QA完全不懂编码而且也没有兴趣接触编码，这样即使是使用一些很自动的工具（类似录制测试用例）他们也没有办法接手。 最终只能分出部分开发人员去实现QA已经写好的TestCase。
27 楼 streamone 2012-04-13 09:05
“没搞过测试也不会测试”！那贵公司的“她们”是怎么被招进公司的？
QA不做测试就像测试不去干QA该干的活儿，做好自己职责内的事儿，你懂？
26 楼 allloveend 2012-04-12 19:42
LZ这篇帖子完全跑题,
25 楼 kyfxbl 2012-04-12 16:26
个人感觉测试还是有用的，但是好的测试少。QA根本没用，就是混日子的
24 楼 andyflyingcat 2012-04-12 14:14
不过也难怪，很多公司规模也不小，TMD也分不清这些角色职责。主要是sb领导太多
23 楼 grantren 2012-04-12 13:49
很多公司，理想状态的开发测试比例为1:1.
另外在很多公司，QA式独立的部门，并不是测试。
22 楼 mylazygirl 2012-04-12 13:44
让我想到了这张图
http://imgsrc.baidu.com/forum/pic/item/6a600c338744ebf846b2be80d9f9d72a6159a74a.jpg
21 楼 faye.feelcool 2012-04-12 13:10
主要还是国情使然，牛人作为一种稀缺资源，不是那么的多，所以牛人在很多公司都被放在开发上。然后就是由什么cmm，cmmi等认证热，将一堆什么还不明白的新人推向QA领域。
很多公司，做测试的都是因为做开发不适合才放到测试中的，而不是他在测试上有天分。
所以，不要怨恨，不要怨念。而应该合作，和体谅。在测试不够强大时候，开发的确要自行把关，测试只是最后一步，发布前的最后一到工序而已，不要把一切都押宝在最后一刻。而且，作为开发人员也得有清醒的认识，自己才是一切的根源。
要不要专职的QA，看公司规模，看项目规模，看技术实力，没有丰富人力和资金，就不要那么大的排场。
20 楼 hulei1982 2012-04-12 10:52
赞同8楼说的第3点，开发人员对于没有技术含量的重复性工作是不会认真完成的。
不管是QA还是TE在不同的公司工作职责不一样，这个不纠结。
目前在我们公司是开发经常加班，测试从不加班，开来测试也要背负点责任才行。
19 楼 Gorehowl 2012-04-12 10:49
我只要求我的经理懂开发就满足~
18 楼 oaklet 2012-04-12 10:21
17 楼 没头脑 2012-04-12 09:33
16 楼 ronnin 2012-04-12 09:29
2. Dev配备测试秘书，协同dev对测试工作和软件质量负责。
这个秘书会开发，起码会写单元测试代码，制作测试数据（比如SQL）等
测试类型可以包括大部分：单元测试、功能测试、回归测试, 甚至包括性能测试和Soak Test.
3. 规模比较大的团队或产品，也需要一个QA保障最终产品质量，做集成测试，与运营部、市场部等协调。
12 楼 唇角轻扬 2012-04-11 16:55
+1
11 楼 cgd123 2012-04-11 15:53
10 楼 neptune 2012-04-11 15:50
9 楼 nemohq 2012-04-11 15:32
8 楼 nemohq 2012-04-11 15:29
楼主说的有点像Scrum里边的理想情况了，不区分开发和测试的职责，大家一起保证产品的质量。
同意楼主关于QA需要懂技术的观点，但是其它就有些偏激了：
1. 楼主文章里的QA团队可以全部fire掉了，根本就不是专业的测试人员，没有基本写test design的能力，没有责任心。而且楼主说的都是手工的QA，还有很多做白盒测试和自动化测试的QA，楼主不能以偏概全。至少我知道的一个测试团队他们可以帮助开发找到memory leak，并且给出fix的solution，开发人员经常需要测试团队的帮助来搭建单元测试的框架，代码checkin时的自动化测试环境等。
2. 楼主把开发人员说的好像很完美一样，如果仿照楼主这个说法，可以写个文章叫“我们需要专职的Dev吗？”。一个技术强点的QA，有测试的经验，写出来的代码质量比专职的开发好的多。
3. 楼主说的这种理想的软件工程师基本上是很少，甚至是不存在的。试问哪个开发可以耐下心去一点点的做功能测试？ 即使是写自动化测试的脚本，对于这些眼高于顶的开发人员来说就是没有技术含量的东西，有多少人可以认认真真的完成？结果的分析呢？对他们来说这个就是浪费时间，有时间还不如去学下cloud，mobile这些现在热门的技术，甚至有很多开发fix完defect后，没进行完全的确认就丢到测试团队，来来回回让测试团队重做很多次的也有。
总之，术业有专攻，开发人员有自己的局限：太专注单独的功能点实现，太专注技术，对客户需求不清楚，对测试的技术和策略没有了解。 测试也有自己的局限：对代码了解不够，对技术不敏感。
7 楼 icefishc 2012-04-11 14:32
6 楼 _mjhx 2012-04-11 14:31
5 楼 aninfeel 2012-04-11 13:51
我们公司的测试部门也这么干——原因吗？比较容易找到bug，而找的bug越多，绩效越高。
4 楼 oxware 2012-04-11 13:50
最关键的是，测试团队的头头和开发是完全独立的，直接对总经理负责，任何开发团队都推卸不了责任。当然负的责任也更大，线上如果出了事故首先也要追究测试的责任
