首页 > 技术管理, 流程方法 > 我们需要专职的QA吗?

我们需要专职的QA吗?

2012年4月11日 发表评论 阅读评论 54,501 人阅读    

这个文章必然是有争议的,我在我的微博上讨论过很多次了,每次都是很有争议的。有不同的观点,有争论总是一件好事,这样可以引发大家的思考。所以,对于我的这篇博文,如果你赞同我的观点,我会感到高兴,如果你会去认真地深入思考,我也会高兴,如果你反对,没关系,可以讨论。

在此之前,我想说明一下我观点里的这个“专职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页面 寻找遗失儿童。 ===——
好烂啊有点差凑合看看还不错很精彩 (46 人打了分,平均分: 4.59 )
Loading...
  1. AmyOrchid
    2013年11月14日13:10 | #1

    赞同

    未央哥 :
    一个典型的程序思维产生的出来的结论,认为代码就是everything.
    测试对接的不光是程序员,还有各种产品需要及设计者。不过有句话我很赞同,不懂开发的做不好测试,所以我们团队里,所有测试都是开发出身。也许有人问,为什么开发要去做测试?那我告诉你答案吧,你的问题错了,因为你认为测试是给开发打杂的,服务的,低开发一等的,所以才有这个疑问。

    我也同意作者的观点,不懂开发的测试人员是做不好测试的,也会浪费DEV 的时间。

  2. psistorm
    2013年11月27日13:29 | #2

    优秀的程序员确实不需要测试人员的协助就可以自己测试得很好,但是优秀的程序员少之又少,大部分公司顶多就一个够格,所以为了考虑其他的程序员,不得以引入测试人员来协助,不理解不需要测试人员的程序员境界一般还不够

  3. 2013年12月2日14:53 | #3

    @未央哥
    是的,那个问题确实是错的,但是面对社会的偏见,又不可能心里没有个思考
    而且lz这个问题,我觉得其实并不是针对专职qa(不做开发的qa),而是能力有残缺的qa(没有开发能力的qa)。我也是qa,而且是我所在项目的唯一参与改代码的qa,我改的代码提交以后也和开发代码一样经过ut,并接受其他qa的再测试,因为,我觉得我语言表达能力可能有欠缺,很多时候,与其向开发解释问题,不如我把问题解决掉,让他们看到答案,他们也就懂了到底是什么问题,然后也许我的解决并不圆满,但是他们知道了要改什么,可以继续完善。代码是工程师之间交流的最直接(虽然未必最好)方式

  4. EarthCoder
    2014年1月7日17:31 | #4

    我在过公司里,是安排比较优秀的开发人员担任QA。

  5. 咦?狗又在叫
    2014年1月13日17:28 | #5

    我只能说,你根本不了解QA的工作。QA不仅仅是对技术的掌握,更是对思想的了解。虽说程序自己写的代码比别人更了解,可那又怎样呢?你媳妇还和你结婚了呢,不照样也找别的男人?这道理是一样的。总一副万事通的样子,实际你根本就没了解彻底。说不好听的,是因为QA总让你修改问题,才导致你这么奇葩的心里吧。

  6. 测试人员
    2014年1月20日16:09 | #6

    说的很好,我是通信行业的UAT测试人员,那边的开发和测试人员经常未经同意,私自私改方案@Hacker D

  7. 2014年5月13日15:00 | #7

    写这篇文章的时候,作者肯定工作没几年,且没有在bat、淘宝等这样的公司呆过。明显的以偏概全,也完全没有理解QA的概念,和一些牛人qa工作过,肯定就没有这篇文章了。

  8. fisher
    2014年5月20日15:42 | #8

    如果有十分负责任的员工,那真的是好运气,否则需要好的管理,qa不行,不负责任,是他们的manager的问题,这个管理者有真的真抓实干吗,还是就会转发一下邮件,做个邮差,搞搞办公室政治,上班就网聊网购什么的,因为做技术苦,所以很多人要去做管理,但并不一定是合格的管理者。

  9. bobby
    2014年6月9日17:24 | #9

    @Rocky
    2K的老婆的工作质量=10K的资深DEV?

  10. 2014年7月7日11:00 | #10

    victor :

    写这篇文章的时候,作者肯定工作没几年,且没有在bat、淘宝等这样的公司呆过。明显的以偏概全,也完全没有理解QA的概念,和一些牛人qa工作过,肯定就没有这篇文章了。

    呵呵。

  11. stephenh
    2014年8月2日20:22 | #11

    有一点,QA的测试计划是需要Dev来sign off的。

  12. 2014年8月13日19:52 | #12

    本人就是专职QA,对楼主的某些观点不敢苟同。
    但想做好QA这份职业,确实需要具备一定的DEV能力,能看懂代码,能理解程序逻辑的深层逻辑才能做好这份测试。

  13. Adam
    2014年8月15日12:32 | #13

    @陈皓
    每个角色对事物的看法都有不同的视角,但是那个东西做的好不好和那个东西本身好不好是不同的纬度。

  14. richrenf
    2014年8月26日20:06 | #14

    很赞同,不会做测试的开发不是好开发,不会做开发的测试不是好测试。

  15. Alvinte
    2014年11月6日17:58 | #15

    严重同意作者的观点!!
    在现在国内环境中,我特么也被中国QA这种逗逼角色深深的伤害中!!
    不能否认QA本身在一个成熟的SE流程中的重要性,我们需要的是专业的QA,而且这种QA也只能是专业SE过程的一部分。试问国内到底有几家公司能号称自己是专业的SE流程?只有在这种环境下,我们才需要所谓的专职QA,否则只能给Dev甚至Prod带来各种逗逼效果。
    最最奇葩的就是我遇到的:我们公司换了好几拨QAManager,每新来一个都号称自己多牛逼,并带来一些新的东西,比如scrum,预发布 等等,我不否认这些都是很牛逼很好的理念,也有很好的成功案例,但是特么你要适合当前公司的现状好么,被这些逗逼搞了一通之后,研发效率大幅下降,甚至影响到产品部门,而且QA团队本身一点儿提升都没有,各种bug都在线上才反映出来,每次上线都所有Dev手忙脚乱好几天,还不如从前那么单纯的时候,真不如Dev自己做QA的工作。
    更逗逼的是,这些QAManager做了一段时间,发现做不下去了,就跑路了,然后留下一堆粪坑,让Dev持续在这种逗逼氛围中填坑!真心受不了!!
    当然我只说现状而已,从概念上讲QA本身尤其不可取代的必要性,然而理想和现实有着赤裸裸的差异,从概念上说一个观点是不是对,没有任何意义,必须理论结合实际。 我就敢说现在市面上至少有一大半的软件公司,适合楼主的观点,而且我也敢说其中有一部分与楼主同样理念在运作的公司,他们运转的很好!你们没必要抨击他们是不是成熟,因为那就是事实,没有一个东西是不经过发展直接达到巅峰的。
    最后,什么叫做好,适合的才是最好,没有教条主义,没有经验主义,事实是检验真理的唯一标准!

  16. 毛桃丫头
    2015年4月21日14:02 | #16

    【真正的工程师是能真正明白软件开发不单单只是coding,还更要明白整个软件工程】。目前需要QA的主要原因就是大多数软件开发者只是在coding。

  17. 2015年12月12日13:30 | #17

    DEV既做开发又做测试还做运维 真要看业务忙不忙了 我觉得一个人要在这么多维度上把事情做好 接触各种不同的体系工具 想走得深很难 往往一个人在一个点上做到专家就很难 何况多个点 何况各种技术都要不断学习进步

  18. 2015年12月13日16:38 | #18

    楼主傻逼。开发全能的话 ui也不用要了 自己可以搞 产品也不用要了,自己可以搞 老板也不用要了。自己可以当 恩。

  19. 2015年12月13日16:38 | #19

    楼主傻逼 不解释

  20. woke
    2015年12月23日15:38 | #20

    @gcd0318 我很不赞同你的这种做法。虽然问题得到解决,但是会导致管理混乱。

  21. gavin
    2016年2月15日16:04 | #21

    对于规模比较大的公司需要测试,因为开发懒得干这些事情。而且开发人员喜欢与他们扯皮,扯皮有利于搞清楚需求。这些公司中的DEV其实都是纯粹写程序的,完成功能,既不设计,也不出文档。

    可能创业型的公司是不需要QA的。DEV可以包揽一切,但是他们有可能坚持不下来,一个人的确可以把这些事情都干了,但是找几个帮手不是也挺好的?而且许多QA都是女孩子呀。

  22. gavin
    2016年2月15日16:07 | #22

    @陈皓
    哈哈

  23. 小小妮子
    2016年2月25日11:00 | #23

    “如果一个人懂开发,为什么只让其专职做测试呢?这样的程序员分工合理吗?把程序员分成两等公民有意义吗?试问有多少懂开发的程序员愿意只做测试开发呢?”做开发还是做测试,这个大多数都是自己的选择,难道懂开发就非要做程序员才是正确的人生选择吗?可能您对合格开发的界定标准太高了,这个社会的人员存在不同的水平等级,您的要求应该都算是顶尖的人才了,在整个社会又能有多少在金字塔顶尖呢?理想化的想法那就是极端。

  24. webwombat
    2016年4月11日18:19 | #24

    的确,专职QA最喜欢干的工作其实不是去测试保证系统质量, 而是去尽量多找BUG保证自己的KPI, 开发出什么问题他们才没兴趣知道, 我只关心我能不能按时上下班,能不能少干点。。。等等, PM啥的也是一个丘的豹,最后就把压力全放在Dev身上。

  25. KingTom
    2016年4月25日17:56 | #25

    对你说的很赞同,我一直在做测试,看你这个贴子是三年前的事儿了,看了之后决定学了一门语言,今天翻到又看到这篇文章,感受到了你文章里所写的所有内容,以前我的目标是测试加构,现在我离这个目标中间还有一个目标就是全栈工程师,当达到这个目标后,再往后走,会更水到渠成

评论分页
1 3 4 5 6994
  1. 2013年11月10日16:16 | #1
  2. 2013年11月19日22:39 | #2
  3. 2014年1月22日13:57 | #3
  4. 2014年2月24日09:01 | #4
  5. 2014年3月7日03:17 | #5
  6. 2014年6月9日09:06 | #6
  7. 2014年6月12日12:44 | #7
  8. 2014年6月30日17:23 | #8
  9. 2014年7月1日13:26 | #9
  10. 2014年8月3日05:48 | #10
  11. 2014年10月30日01:05 | #11
  12. 2014年11月18日21:38 | #12
  13. 2015年12月13日12:55 | #13
  14. 2015年12月13日14:58 | #14
  15. 2015年12月13日17:54 | #15
  16. 2015年12月14日21:57 | #16
  17. 2016年1月7日22:19 | #17
  18. 2016年1月8日19:24 | #18
  19. 2016年1月8日19:49 | #19
  20. 2016年2月16日16:13 | #20
  21. 2016年3月23日08:05 | #21
  22. 2016年5月3日09:08 | #22