咱们须要专职的QA吗？ 现代软件工程讲义 9 测试 QA 的角色和分工 对《咱们须要专职QA吗？》的回应

转自:  http://coolshell.cn/articles/6994.html

 

咱们须要专职的QA吗？

这个文章必然是有争议的，我在个人微博上讨论过不少次了，每次都是颇有争议的。有不一样的观点，有争论老是一件好事，这样能够引起你们的思考。因此，对于个人这篇博文，若是你赞同个人观点，我会感到高兴，若是你会去认真地深刻思考，我也会高兴，若是你反对，不要紧，能够讨论。

在此以前，我想说明一下我观点里的这个“专职QA”是怎么定义的。

1. 其是不少公司成立的专门作测试的技术人员，仅测试不开发。
2. 这些QA对于软件开发技术并不熟悉，甚至不懂。

我经历过一些公司都有专职的QA团队（专职的测试人员），自从上个公司个人开发团队在一个项目上被QA部门搞得一团糟，我愈来愈怀疑专职QA存在在乎义。个人观点不必定对，但请让我鲜明地表达一下——我以为是不须要全职的QA的，甚至不须要QA这一专职角色或部门，由于，不懂开发的人必然作很差测试。就像不懂开发的研发经理必然管很差研发团队同样。我愈来愈以为Dev应该应该是作测试最合适的人选，这必然是将来的趋势 （由于我已经看到了中国程序员的进步，相比起10年前，今天的程序员已是很是全面了，再来十年，必然证实个人观点是对的）。

在我正在展开说明以前，我想引用两篇文章：

两篇文章

一篇是  “On testers and testing”(中文翻译)，本文的做者Sriram Krishnan是一名程序员，曾在Yahoo和微软工做过，开发过不少软件，曾被纽约时报报道，写过一本书，本文是他的一篇博客。他在文章中表达了这几个观点——

大 多数的开发团队并不须要一个独立的测试角色。即便要有，那么全部的开发时间比上全部的测试时间应该 >20:1的。。证据吗？光看看一些从古至今最成功的软件开发团队就知道了。不管是当今的Facebook，仍是30年前最初的NT团队，不少伟大 的产品都是出自没有或不多测试人员的团队。

开发人员应该测试本身的代码。没什么可说的。背后的道理并不重要。这包括单元测试，全覆盖的自动化测试或手工测试或组合测试。若是你的开发人员不能/不肯意或认为这“不归我管”，那你须要更好的程序员。

另外一篇文章是邹欣的“现代软件工程讲义 9 测试 QA 的角色和分工”，这是一篇很不错的文章。他在文章里提到了分工的必要性，好比第三方的鉴定机构，而且也指出了分工的一些问题，好比，画地为牢的分工，无明确责任的分工，等，这些问题直接命中了分工的要害。我隐约以为，我和邹欣的不少观点是相同的，咱们内容上是相同的，只是形式上还有分歧。另外，个人观点太鲜明了，从而容易导向极端的理解。

你看，咱们都赞成，Dev要懂测试，QA要懂开发，只不过度工不一样，既然你中有我，我中有你，那就不要分彼此了，一块儿携手开发测试吧。（另外，我我的以为不懂开发的测试人员不可能测试得好）

—- update—- {

     //本篇文章出来后，网上出现了一些对此讨论的文章，我一并更新在这里
【 《对《咱们须要专职QA吗？》的回应》做者：@段念-段文韬 】
【 《关于“咱们须要专职的QA吗”》做者：@Jacky郭 】
【 《咱们须要专职的QA吗？（评）》做者：@Monkey陳曄曄 】
【《 《咱们须要专职的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部门的同窗们就像没发生什么事似的，依然正常上下班。哎……

为何会这样？我以为有这么几点缘由（和邹欣的观点同样）

1. 给了QA所有测试的权力，可是没有给相应的责任，
2. QA没有体会过软件质量出问题后的痛苦（解决线上问题的压力），致使QA不会主动思考和改进。
3. QA对Dev的开发过程和技术彻底不了解，增长了不少QA和Dev的沟通。
4. 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，若是有别的团队也在用你开发的模块，那么，别的团队也就很天然地在帮你作测试了，并且是最真实的测试。

• 你可能会说吃狗食就是个笑话，由于若是是我，我把事干烂后，就离职走人了，让别人去吃个人狗食。 这个在现实中的确会发生，也是很现实的。可是想想，你为何在一开始让他把事干烂了？另外，若是你的团队在设计评审和代码评审里没有把好关，让某人把事 给干烂了，那么这我的的离职带来的问题仍是这个团队来扛，因而整个团队都在吃本身的狗食，挺公平的。痛苦过一次，你的团队下次怎么干了，就不敢乱招人了， 就不敢随意评审代码了，就不敢让人只作一块东西了。最终仍是没有逃脱吃狗食的范畴。

• 关于系统集成测试。所 谓集成测试，就是把多个开发团队开发的模块集中起来测试。由于开发人员可能没法看到全局，不了解别个团队的系统，并且步调不一，因此须要有统管全局的专职 的QA进行统筹规划并作测试。对这个方面，我并不反对，在实际操做过程当中，好像的确用专职的作集成测试的QA统一调度各团队的时度更有效一些。不过，这还 是不能让我中止去思考两个问题，1) 若是开发人员看不到全局，他能开发出更好的软件吗？2）这个全职的作集成测试的QA难道不能是各个团队的骨干Dev来组成吗？3）统一调度这个事，不更像 是Project Manager要作的事吗？

• 关于自动化测试。所谓自动化的意思是，这是一个机械的重复劳动。我想让测试人员思考一下，你是否在干这样的事？若是你正在干这样的事，那么，你要思考一下你的价值了。但凡是重复性比较高的机械性的劳动，总有一天都会被机器取代的。

• 关于线上测试。 咱们都知道，不管本身内测的怎么样，到了用户那边，老是会有一些测试不到的东西。因此，有些公司会整出个UAT，用户验收测试。作产品的公司会叫Beta 测试。不管怎么样，你老是要上生产线作真正测试的。对于互联网企业来讲，生产线上测试有的在玩A/B测试，有的玩部分用户测试，好比，新上线的功能只有 10%的用户能够访问获得，这样不会由于出问题让所有用户受到影响。作这种测试系统的人必然是开发人员。

好吧，我暂时写这么多，我会视你们的讨论再补充个人观点的。

—– update  2012/4/11—–

一些人以为我是在泄私愤，我可以理解为何我会被这样误解，可是没有关系，不少新东西新观点老是会被误解的，我坦然面对。请你们抛开个人这些情感因素，单纯的思考一下，没有专职QA的的团队架构是否有积极的意义在里面？

再补充一点，你们思考一下，QA是保证质量的，可是不少QA是在作测试，软件质量是测试出来的吗？若是不从需求分析，软件设计，代码实现上作好控制，到测试的时候你还怎么保证质量呢？

（全文完）

欢迎关注CoolShell微信公众帐号

（转载本站文章请注明做者和出处 酷 壳 – CoolShell.cn ，请勿用于任何商业用途）

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——