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

我们需要专职的QA吗?

2012年4月11日 发表评论 阅读评论 35,333 人阅读    

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

在此之前,我想说明一下我观点里的这个“专职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. aochant
    2012年11月20日11:03 | #1

    只能说你们公司的qa水平不行, 我们公司的qa水平比初级开发人员要高。

  2. asd
    2012年11月20日19:28 | #2

    有一定道理,我原来和现在估计好多国内小软件企业都没有测试人员,都是dev随便测测,流程制定,test Case design等都很差

  3. xiaoyu
    2012年11月21日11:06 | #3

    我们团队就有专职的qa,我的感觉是给dev增加的累远远大于其带来的好处, 真正的问题在都是开发本身测出来的

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

    我认真看了你的东西,也希望你认真思考一下下面这些问题
    1. 之前你公司的QA文档需要DEV审核,不负责发布、打包流程和实际场景的部署,写个CASE写出.“Expected Result:Make sure every thing is fine” ,这些是缘于什么,是公司的不重视,还是DEV的过于自信,亦或只是QA Manager的极其不专业?
    2. 我本身是一个软件DEV出身的QA,做过SDET,经历过国内三家大公司和一家跨国企业,现在也是Dricter兼做游戏制作人,我对DEV对自己代码错误的态度一清二楚。喜欢开发新东西新功能,对旧代码的问题不屑一顾,自以为是的同时又能力有限是国内DEV的通病,在这点上台湾或者欧美的DEV的确要好很多
    3. DEV懂的只有调试,国内有几个DEV会自己写白盒Test Case的?更不要说有效覆盖和需求跟踪了。
    4. 如你所说,把所有QA全部变成DEV,又有几个人愿意只去测试别人的东西而不开发新功能?交叉测试别人的东西,又能做到什么效果?DEV部门的代码评审和规范国内有几家公司能踏踏实实去做的又做好的?
    5. 如果DEV做测试,怎么保证分支版本,怎么做配置管理和版本资源回溯,代码Test Case应该做成什么样子,外观表现跟需求的差异应该怎么控制,性能指标应该怎么验证,请问有几个DEV知道呢?请注意,我可不只是说代码,包括配置文档,美术资源,音效资源在内的所有部分。就我所知,很多DEV连核心代码怎么做SVN分库都不知道,更不要说分支合并了。
    6. 我很感兴趣你的开发团队是怎么能够被QA搞得一团乱的,既然如你所说所有东西都是DEV在负责,那么项目进度也应该是,既然开发可以内部测试,那么为什么当时又没有做好自己发布,这与QA又有什么关系呢?我所经历的所有公司,QA是加班最多的,特别是在版本发布的时候,如果没有QA,DEV不可能下班一个多小时就能回家,一早晨来就知道自己有什么东西没有做好,应该怎么改。
    7. ”这个bug再不fix“,如果有BUG不fix,要么是技术问题,要么是人懒的问题,技术问题总能解决,解决不了的小问题早应该关掉了,人懒问题就没办法搞了,就一辈子懒下去吧
    8. ”无论怎么样,你总是要上生产线做真正测试的。“ 你和你的公司敢这样做么?呵,我只能说你们公司的产品用户基数和净利润真是大到了能够浪费的地步

  5. 2012年12月21日20:15 | #5

    问题尖锐而深刻!

  6. QA
    2013年2月26日23:45 | #6

    根本原因是由于你们的QA水平造成对QA工程师的工作和职责误解, 我认为QA在软件开发过程中是必须的,特别是针对商业软件或者性能要求高的金融系统。 事实上很多高级QA都是从开发转过来的,这些QA不但懂测试,而且懂开发和技术架构,他们从系统架构和需求分析就开始参与,一直是项目组的重要成员。

  7. DiegoK
    2013年4月9日02:34 | #7

    这里看到你的痛点很明显,因为QA的不专业,让你浪费时间 精力。但实际上,更应该讨论的是 什么是QA, QA的标准是什么,QA的角色是什么。
    QA不应该不懂开发技能(本地化测试可能需要开发技能少一点),因为不懂开发技能意味着不能很好的独立发现问题以及发现深层次的问题,而且很难做正确的回归测试
    QA不应该跟开发没有任何交流,好的QA 应该在需求时期就已经参与,试图更早的找出设计中的问题,避免后续发现导致更大的问题,QA跟开发应该是合作的关系

  8. 路过的测试人员
    2013年4月9日23:38 | #8

    额……QA不是质量保证么,怎么变成测试人员了……难道我们公司特别奇葩??

    首先申明一下共识:
    1.开发和测试分工确实是会导致交流成本之类的问题产生。
    2.完全不懂开发的测试人员没用(最起码要会写测试用例,纯执行用例的那其实就跟开发只会写代码没什么两样,都是废的)
    3.测试人员的考核机制确实很不好界定,我们这边用缺陷密度之类杂七杂八的数值来考核,但是我觉得有待商榷。

    说开发不需要做测试是不对的,开发在交付给测试之前是要保证程序基本业务能跑的,不能的话直接把版本打回去要他们重做。

    说开发要懂测试,确实,懂的话更好,那么开发是不是还要懂产品,懂经济学,懂XXXX(这类东西其实都有人在讨论)。懂得越多能量越大。但是我觉得不能说因为看到能量大带来的好处,所以我就觉得这是必须的。

    我觉得测试是必要的,原因很简单,说白了就是测试比开发在测试方面专业。就像开发有设计模式(当然这个东西是否要固定成一个模式有待商榷,但总归还是有的),测试也有测试的一套方法论和经验论的。而且测试也不仅仅是功能测试,还有性能测试,稳定性测试,安全性测试,易用性测试(我觉得这一点是开发和测试经常吵架的一点,而且这一点我觉得也是开发最不可能兼顾的一点,如果能兼顾的话我觉得你可以再开一个标题“我们需要专职的产品经理吗?”,当然测试也只是从用户角度来看产品,并不等同于用户)。

    说说自动化测试吧,因为这半年做这个做的想把开发全杀了。首先,自动化测试需要很高的成本,而且当被测端改变时,往往波动很大。说什么自动化测试代替手工测试是有前提的,产品最起码要进入相对稳定阶段。我不觉得开发能把自动化测试给兼顾了,我这半年写的代码量(不含测试用例,就测试框架、桩函数等等)可以顶得上我们开发的产品一个中等程度模块的代码量了。确实,转版本的时候因为我们完全没碰过源码,不清楚里面的东西,弄得每次转版本时都是整的焦头烂额的,很麻烦。
    但是我们一套环境要用上4,5种语言(因为测试端,被测端,还有模拟用户场景用的那些机器),需要3~6台计算机。然后这种环境有10套左右。你叫开发去管理?这你还让人专注于解决问题提升质量不。搭一套环境确实程序跑起来本身需要开发的协助,但是反过来,搭一套模拟用户实际使用的场景这个是需要测试给开发帮助才搭的起来的。期间还有什么剪网线呀,装单板呀,换后插板呀,这些杂七杂八的事情都由开发去做么?这还没算上那成千上万行的测试用例。(写这堆用例又要消耗多长时间呢?)
    这堆事情开发确实可以做,但是为何要开发兼顾这堆东西呢?兼顾了这堆东西还能关注于产品本身么?反过来说,如果开发有一部分是专门做这事的,那么为什么不能独立出来作为测试呢?(类似的像安全性测试的时候,都是专人来测,我干嘛非要把人划分到开发里?)

    遥想当年有人跟我说:“干测试很爽的,开发天天加班,测试准时上下班,还能对开发指手划脚。”丫的,我好久没有准时下过班了……我也没有对开发指手划脚过,每次都要催呀催,你倒是快点定位呀,我还有其他用例要跑呀!!

    想说的其实还有很多,但是我现在还是快点洗洗睡了……明天不知道又要加班到几点……

  9. Tomorrow
    2013年4月11日09:04 | #9

    我们不需要,但是领导需要哎。

  10. 郭儿
    2013年5月3日16:55 | #10

    我们公司的质量部门划分更细些,有测试开发,专项测试,系统测试,QA。其中QA主要做研发流程,规范制定的工作。
    个人认为这种类型的QA存在的必要性不是很大。

    作者举的本公司测试的例子感觉有些极端了。像这种设计用例不仔细,不看设计文档,不负责的人确实没什么存在的必要性。

    我认同“开发要懂测试,测试要懂开发”这个观点。
    开发懂测试:
    至少保证提交测试的内容关键路径是通的,不至于反复打回重来。另外基本的单元测试还是要开发进行的。
    测试懂开发:
    个人认为测试确实需要一定的开发能力或者说技术理解力,自助定位分析问题。如果能把问题原因定位到代码行级别,相信也能提升自身的认可。

  11. 坐忘天下
    2013年5月9日14:56 | #11

    这个问题我觉得有个原型可以参照考虑。

    哲学王治国应该是最为完美与理想,但是人类文明实践显示,从来没有这样的完美的人(人治)出现,最终退而求其次,选择了制度予以约束与监督。比如我们中国人比较称道的唐代,三省制(监督制衡审核)、当今世界上浩浩荡荡的权力制衡。于是,我想既然千古以来没有哲学王在国家管理工程领域出现,在软件领域也不太可能吧?

    首先,社会分工一定是事物发展到一定规模与高级程度之后的需要,早期肯定没有独立的测试,那么软件质量乃由开发一体负责,他们曾经是开发测试的双重角色,但是我想历史上如果做的很成功,一定不会有后来测试工作的分离与测试工程师的出现;

    其次,任何学理证明起来较为工整,但是实践操作起来可能千差万别,兰州拉面的基本制作流程与原理应该一样,但是你会发现一家一个味道。开发与测试是逐渐确立起来的一个基本制度,双方之间的矛盾(文中作者已经备述)其实从另一个方面反映了测试独立的重要性,如果没有测试与开发这种矛盾存在,又有那个开发领导可以清晰洞察项目本身的问题并准确无误的去推动质量的逐步提升呢?如果只是站在开发角度,那肯定是极度不爽的,如果站在工程管理的角度,你会发现这也是一个退而求其次的优秀方法。现在的抱怨,犹如公安机关抱怨检察院只会吹毛求疵,对他们的调查结果要求补充调查,其实呢?检察院可能也是一堆抱怨,如果不是他们进行独立审查,而只是座位公安机关的附庸,不知又有多少公诉失败呢?测试人员类此,也有回复佐证。

    最后,至于是否需要由专职的QA,只能要交给实践去处理,我绝不相信测试人员的完美,同理也不相信同为人类的开发人员的完美,如果真有工程师直接开发测试出来质量上乘的软件,QA取消绝对无人反对。而楼主如果有这样的方法能打造如此豪华的团队,那也一定能开山立派,一举解决软件危机的根本问题了。

    关于QA的其实也不是一言两语能够说清,仅就楼主所虑提点个人拙见。

    楼主文章十分欣赏,正在逐一阅读,时有共鸣,不过关于此文,给我的感觉是:楼主的技术(与追求)强劲,当然也自有技术优秀者的普遍成见。

  12. hu
    2013年5月10日10:53 | #12

    不敢苟同,体现个人能力的想法,跟十年前缺少软件工程理论的指导做开发一样。QA是一个公司成熟之后所必须的,另外一个人精力真的是很有限的,又是开发又是测试,没那么多时间搞啊,也没那么多精力去学习专业的软件测试知识、自动化测试知识,这种开发、测试之间的角色转换本身就会浪费很多时间。

    要说测试,那肯定是要懂开发的,其实开发和测试的重要程度是一样的,只是开发偏重于开发而已,测试偏重于测试而已,也就是你中有我,我中有你,侧重点不同,然后达到保证整个项目的质量平衡。

    感觉作者处于人生的第二个阶段——-看山不是山的阶段,太过一家之言,或许是太多不懂开发的QA损失了QA的信誉吧,或许作者也被误导了。

  13. Ryan
    2013年6月4日21:32 | #13

    即使也有这样的原因:

    不怕狼一样的对手,就怕猪一样的队友。

  14. 2013年8月5日13:17 | #14

    网友们对这个问题已经讨论的很充分了,总结这个问题:一个团队是否需要QA?需要什么的QA? 答案就是 depends。
    翻译过来就是 “视情况而定”。考虑到所有的公司想得到结果肯定都是一样的:在既定成本的条件下,产出高质量的产品。所以只要能达到这个目标 随便怎么折腾都可以。这里没有技术上的,更多的是管理和资源分配甚至是人才使用上的问题。

  15. 2013年8月5日13:18 | #15

    网友们对这个问题已经讨论的很充分了, 总结这个问题:一个团队是否需要QA?需要什么的QA? 答案就是 depends。
    翻译过来就是 “视情况而定”。考虑到所有的公司想得到结果肯定都是一样的:在既定成本的条件下,产出高质量的产品。所以只要能达到这个目标 随便怎么折腾都可以。这里没有技术上的,更多的是管理和资源分配甚至是人才使用上的问题。

  16. 大老虎吃小白菜
    2013年8月8日20:13 | #16

    我赞同你的观点

  17. 听雨稚子
    2013年8月11日22:06 | #17

    我觉得说的很好, 确实应该是谁开发谁测试,专职的测试很多时候是浪费资源,不过很所公司借此调节男女比例,在测试部门多招一些女生,比如IBM。

  18. wtgamaa
    2013年8月11日23:06 | #18

    我几乎是看了标题就想回复作者了,现在我几乎每天都在受着某些测试导致来的痛苦。甚至要忍受测试人员的态度,为什么他们会觉得出了bug是给他们增加工作量,觉得程序员做的东西不完善就拿给了他们测试?
    其实很多矛盾的增加就在于文章中说的,他们根本没有理解程序员的工作。
    互相增加了累赘的感觉,真的需要考虑一下什么样的环境才是适合加入专职QA部门的。

  19. 2013年8月12日01:11 | #19

    先回答标题的问题:需要!
    看完发现po主是在说测试,在很多外企倒是会把测试说成是QA,这个就不纠结了。分工越来越明确是个大方向,随着公司或者项目的壮大结果肯定是会需要专门的测试的。
    首先我是做测试的,一个专业的软件生命周期,测试人员应该是全程参与的,具体的话可以画成一个双V模型(搜了一个,基本大同小异http://wk.baidu.com/view/e15c3716650e52ea55189820#image/fullimageview/1376238850292),一个专业的测试组也是应该根据具体的功能/接口来确定黑盒还是灰盒的测试方法。所以我们需要写用例,可能还需要去重新设计回归测试的的自动化脚本,我相信这些东西如果让一个"兼职"的人来做肯定做不好。当然,po主所谓的交叉测试,我不敢说没有效果,但做完这些测试还要修bug的话不觉得这份工作太苦逼了么!
    我非常同意po主提出的"工程师思想",开发自己也应该有测试的思想,别总是一副码农的傻样。当然测试和开发绝对是同一战线的,我们是在协同完成一样东西,并不是所谓的死对头。
    po主遇到的不专业的测试暂且不谈,要测试去理解开发的思维没有任何必要!如果需求实现的不对有什么好扯皮的,有争议的大可请原始需求人员来判断。不过测试需要理解概要设计和详细设计,这在上面的双V模型里有说。加班问题上也是那句话,分工不一样,你们可要知道相同工作年限的开发基本上可是比测试工资要高的哦。
    我也希望各位开发对自己不了解的领域别轻易下结论,只会显示出自己的无知。

  20. melin
    2013年8月12日09:41 | #20

    公司项目经理最为头疼的是面对QA,每周每月需要定期的交付一些没有太用的文档。QA不太关心开发过程,更不会关系系统设计。目前大部分的QA只比较适合做web功能测试,这点要比开发人员仔细。但是遇到后端功能性测试完全无力。只能开发人员自己去做测试,可以协助打下手。QA本就是一些不想做开发的女孩子居多,别想让他们去学习开发,提升测试。不太现实。QA需要有,但不能太认真,

  21. 花间一壶酒
    2013年8月16日10:41 | #21

    写得太TM好了.深表赞同.

  22. Hacker D
    2013年8月18日09:07 | #22

    Stupid Pig。如果你说在普通的Web产品中不需要QA,还可能。在一些业务关键的系统中(银行、电商、航天设备)不设置QA,靠谱么?你自己提交的代码难道就没被QA测出过问题么?推动QA人员的质量本身的动机是好的,但写这么大一篇文章来说不需要专职的QA,真是扯淡。第一,没找好出发的基点(你做的是业务系统,还是简单的一个社交网络产品);第二,现实环境是,大部分开发人员自己连需求都没弄明白,更别说测自己的产品了。

  23. IBM
    2013年8月22日12:53 | #23

    只能说明: 你上个公司的QA水平太差了! 我在XXX公司的时候,QA的工资好多都比RD的高!

  24. 2013年8月28日00:19 | #24

    @坐忘天下
    精彩回复。行文工整流畅,观点中肯到位。求@坐忘天下blog地址~定要学习学习~

    另:“楼主文章十分欣赏,正在逐一阅读”,同感。前两天无意进入此站,现正欣赏中。

  25. 2013年9月3日12:38 | #25

    你提到了qa责任,很好,我在多个公司多个项目组都提出过,如果产品到了用户手里出问题,qa全责,因为qa是把关的人,qa可以拒绝为产品质量背书,或者把risk都写进report,并且必须标注bug作为证据,让pm决定是否发布,但是一旦出现report以外的问题,qa全责
    所有工程的质量都不是靠测试测出来的,都是一开始就考虑进去的。你会等到房子盖好才去凿墙看它是不是结实吗?从来不会有建筑学院这么教书,也不会有建造者这样干活,而是从画图纸的时候就在考虑质量了,各种监理各种指标地基挖多深砂浆比例多少都是质量,所有的工程都这么做,怎么到了软件就变了?软件行业有什么特殊吗?除了从业人员相对行业的复杂度和危害来讲素质最低以外
    最后:我是qa

  26. 2013年9月3日12:41 | #26

    @路过的测试人员
    您这个说法有些道理,qa不是找bug的,而是判断产品质量是否在某个可接受范围内,以及如何让产品质量保证在这个范围内的人

  27. yuer
    2013年9月13日16:40 | #27

    @reti
    哥们,你说除了我的心声哇。。。。

  28. 未央哥
    2013年10月20日10:02 | #28

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

  29. AmyOrchid
    2013年11月14日13:10 | #29

    赞同

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

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

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

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

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

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

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

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

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

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

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

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

评论分页
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

Desktop Version | Switch To Mobile Version