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

我们需要专职的QA吗?

2012年4月11日 发表评论 阅读评论 38,350 人阅读    

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

在此之前,我想说明一下我观点里的这个“专职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.cn ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
好烂啊有点差凑合看看还不错很精彩 (42 人打了分,平均分: 4.74 )
Loading ... Loading ...
  1. 挽弓挽强
    2012年4月11日08:55 | #1

    mark,等会肯定会有人challenge的,我等着看比文章更精彩的评论

  2. 2012年4月11日09:10 | #2

    自己测试时必须的,其他测试也是必不可少的;
    我个人觉得应该从开发人员里面组建一个QA小组比较好

  3. biaoli
    2012年4月11日09:17 | #3

    没有QA的sign off, 我们的东西上不了线。。。

  4. imzrh
    2012年4月11日09:20 | #4

    QA会开发的话确实对团队帮助很大啊,如果QA不懂开发的话取消单独的QA部门让QA和DEV直接在一个小组内,共同办公,需求分析、每日例会、test case review一块参与也有帮助。

  5. St.Charles
    2012年4月11日09:25 | #5

    我十分同意作者的观点
    但是现实是大多数QA就是不知道开发,大多数程序员就只跑通了自己的负责的模块,其余的要么不管要么管不了
    所以说……能像文中那样当然是最好了,只是很难

  6. 2012年4月11日09:26 | #6

    你所经历的测试组不至于水平这么差………
    但测试必须懂开发,这点很赞同。并且对测试要求其知识必须非常全面.

  7. 小杰
    2012年4月11日09:31 | #7

    其实蛮有道理的,qa团队有的时候反而降低了效率

  8. 2012年4月11日09:40 | #8

    昨天就猜到皓哥要写一篇关于测试的。infoQ第一时间竟然截录了微博内容!

  9. Ben
    2012年4月11日09:46 | #9

    我觉得测试的工作由PM+DEV同时来完成会更好咯

  10. jinghli
    2012年4月11日09:47 | #10

    一个好的QA是最懂产品的人。QA存在有绝对的意义,即便是不会写code的QA,简单的例子,光靠写unittest来覆盖测试是不可能的,还得人用。这个过程是最能出高质量bug的。

  11. bitwolaiye
    2012年4月11日09:47 | #11

    很同意你的这个观点”软件开发,真的不需要专职的QA,更不需要只写代码不做测试的专职的Dev。”
    其实我以前开发也不写任何测试,包括单元测试,但是我觉得那是错的。自己都觉得羞愧。当前做一个项目,我就在开始改正这个错,虽然覆盖率也不高,但比之前至少方向对了。
    我觉得,这个观点虽然对,但实现起来太难。主要是涉及人员调整,不是公司负责或者团队负责不可能解决这个。像我这样的程序员这样的建议都最好别提,原因很简单,这是在砸很多人的饭碗。
    像我所在的团队,测试人员其实已经比研发人员还要多了(1.5倍),团队一个负责的还是测试出身。所以无奈。

  12. silverhawk
    2012年4月11日09:48 | #12

    完全同意,测试一旦作为一个工种,就会制度化把原来想积极解决问题的人变成一味增加测试工作量而完全不考虑实际情况,忙于完成或者向上面交代他全面覆盖了多少。更要命的是他们会把简单问题复杂化,或者将复杂问题简单化归结为几个高层耳熟能详的问题。我现在的办法是测试之前开发和测试要一起商量怎么测试,test case不一定每个都看,但是一定要只带大概怎么操作。

  13. 2012年4月11日09:56 | #13

    没有QA部门,哪来ppmm?

  14. Rocky
    2012年4月11日10:08 | #14

    我是一个多年的老测试了,干过黑盒,也做自动化,部署过环境,开发过测试工具。
    皓哥的观点,有合理的方面,我也谈谈。

    1. 首先从老板的角度看。
    ==========================================================
    皓哥的博文中提到了开发与测试相关人员,那么多公司老板的角度让我们看看为什么会产生测试组:
    首先,公司在产品没有 成功 之前 是没有专职测试的, 只有开发,产品设计,lab admin部署环境一类的角色。
    然后,销售人员出去给客户做demo, demo 过程中经常发生 事故,事故原因多种多样,当然销售是不关心原因的。
    老板大怒, 于是成立了测试部门,第一批测试人员是开发人员的老婆们。 测试部门的责任就是保证产品是绝对work的, 让demo不再失败。

    如果我们假设老板是皓哥,老板会对开发人员发火,让他们去测,但结果会怎么样呢?
    开发人员都忙于开发功能,研究技术实现,最多做一下基本case验证,根本没有时间做全面测试。
    如果老板一定要开发去做全面的测试,也不是不可以,时间,时间,老板会发现,本来一个新功能一月,现在要三月。

    特别要说的是,由于现在产品各个模块的分工越来越明确,单个模块的开发只熟悉自己的东西,而用户用到的功能是由多个模块协作完成,所以要做全面integration testing, 需要开发理解整个产品。而实际上一个团队时,可能只有少数leader, 资深人员也才能理解所有的东西。
    当然由于皓哥是老板,要求所有开发人员都全面理解产品是非常合理的,也是应该的。不过这里需要的是什么?时间,还是时间。

    这样,让我们从老板的角度算一下账:
    1. 不要测试部门,所有开发自测,那只能答应他们的时间要求。
    做个简单假设,一个项目本来计划1个月,10 个开发,每人1万,共花费10万。由于要求开发人员自测,项目时间不得不改为2个月,所以总计花费20万。

    2. 由开发人员的老婆们来测。
    由于在san jose, 老婆们都是陪同来US, 基本上没有正式工作, 每人月给2K就可以了。 10个老婆2万,所以总计花费 12万。

    于是老板决定,还是成立专门的测试组!

    =============================================
    未完待续

  15. Bright Fire
    2012年4月11日10:16 | #15

    QA不是测试人员吧,QA管的是你的开发流程吧
    btw:测试不懂开发其实是可以的,但是这样的测试应该不会走很远.
    好的测试团队会给你提供很多帮助,比如如何有效率的提高case的覆盖率,快速检出最有价值的缺陷,搭建自动化测试环境等等,现在的软件开发和以前不一样,讲究的是team working,各部门人员之间的交流是很重要的,包括开发人员和测试人员

  16. qingchunjun
    2012年4月11日10:22 | #16

    一直以来都是关注楼主的文章,但很少发言。今天看到这篇文章,觉得有些不太蛋定了,有些话想说一下。
    我自己做了七年的软件测试,我分析楼主之所以会写这篇文章,估计是以下几个原因:
    1. 第一感觉是楼主遇到了“史上最差”“QA团队”,已经对测试的东西留下了非常严重的心理阴影,所以从内心感觉抗拒。
    原文“发现很多的test case这样写到 – “Expected Result:Make sure every thing is fine“,我相信不但是开发人员,任何一个专业的测试人员对这样的case都会嗤之以鼻,简直太不专业了,单从这点就可以看到楼主所经历的软件测试是多么恶心的一种经验,所以你憎恶测试我觉得可以理解,就跟一个处女在遇到一个花心男被玩弄后,再也不信任任何一个男人一样。
    2. 第二个感觉是楼主对软件测试确实是外行。软件测试其实分很多种,并不单单您在文中所强调的开发测试。其实如果你对测试这个行业了解比较多的话,你就会发现其实大部分的测试都是黑盒+手工的测试方法在测。或许您从开发的角度觉得这些都很没有技术含量,但其实每种测试类型都有它的目的性,而且测试依据也是不一样的。比如黑盒测试本来就不需要测试人员去了解系统内部的代码结构,只要知道产品需求,并且去验证产品功能是否符合需求就行了。他凭什么要去了解代码呢?而开发人员之所以只适合干单元测试是因为并不是每个开发人员都了解产品的需求,他们大部分都只知道看设计文档,照着做就OK,他们或许并不能从整个功能或者是产品的角度去进行验证。我觉得可以用一句话来总结开发做的测试和测试做的测试之间的区别:前者是通过测试来保证我们在正确地做事,而后者则通过测试来保证我们在做正确的事。这里多余的话不说了,推荐楼主如果有时间的话,倒可以去推荐你去看基本关于测试的书:《The art of software testing, 2nd Editon》,《lessons learnt from software testing》,《微软的软件测试之道》,或者一些测试的论坛,国内的51testing,国外的http://www.sqaforums.com等等。任何一样东西都最好在有深刻了解之后再发表评论会显得更专业一些,就跟您了解C/C++一样。
    3. 第三个是对于自动化测试的误解。原文”所谓自动化的意思是,这是一个机械的重复劳动“,楼主知道自动化测试真正的意义吗?自动化测试确实是利用电脑来进行一些看似重复的测试工作,但这些所谓”重复“并不是由于操作的模式化引起的,而是由于在每个迭代周期,软件release出来之后,必然要做的一些回归测试等等领域的测试,开展自动化是最多的。这样做的意义是可以快速地让电脑代替人脑去check一些basic的功能,而把测试人员解放出来去测试业务逻辑更加复杂的场景,从而尽可能多地由人脑去发现更多的缺陷。

    诚然,dev懂测试,测试懂dev是最理想的一种情况,但现实是99%以上的公司无法达到这样的一种状态,很多公司里面测试甚至没有机会看到代码,而且确实也没必要。举个例子,在敏捷测试中,发现缺陷最多的就是ET,探索性测试。这也是一种黑盒加手工的测试方法,它不要求测试具有开发能力,但要求测试人员能够边学习系统的需求和产品特性,再根据自己以前的经验,再最可能发现bug的地方快速找到bug。开发和测试人员之间如果不能建立起对产品质量负责的态度,而是想着对方在找茬,那任何人都做不好测试,就算开发人员自己做,他也不想找自己的茬。

    最后一点,请不要混淆QA和QC之间的区别,本文里的QA实际上是指的QC(Quality control).关于QA和QC之间的区别可以参考:http://www.softwaretestinghelp.com/does-quality-assurance-remove-need-for-quality-control/ (顺便提一句,这里也有不少非常好的关于测试的文章)

    如果这个世界只有一种观点,那是一件多么可怕的事情,所以以上观点欢迎拍砖,也欢迎讨论。

  17. Tiger1102
    2012年4月11日10:29 | #17

    给了QA全部测试的权力,但是没有给相应的责任,
    QA没有体会过软件质量出问题后的痛苦(解决线上问题的压力),导致QA不会主动思考和改进。
    QA对Dev的开发过程和技术完全不了解,增加了很多QA和Dev的沟通。
    QA对软件项目的设计和实现要点不了解,导致了很多不有效的测试。

    同意这些观点,不懂开发的测试人员应该是做不好测试的,如果测试人员没有相应的责任和解决线上问题的经历,用心度和提升度是比较慢的;
    个人认为在商业软件公司中测试人员是需要的,但是测试人员的基本要求应该满足以上几点,测试的要求能力应该比开发高,对相关技术应该非常熟悉,才能真正做好测试。最主要要和开发人员一起工作。

  18. kkyin
    2012年4月11日10:31 | #18

    陈兄,能推荐一些你平时常看的技术类博客吗

  19. 猫仔罐头
    2012年4月11日10:31 | #19

    QA是必须的,但不懂的反馈回报的在开发上是个悲剧,这点我相信很多开发人员都有切身感受(我还遇过以穿梭机等级验证家用产品的,老天 这玩意售价还没10元)。
    程式设计师自我测试中往往会不自觉的绕过自己所埋下的陷阱,但一般使用者却会跌下去,这时候纯洁如白纸的QA就是要把这类问题抓出。
    但可惜的是我看过太多QA完全不知道如何重现自己所发生的问题,往往双手一摊直说:他就崩溃了,原因不知道、过程不知道、操作方式不知道,还有连崩溃不正常了也不知道。
    良好的QA必须严格尊守实验设计法则,这是品质管理最重要的一个环节,依巡设计师所给予与一般使用者相同的说明文件,来研究及操作,并抓出问题重现反馈给设计团队。
    QA团队是不能与设计团队脱勾的,良好的团队应该在产品设计末期保留1/3或1/4设计开发人员合并到QA团队中,而业务也需派人参与,才会最贴近客户需求,也才能最快完成上线工作。

    总结QA是产品上线最重要的一环,但不知道回报问题和重现的QA是不需要完全可以舍弃的,比猴子还不如(monket test),因为除了制造麻烦外,没有任何贡献

  20. YufunHe
    2012年4月11日10:33 | #20

    楼主说的有点像Scrum里边的理想情况了,不区分开发和测试的职责,大家一起保证产品的质量
    同意楼主关于QA需要懂技术的观点,但是其它就有些偏激了:
    1. 楼主文章里的QA团队可以全部fire掉了,根本就不是专业的测试人员,没有基本写test design的能力,没有责任心。而且楼主说的都是手工的QA,还有很多做白盒测试和自动化测试的QA,楼主不能以偏概全。至少我知道的一个测试团队他们可以帮助开发找到memory leak,并且给出fix的solution,开发人员经常需要测试团队的帮助来搭建单元测试的框架,代码checkin时的自动化测试环境等
    2. 楼主把开发人员说的好像很完美一样,如果仿照楼主这个说法,可以写个文章叫“我们需要专职的Dev吗?”。一个技术强点的QA,有测试的经验,写出来的代码质量比专职的开发好的多
    3. 楼主说的这种理想的软件工程师基本上是很少,甚至是不存在的。试问哪个开发可以耐下心去一点点的做功能测试? 即使是写自动化测试的脚本,对于这些眼高于顶的开发人员来说就是没有技术含量的东西,有多少人可以认认真真的完成?结果的分析呢?对他们来说这个就是浪费时间,有时间还不如去学下cloud,mobile这些现在热门的技术,甚至有很多开发fix完defect后,没进行完全的确认就丢到测试团队,来来回回让测试团队重做很多次的也有

    总之,术业有专攻,开发人员有自己的局限:太专注单独的功能点实现,太专注技术,对客户需求不清楚,对测试的技术和策略没有了解。 测试也有自己的局限:对代码了解不够,对技术不敏感

  21. kanbol
    2012年4月11日10:47 | #21

    不是不需要专职的QA,而是要明确专职QA的技能和工作内容以及应该承担的责任

  22. 2012年4月11日10:48 | #22

    测试人员(Tester)和质量保证(QA)应该不是一个概念吧?

  23. Bright Fire
    2012年4月11日10:51 | #23

    各位兄弟们,这么久了,难道大家还没发现作者文中的QA和现实的QA不是同一个东西吗?
    作者文中的QA是说测试人员,现实中的QA的话,我贴一下Wiki的词条吧,
    WIKI:
    Quality assurance (QA) refers to the planned and systematic activities implemented in a quality system so that quality requirements for a product or service will be fulfilled [1]. It is the systematic measurement, comparison with a standard, monitoring of processes and an associated feedback loop that confers error prevention. This can be contrasted with Quality “Control”. which is focused on process outputs.

  24. z
    2012年4月11日10:56 | #24

    成本,成本。。。

  25. hunxiaobing
    2012年4月11日11:09 | #25

    这成本估算的问题在于只看到眼前,而太多现实的例子告诉我们,磨刀不误砍材工。
    一个人要去看穿眼前的迷雾,进而认清事物的本质,尤其是在周围环境都是迷雾的情况下,去挑战传统,用新的思路去思考问题,却是很难,
    但是对于软工来说,恰恰需要个cheng’be@Rocky

  26. hunxiaobing
    2012年4月11日11:13 | #26

    由产品组负责写需求描述,code和test review,然后code写testcase,给code review,然后test看需求描述,写case后,然后集成code写的case。 test case也用scm管理。
    成本问题,记住一个好的员工的效率其实20倍于普通员工。
    成本问题不是本质问题,本质问题是你能够找到够优秀的人,起码是能同时用code和test思想的,也就是传说中的软件工程学

  27. xum
    2012年4月11日11:13 | #27

    如今的开发,常会有很多框架、工具,但大都是为了构建最终产品服务的,包括设计、实现、构造、实施等,却非常缺少为测试而服务的数据、框架或工具,尤其是单元测试,导致开发人员每做一个项目,都要耗费很多精力,多个项目之间会有很多类似的基础性、重复性劳动,这些事情,对是否能完成产品没有影响,但是对产品质量却息息相关,很多时候,没有人想,更没有人做。
    其实,这也涉及到一个系统架构的问题,好的设计,应该是可扩展的、灵活的、开放的,如何检验呢? 如果能够很容易的实现相应的测试系统,那么不单单测试了实现,也测试了设计。

  28. Jp
    2012年4月11日11:19 | #28

    看了之后只能说招进来的QA水平都太烂了。不过的确有能力做dev的人大多数都不会想去做qa。

  29. Jp
    2012年4月11日11:21 | #29

    我有朋友在amazon总部上班,里面很多QA/SDET都是直接从印度通过中介公司到美国来工作的人。素质很差,水平也很差。

  30. segmenttree
    2012年4月11日11:42 | #30

    作为一个在某搜索引擎公司有过两年测试经验、 两年开发经验的码农,客观的评价一下这个问题。
    对于楼主的观点,绝大部分我是支持的,出发点稍有不同。

    测试团队最大的问题,是和产品、开发脱节,并没有一起扛kpi,这导致测试团队和产品开发团队的目标不同,自然“分道扬镳”。好比几匹马拉车,qa 和rd 的方向有15度的夹角,却硬要用绳子拽在一起,每匹马都很累。
    测试团队有自己的kpi,这大概由两部分组成:一是测试质量,就是不漏测等等,二是一些测试技能的提升,这包括一些测试平台、测试理论、测试流程的改进。
    kpi的第一部分使得qa过于关注bug、bug、bug,因为这就是他们的业绩。但是如何对做成一个产品更有帮助,思考的较少。虽然有的qa团队kpi包含“对产品的影响”这一项,但多数是一句空话,很难操作。
    kpi的第二部分有两个问题,一是经常流于形式,忙于一些假大空的政绩工程,二是一些所谓的改进脱离产品的的发展现状。反过来拿这些“改进”要求研发,造成不必要的消耗。

    测试团队没有和产品、研发一起扛kpi,跟公司的组织架构也有关系。从制定kpi时就没有把qa拉进来, pm做产品、rd实现, 那么qa呢? 仅仅是帮忙测试吗? 很多软件公司都有这样的发展过程,最初没有qa, 产品做大了,研发人力不够,第一次召进来一些纯手工测试的qa,是想以较低的价格完成一些重复劳动。但是这种思维定势却沉淀下来, qa一直是最后一环“帮忙”的,殊不知现在qa已经和rd一样的成本,可以做很多跟rd一样的工作,一起提高效率,而不是互相牵扯。

    从制定kpi开始,就应当是pm、rd、qa坐在一起。 一样的kpi,qa自然会主动去理解dev的设计、dev的代码、dev的逻辑,久而久之并肩作战。

  31. 2012年4月11日11:43 | #31

    认同作者的观点,但有几点疑问,希望指点:

    1、专职的运维,是否必要

    2、横向的问题,如何运作
    如,日志格式、部署路径、OS配置等等,是否需要全公司统一风格?
    是否需要专职人员来订制标准?
    是否需要专职人员来开发自动化工具?

    • 2012年4月11日11:52 | #32

      第一个问题,对于互联网企业,我觉得是需要的,这些人的角色应该是系统管理员,就像DBA或SA一样,做系统管理的,而开发人员一定是要进入日常运维工作里的。第二个问题,应该开发或使用已有的自动化的工具,自动化部署,自动化监控,不需要专职人员。

  32. double
    2012年4月11日11:51 | #33

    “为什么不做开发的QA会比Dev在测试上更专业? 这一点都说不通啊”
    不做开发,不意味着不会做开发。即使QA的开发能力不好,但有这方面经验是很宝贵的,跟运维类似,如果运维的经验丰富,由专人来运维当然比开发自己运维更可靠。说到底,还是想能提高质量同时提高效率。如果QA能在了解开发的基础上,更专注测试,这必然是可以比DEV在测试上更专业的。比如性能测试,开发可能都不知道有哪些平台工具可用,只是跑一票数据查看下处理速度可接受就很容易满足了,而QA肯定会关注更多的点。从我的经验看,Dev总是很理想主义,运行一遍没问题就会对自己的质量充满自信。

  33. 呵呵
    2012年4月11日12:08 | #34

    不要因为一两次痛苦的经历就对整个世界充满怀疑;

    也许你的团队确实不需要测试,但也确实有需要测试的团队;

    既懂得测试技巧(不要认为测试没有任何技巧,唯代码是技术?),又懂得开发设计,还对产品需要门清,这样的人不是没有,但他不会去测试,没准连code都不写,就像您,如果到了您这高度,让你去测试你干吗?

  34. xiamc
    2012年4月11日12:13 | #35

    我觉得你们team取消然后尝试一下,成本收益等等情况,YY无用,空谈误国

  35. xiamc
    2012年4月11日12:33 | #36

    在此之前,我想说明一下我观点里的这个“专职QA”是怎么定义的。
    (1)其是很多公司成立的专门做测试的技术人员,仅测试不开发。
    (2)这些QA对于软件开发技术并不熟悉,甚至不懂。
    其中第一条是定义,第二条是能力描述,问题是为啥不招收对开发技术熟悉的人呢?亚马逊的测试要求其实并不低的。我觉得楼主跟大家分享一下目前的实践,比如对整个项目来说,工作量是否有减少?项目成本是否有变化?

  36. zzz
    2012年4月11日12:44 | #37

    我是QA,同意你说的!hurt but true!
    thinking how to improve。。。。。。。。

  37. xiamc
    2012年4月11日12:46 | #38

    我觉得楼主真的这么做的话,可以分享一下自己的经验,比如项目成本比如时间分配之类的,如果有数字的话是最好的。其实互联网质量保证还是和传统行业有很大不同的,也许没有QA是一种趋势,也许没有QA可以做一种尝试,希望分享给大家。

  38. isrek
    2012年4月11日13:35 | #39

    博主的得出这一观点的逻辑真够烂的:
    首先你所有的逻辑都是建立在一个所谓的“专职QA”上,而这个定义是如此的莫名奇妙:
    1. 其是很多公司成立的专门做测试的技术人员,仅测试不开发。
    2. 这些QA对于软件开发技术并不熟悉,甚至不懂。

    然后你就得出了一个哗众取宠的论点“我们不需要专职的QA”.

    按照你的逻辑我是不是还可以这样推论:
    专职项目经理的定义: 负责项目协调,制定计划…,对具体实现其实不太懂。
    我们上一个项目经理连个C语言的”Hello World都不会写“ -> 我们不需要项目经理
    专职架构师的定义:负责…,但是…不行。
    我们上一个项目的架构师连…都不会 ->我们不需要架构师
    专职开发人员的定义:负责写代码,负责…,但是总体设计和架构能力不行,…不行
    … ->我们不需要开发人员

    退而广之:
    专职公务员的定义: 负责政府机关日常工作,上班时就是喝喝茶看看报纸。 ->世界上不需要公务员。

  39. isrek
    2012年4月11日13:37 | #40

    明白了, 博主的 “专职的” == “糟糕的“

  40. Anson
    2012年4月11日13:47 | #41

    看酷壳的博客也快1年了,非常喜欢。第一次评论,如果错误请指出:

    先阐明一下QA和QC区别:
    ①QA是质量保证,QC是质量控制。
    ②测试只能算QC的一种手段。
    ③QA查找的是过程中的错误,QC查找的是产品中的错误。

    个人感觉除了后端的测试开发和执行,测试人员如果能尽早介入需求规格开发对于项目的帮助更大。比起coding bug,SPEC bug更让人恶心,而如果让开发人员从需求分析,设计,编码,集成,测试,执行从头到尾一条龙的话,至少需求分析很难做到无二义性、完整性和一致性,而且开发人员写的SPEC往往是从逆向实现角度考虑的,这个时候公司需要花钱买个demo客户,体验一把正向的需求是否满足要求,这个demo客户应该就是专职测试团队。

  41. test
    2012年4月11日14:02 | #42

    从做事的角度我很赞同你的想法, 但是从一个公司政治的角度, 如果老板手下人很精干, 那么老板就无法做上高位, 一件真事, 一个小公司被大公司收购了,换了一个大公司来的CTO, 一开始只有20多个开发, 一切都很顺畅, 但是CTO觉得需要有层级, 他就不考虑做事角度, 拼命扩招, 因为CTO才管20多人对他来说感觉不合理, 而且公司财务上也没有压力, 最后变成一团乱麻, 客户满意度很低, who care, 最终CTO才像个CTO, 技术部门一下就有了200多人。

  42. 土豆
    2012年4月11日14:12 | #43

    上边说了~~测试是一个捡漏补缺的工作,所以后来推出代码review,其实就是开发之间相互测试,但是很悲剧啊,我都不知道你干什么,怎么测,光看代码有什么用。

  43. malasyan
    2012年4月11日14:19 | #44

    你所经历的测试组,被你一描述,听起来就像个弱智,完全就是会上网的煮饭大妈.这能叫测试人员么…

  44. 2012年4月11日14:42 | #45

    同意【程式设计师自我测试中往往会不自觉的绕过自己所埋下的陷阱,但一般使用者却会跌下去,这时候纯洁如白纸的QA就是要把这类问题抓出】
    而且,做开发的的确容易懒得深入测试。也许结对编程的方式能做好,但是可能比专职测试人员还要贵了。
    另外,QA不懂开发是指没参与产品的开发,不一定就是不会在自己测试领域进行自动化、提高效率的编程

  45. matrix
    2012年4月11日14:51 | #46

    test :
    从做事的角度我很赞同你的想法, 但是从一个公司政治的角度, 如果老板手下人很精干, 那么老板就无法做上高位, 一件真事, 一个小公司被大公司收购了,换了一个大公司来的CTO, 一开始只有20多个开发, 一切都很顺畅, 但是CTO觉得需要有层级, 他就不考虑做事角度, 拼命扩招, 因为CTO才管20多人对他来说感觉不合理, 而且公司财务上也没有压力, 最后变成一团乱麻, 客户满意度很低, who care, 最终CTO才像个CTO, 技术部门一下就有了200多人。

    这是胡扯

  46. ldy
    2012年4月11日14:58 | #47

    应该充分了解专业的测试团队后再下结论。跟据你所描述的测试人员的工作方式和技能,只能说明你们内部出了问题,建立了一个垃圾的测试团队。

  47. matrix
    2012年4月11日15:06 | #48

    有人从成本角度分析,有的人从技术角度分析,这本身就说明了软件项目多种多样,不同的项目必然需要不同的工程方法。就连被批判最多的CMM也一直强调要根据实际项目情况裁减。楼主的很多意见有道理,但太理想化,太绝对。夸大了开发技术的作用 ,对有的项目来讲,例如一些外包,需要的就是楼主所说的码农和严格的流程就够了,这点阿三最有发言权。楼主所谓的通吃的开发工程师在总数中只是太小的部分,我也不认为这是开发工程师的发展趋势。

  48. metasearch
    2012年4月11日16:12 | #49

    我十分同意你的看法. 大部分QA的确不懂开发, 业务,不能真正发现postive bug。所以只能对着需求文档,界面上提出一些无关紧要的bug,牵扯了开发人员大部分精力。而且可能自己也觉得这些bug没成绩,进而在扯皮和推委上下功夫,到最后把开发人员搞得很火,很疲惫,很无奈,没有时间和精力去做更好的开发。当然这只是我们在做事的角度去讨论这些问题,但是很多公司就是要扯皮,要搞的,不搞显得你不重要,上不去。

  49. gooner
    2012年4月11日16:25 | #50

    看了半天忘了看定义,不需要“专职的QA”。
    不需要QA只是一个伪命题。不放到具体的产品、公司、规模来谈太理想了。

  50. invalid
    2012年4月11日17:11 | #51

    我是这么看的: 程序员就一包工头,QA是公司搞质检的。

    换言之,QA根本就不是来“帮dev干活”的;而是代表公司来验货的。

    从这个角度看,QA或者测试团队根本就不该把找到的bug提交给dev,只要告诉他们“你们做的东西质量不行,公司没法接受”就够了。

    从这个角度看,说不需要QA是可笑的——嗯,老板,偶们团队的软件可以免检吗?
    免检?你先打出这个信誉再说。

    ——————————————————————
    很多人可能会疑惑:没有测试团队,软件质量怎么保证?连个错误报告都没有,dev怎么修复bug?

    这点我同意云风的观点:好软件不是测出来的。

    换言之,好软件是一开始就没什么bug的——也就是“明显没有错误的”。

    反之,那种靠测试报告补窟窿补出来的东西,多数是“没有明显错误的”。

    这两者的质量差异可就大了。

    ————————————
    事实上,我认为那些没有测试报告甚至测试报告稍微含糊一点都没法定位错误的,是因为被惯坏了,“没有明显错误”的东西写太多了。

    而自测bug就会逼开发人员放弃那些炫耀性的东西——比如放弃“设计模式驱动”——真正面向需求,写“明显没有错误的”程序。

评论分页
1 2 3 4 6994
  1. 2012年4月11日09:02 | #1
  2. 2012年4月12日10:40 | #2
  3. 2012年4月17日21:43 | #3
  4. 2012年8月12日22:43 | #4
  5. 2012年11月20日08:22 | #5
  6. 2012年11月20日09:29 | #6
  7. 2012年11月20日11:04 | #7
  8. 2012年11月21日00:34 | #8
  9. 2012年11月21日09:32 | #9
  10. 2012年12月30日00:56 | #10
  11. 2013年3月11日09:21 | #11
  12. 2013年3月12日14:13 | #12
  13. 2013年4月10日15:36 | #13
  14. 2013年4月12日14:45 | #14
  15. 2013年4月20日09:50 | #15
  16. 2013年5月1日15:28 | #16
  17. 2013年6月4日02:37 | #17
  18. 2013年7月26日17:06 | #18
  19. 2013年8月31日21:46 | #19
  20. 2013年9月1日15:54 | #20
  21. 2013年10月20日07:55 | #21
  22. 2013年10月29日15:40 | #22
  23. 2013年11月10日16:16 | #23
  24. 2013年11月19日22:39 | #24
  25. 2014年1月22日13:57 | #25
  26. 2014年2月24日09:01 | #26
  27. 2014年3月7日03:17 | #27
  28. 2014年6月9日09:06 | #28
  29. 2014年6月12日12:44 | #29
  30. 2014年6月30日17:23 | #30
  31. 2014年7月1日13:26 | #31