我们需要专职的QA吗?

我们需要专职的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 ,请勿用于任何商业用途)

好烂啊有点差凑合看看还不错很精彩 (60 人打了分,平均分: 4.23 )
Loading...

我们需要专职的QA吗?》的相关评论

  1. 值得思考 不过个人认为qa的存在是为了解决女性就业 属于社会学范畴

  2. 看来有很多IT公司都是这个样子,我所在的公司也是这样,有专门的QA部门,我是做开发的,马上要入职一年时间了,这段时间里做开发真的很郁闷感觉,对博主所提到的问题深有感触啊(虽然入职还不到一年。。。。)

  3. 文章太长,粗略看了一下,整体不做评论,对于支持文章观点的一个论据有不同意见:“在我现在的公司,程序员要干几乎有的事,从需求分析,设计,编码,集成,测试,部署,运维,OnCall,从头到尾”。难道那些程序员都是起码好几年工作经验的?也太轻视各个环节的专业性了吧?程序员是可以每个环节都去做,然而要每个环节都做好,实在不是一件简单的事,这样说起来,岂不是系统分析师、架构师什么的职位通通不要了,都程序员去做吧。程序员每个都得是通才而且各个环节都不能差了,微软、google这样的公司也不可能召集这样的程序员队伍。

  4. 针对楼主的update,我也再补充一点:QA并不能保证质量,它只能制定出一系列的流程和标准来试图保证质量,但真正能够保证质量、提高软件质量的人只有开发人员自己。另外,测试更不能保证质量,测试其实也不能控制质量,代码在开发手里,当然只能由开发来控制质量。测试的真正作用是:衡量软件的质量(measure the quality of the software)。

    另外,我看了很多人的评论,忽然间我倒宁愿同意楼主的这种观点了:还是开发人员自己吃自己的狗屎吧,测试人员并不是给你们擦P股收拾烂摊子的。质量最终只能靠大家一起来努力。

  5. 不完全同意,但是还是顶一下!今年一直都存在着弱化QA角色的声音,广大测试同胞该重视了,不傲忽略自身能力的提高!!!!!

  6. @kokobar
    能的,就看你去不去做,不要把自己的定位限制住,难道公司提拔你做经理的时候,你会说:”我是专业的开发人员,不要让我去做经理?”微软的NT内核,windows最早的代码,谷歌的最初架构,都是那些什么都去做的程序员做起来的

  7. QA人员的责任和权力明确了没?
    他们应该是质量的最终负责者,没有他们通过,产品不能发布,通过之后,再有问题,打屁股就该是他们。
    你首先要保证测试人员的质量,为贪便宜招一堆廉价的测试人员,还指望人家有什么技能了,这种水平的人员,当然测试环境要找开发人员来配置了。要让开发人员吃狗屎也简单,人家测试出一个错误,你奖金扣100,看他还敢不敢随便瞎写写。
    全才,需求,设计,开发,编码,测试,什么都能做的,你指望花多少钱来请人家呢?
    我觉得下次可以写一篇“我们应该怎么克扣开发中的成本”

  8. 据说从前华为经常把开发和售后人员互换,让开发也体会售后的痛苦,售后体会开发的不易。
    可以把测试调来做开发,开发调去做测试。一个人具备两种能力,和同时做两种事,差别很大的。

  9. 基本上Dev和QA一个竞争的关系,是一种管理方式或产品质量保证的需要,就好比老美崇尚的竞争,同样一件事情至少要保证两个团队去做,但是开发一个软件来说弄2个开发团队太浪费资源,因此需要独立的测试团队专门找开发的茬, 而测试的工作业绩也是基于找出茬的数量和质量,如果单有开发,那么人天生的惰性会让开发在功能性能上留下纰漏

  10. 不同公司有不同的风格吧
    我们做工业自动化的 专职的QA不管具体的技术 只是管文档
    也就是说测试文档需要开发工程师 测试工程师 QA和项目manager一起敲定 审阅
    完了以后 开发的软硬件工程师也负责和测试工程师做交接handover
    测试工程师遇到问题直接跟开发工程师反馈 同时把问题归档 开放工程师解决bug的时候要核对文档 和测试工程师还有QA一起一个一个注销
    当然了 资本家不愿意浪费利润 所以大部分时候开发和测试是一拨人 所以很多时候导致测试自己的系统容易不仔细 而且QA和主管也不会注意那么多细节
    总之再完美的计划也需要人来实施 很多时候都不是计划/系统的问题 而是执行/预算/项目进度的问题

  11. 我也来拍两砖,不知道会不会有人同意。

    整体上我是同意开发兼任QA的。不能光做完一件事情就完事儿,一个有责任心的人,一个合格的工程师应该是把事情做好。开发一般都会比较看重设计,但其实质量也是我们做的东西的一部分。
    但是从保证质量的角度讲,我还是支持要有第三方测试的。无论这个第三方测试是来自自己的QA,还是用户。这个主要是为了预防两种情况,一种是能力不济,确实没发现有些问题,另一种就是避免不识庐山真面目,只缘身在此山中的问题。
    当然,你可以将自己的团队如何如何的强大。但我想任何主观的因素都不应该替代制度。我们可以根据事情的具体情况调整制度的范围,但不能取代。这方面我想到一个例子,就是一党执政。我们经常听到新闻上说档的先进性,可以通过自觉杜绝腐败。结果呢?

    对于需求和维护能否都让开发兼任,我本人持质疑态度。我认为还是团队大小的问题。本质上人类分工就是因为两点原因,一点是精力不够,一个人做不了所有的事情。另一点是专业分工可以让你更专业。所以如果团队较小,开发兼任需求和维护我是支持的,甚至可以兼任售前,售后,客服,非常有利于开发人员理解自己的用户和产品,这在绝大多数软件作坊中已经就这么做了,不算创新。但如果团队再大点呢?

    另外还有个问题,公司如果有很多这么小的team,他们各自做各自的产品,他们自己内部是没问题了,他们之间如果合作不也有沟通问题吗?会不会也有责任不明确,互相推诿的情况?一个大的公司如何管理这些小的团队?

  12. “在我现在的公司,程序员要干几乎有的事,从需求分析,设计,编码,集成,测试,部署,运维,OnCall,从头到尾”。
    ——————–
    很不赞成这种做法。这种做法 对dev的素质要求太高,现代分工应该像工厂的流水线一样的,编码的人员专门编码,设计的专门设计,这样可以让人员对各自的部分有足够的操作时间并且成为相对高效的熟练工人。
    如果所有人都必须要从事 需求 设计 编码 集成 。。 等等等 则有如下问题:
    1、各人处于相对独立且封闭的任务或者模块中,时间久了各模块间的磨合会有问题。一旦发生人员流程,补充成本高昂!
    2、要改善第1点问题,必然需要考虑各组成员交叉工作,这就导致人员工作内容,性质不确定,难以呈现熟练工人效应,效率会下降。长远来看,抽象度会降低,而且频繁的更换工作模块也可能导致质量下降问题。工作、沟通磨合也将会是个问题。 这些都是成本。

    如果一定要dev自己去测试自己所写的代码,则必须要保证有足够的时间去开发,甚至都找不到一个好的理由去压缩时间赶进度。一般来说在一整个工作流程当中,“单个的人” 这个因素其实是最不可靠的,如果项目进程进展到必须要通过加班来解决的时候 “单个的人”这个因素会变得更不稳定。 所以要引入 人手 互相补充、竞争。

    最后 我一直认为qa 要比开发精贵,廉价人员只能从单纯的功能测试做起,一个合格的qa 如果搞不起环境 那就要去学,
    原则上,我是说原则上,我不希望有dev动手帮助qa解决这些问题,dev部分应该要出具足够详细的安装、部署文档 而不是抽调足够的人手去帮助qa搭环境!QA只对功能质量和性能质量负责,没必要对所谓的代码质量负责,这个应该是开发小组长或者是架构设计师去把握的问题!

    但是,我不反对组织dev去有限测试或者试用自己的产品。事实上自己做的东西自己也应该要去用一下。特别是PM。这有点像做架构 框架的人 也要有限度的涉足开发一样。

  13. 博主写了不少好文章,受教了。
    就这篇而言,
    好像你找的是全能的最优秀的开发,被你挑剩下的开发干嘛?回家种田嘛?感觉这个文章完全你在发泄抱怨。

    我的工作经历告诉我:
    测试人员是必须的,而且有一部分测试应该在设计文档进行的时候跟进来,还要部分参与到设计中来。

  14. 我边上的测试团队的leader甚至在指导开发应该怎么搭框架,用什么workaround避免什么什么问题等等等。

  15. 只能说你们公司的测试太烂了,别把你们的个例延伸到全部。我们经历的公司,测试都是很不错的。他们的有的要求甚至比开发还高。另外需求的问题是你们公司的问题,和QA或者Dev的沟通有关系。
    另外别说测试不专业,不细心,不认真不加班,记得我们QA有时候为了一个Asp.Net内存泄漏的问题,用WinDbg追踪了好几天,别以为这些是你们开发能做得出来的。没有专业,就想有品质,你想都别想。

  16. 问个问题? Linux Kernel有专职的QA么? 有?什么样的QA? 没有?那么是如何保证质量的? Linux Kernel的方式个人认为就是目前的最佳实践。

  17. 我觉得楼主没把QC和QA分清楚,也许你们的QA,做的是QC和QA的事情综合起来的事情,简单来说吧,你上述所说的大多数事情其实QC做的,QC也就是质量过程控制,其实也就是所说的测试人员,QA即品质保证人员,有些公司会把QA和QC分开,即QC负责过程中的测试工作中,也就是测试计划,测试设计,测试执行(包括测试环境的搭建),提交bug,定位bug,回归bug的职能,QA做什么呢?QA即负责开发与测试之间工作的协调以及整体计划执行的把控,以及在过程中,通过设置检查点等方式来检查开发以及测试的工作是否按相关节点完成,说简单点也是计划监督把控,主要起到对项目的监督作用。
    看了你说的,我觉得你所在公司的开发和测试的矛盾可能较为严重,为什么随着软件技术的发展,软件从业人员的工作越来越细分化呢?照你说的话,那么你说的方式又感觉回到了作坊模式的软件开发模式,开发自己写的程序自己测,你认为能保证质量吗?就比如你做一件事情,完成后,那么你会认为你做的不对吗?所以我觉得也不能太过偏面的看待这个问题,其实一个完整的测试阶段是会在项目探研阶段就会介入,一直到产品发布后,用户反馈问题的重现都还不能算完全的结束。也许是你所在公司的原因,我所在的公司,开发加班的时候,测试必然在,因为要验证开发所开发,修改的问题,另一方面来说,我觉得你所在公司的测试流程不是规范化的,同时部门之间的协调也存在一定的问题,感觉你们像敌对部门样的,其实很简单,都是为所开发的产品负责,大家的基本目的是一致的。
    还有你说的测试用例冗余的问题,有了测试能发现所有bug吗?必然不能,测试用例必然会有一定的冗余,但是在测试过程中,我觉得测试人员应该根据产品执行的情况,对测试用例进行维护和优化,更加贴近于产品实实在在的功能点。
    测试人员更加贴近于用户,能够通过用户的角度去体验和测试整个产品。
    总结一下:
    1.QA和QC在一个软件项目中的重要性不亚于开发人员,像微软等大公司的测试与开发比例至少在1:1以上。
    2.贵公司的测试工作流程规范以及相关职责划分不够细化,导致较为混乱,一般一个完整的测试部门,会有黑盒测试,白盒测试,有时也会有灰盒测试,根据不同项目配置不同的测试资源。
    3.适时调节开发和测试之间的矛盾,在我们公司,开发和测试都是很好的朋友,工作中,开发人员也认可我们的价值,因为确实保证了产品的质量。
    先说在这吧,其实还有很多没说完····

    1. 测试都能还要细分成QA和QC,我真是服了,这样的团队一定没什么创造力,就是劳动密集型生产线上的一个工人罢了。另外,我想提醒一些回复的朋友,你们说的管流程的QA其实叫SQA。

  18. 你既然说了是团队,那么团队中肯定还有不同角色的扮演者,如产品经理,他是主导产品定位,产品创新,产品的实现什么样功能需求等与产品相关的事情,只有不同的人员的共同协助才能完成整个产品,也不排除像很多开发人员个人创造出一个很perfect的产品。像产品的体验提升以及产品的完善,我觉得需要有个迭代的过程,在不断的迭代过程中,不断收集团队内部,真实用户,以及市场调研分析等数据,然后不断进行提升。像开发和测试这种类似的矛盾,在我们公司其实是研发部门与市场部门的矛盾,因为研发部门通过内部质量评估以及体验,需求验证认为符合发布要求,但由于我们公司的产品的发布,需要不同部门的审核才能发布,很多次因为市场部门认为我们所做的产品无论界面和功能需求未达到真正满足用户体验和需求的时候,都没通过,我们也有怨言,因为这些在事先也有过沟通和确认,但最终还是要求修改,同时我们也认为,就他们那样的销售,我们不要他们一样的也可以我们研发这边去销售。其实换个角度想,一个公司的员工,大家都是为了产品能够更好,才产生这些矛盾,我们完全可以化解这些矛盾。
    另外,其实你所说的开发去测试,有点理想化了,开发去做单元,自动化等我觉得没有问题,但是要开发去做验证需求实现,每个功能点的不同操作,以及每个功能的异常操作等是需要耗费时间的,那么这样的投入和产出比是否有意义值得去衡量。
    同时,在软件项目不同的开发阶段,bug的修复成本也是递增的,如果在发布后,发现某个bug影响大量用户使用时,这个修复代价就包含了用户对产品的信任,体验等等,所以能够有独立的测试与开发并行进行产品研发是较为合理的模式。
    这是个人的一点看法,请指正。@陈皓

  19. 看过你的文章,我觉得你的观点有点主观,声明:仅个人观点讨论,无意冒犯。
    我来谈谈我的观点。
    我认为,测试人员不参与开发过程是可以的,但是测试人员一定要懂软件开发。我也遇到过很多测试人员,不懂系统,不懂软件,甚至对软件没有基本的概念,这时开发让他做什么他就做什么,所以,这样的测试人员,确实如你所说,没有必要专职。但是,我也见过一些优秀的测试人员,他们虽然不参与coding的过程,但是他们对用户的需求,对系统的耦合性,对系统的特征优劣有着更深刻的认识。他们甚至能够通过测试过程分析出你的代码逻辑,发现问题时不仅能够告诉你输入和结果,还能够建议你分析哪些相关的code。开发人员往往更专业与自己所负责的模块,但是优秀的测试人员,会对整个系统有着清楚的认识。能够分析你的code会对别人哪些code造成影响。还有就是,开发考虑问题往往是从技术角度去考虑,好的QA会从用户使用和需求方面去测试,这是开发无论如何都无法避免的定向思维。仅个人观点,欢迎讨论

  20. 作为一名在MS干了3年的SDET,我表示楼主对SDET的工作职责并没有很明确.
    首先,SDET是一名开发人员,只不过这名开发人员比较特殊,不是开发产品的,而是开发用于测试产品的工具.大家分工不同,方向不同而已,并不是完全的把开发分成两等公民
    其次,在MS里, Windows团队和Office团队的SDET和SDE的比例是3:1,事实上,产品的测试有无数的情况要模拟.如果没有专职的SDET团队来维护,那该是多么可怕的一件事情..
    再次,自动化测试难道只是为了重复的跑一些测试用例,节省人力么?请楼主认真的再了解一下什么叫持续构建,顺便再了解一下持续构建的优势是什么?然后您再思考一下自动化测试的意义在哪里,也许就明白了.
    最后,我诚挚的希望楼主不要以偏盖全,您的公司不需要QA,不代表整个IT行业都不需要,凡事总有个因果,如果这个行业真的不需要QA,那么QA怎么可能存在20多年呢?

  21. 首先,测试部门在研发团队里是必不可少的。因为程序员一般都很懒。。而且在开发的过程中往往思维比较局限,不可能一下子想到全部的issue。但QA部门如果像楼主说的那样做的话,肯定也是不行的。QA部门应该是研发团队的一部分,不能完全独立于开发部门。这也要看做的是什么项目,如果做的是实实在在的电子产品的话,有时候完全不懂开发的人来测试效果会更好。

  22. lz玩了个偷换概念的把戏。
    开始对“专职QA”画了个范围,到后面说着说着就把这个范围扩大了。
    请问一下lz,如果一个“专职QA”不符合你所说的第二条,对技术懂而且很熟悉,那这样的QA需不需要呢?
    看后面的内容,貌似也是不需要的,那你那段“专职QA”的说明就有点画蛇添足的味道了。
    你所经历的项目被QA部门搞得一团糟,只能说明你没公司管理有问题,或者所招的QA本身能力就有问题。
    一个成熟的大型的商业公司,必然少不了专职的QA。

    我们可以没有专职QA并不等于我们不需要专职QA。

  23. 依照lz的逻辑,我也来一段:
    ————————————————————-
    我们需要专职的销售吗?
    我想说明一下我观点里的这个“专职销售”是怎么定义的。

    1 其是很多公司成立的专门做销售人员,仅销售不开发。
    2 这些销售人员对于软件开发技术并不熟悉,甚至不懂。

    Dev对软件开发的整个流程都熟悉……balabala…….销售做的事情Dev完全可以做……..

    so…我们不需要专职销售…..

  24. 我做测试三年,TE跟QA完全是两码事。但国内测试的确不怎么规范。我们公司现在测试基本上除了堆代码基本上都是要求全能(环境配置,测试用例设计,测试用例执行,客户需求分析,新项目的摸索调查,开发该用什么具体的框架)。工作量极大。属于擦屁股类型,真的很累。

  25. 我觉得实质的问题就是要提高开发者的素质。

    一个是对于所谓的系统集成测试,尤其是那种比较复杂的系统,比如那种通信设备企业搞的LTE系统,要想把握全局的话,不仅需要软件技能,也需要有较好的通信知识,对相关3GPP协议要比较熟悉。这对程序员的要求其实不低,是需要积累的。从我们公司的情况来看,在软件这一块,国外的工程师相比国内的更具备这种能力,原因很简单,他们很少换工作,会在一个领域做几十年,很多都50几岁了。而中方员工,过了30就觉得好像要被淘汰了,无法安心做技术了。

    一个是责任心的问题,由开发者去做测试,是否会有主观上的回避问题的态度?我想如果是一个对产品负责,充满责任心的开发者,是能负责的去完成测试工作的。当然我们在不同的开发小组之间各自测试他人的产品。

  26. 不是说不能,我自己就是这样从编码到设计到各个环节学起来做起来的。同样,我也深知每个环节要做好并不易。反驳的观点只是说,一个公司要求他的开发人员队伍每个人都有这样的能力是很难做到的,那就是说他的编码人员队伍就得都要好几年工作经验的,就好像要求人人在道德水平都是雷锋似的。外国我不知道,在中国这是很难做到的。既然没有这套高水平队伍,那抛弃测试人员、设计人员等等做法就不可行。@lee68yt

  27. 看来码农真的很辛苦、、、虽然我不是很理解QA是什么东东、、、类似工厂里面的QC?

  28. “开发和测试,你中有我我中有你,原本就不分家” 精辟!
    是的,周围的确看有些公司,彻底取消掉专职测试,开发自己测:开发自己测试,只不过是交叉测试!

    此外, Gtac里面 Alberto Savoia 更极端, 测试已死!
    GTAC 2011: Opening Keynote Address – Test is Dead (需翻墙)

  29. 看完后,大多说观点严重同意.
    对后一句”如果不从需求分析,软件设计,代码实现上做好控制,到测试的时候你还怎么保证质量呢” 有些补充

    看看软件质量问题都是从哪些地方引入的呢?
    楼主已经给自己的答案: 需求,软件设计,代码实现上, 测试, 除此之外也不能忽略流程(比如code review, test case review, continous integration工具)对软件质量的贡献.

  30. 非常同意qingchunjun的观点,测试本身无法保证或者控制产品质量,测试的直接目的仅仅是评价/衡量当前软件的质量,将其共示出来用以督促掌控产品代码的人对其进行改进。

    开发人员能否客观的衡量自己作品的质量?这个问题的答案应该是决定是否需要专职测试人员的本质。

    这个问题且不作答。相信所有人起码在一点上达到共识:软件是需要测试的。

    单就功能测试而言,看似十分简单。反正现在的软件大都有GUI,随便找几个人来,在上面卡卡卡随便点一气,发现什么什么问题dev再改不就得了--这是当前大多数开发人员对于测试一事的认识,这种想法直接导致了很多根本不懂软件技术的人受雇称为QA的职位,从而引发楼主抱怨的种种问题。

    然而实际上,功能测试不仅仅是做出来一次就可以了,每一个test case都必须能够被一遍又一遍不断重复,以确保该bug被fix之后随着代码的演进,该bug没有重现。大量的test case覆盖了产品近乎全部功能之后,应该能够随着每次代码提交被自动执行,从而保证新鲜提交的代码没有break原有功能。

    将重复运行的工作交给机器去做当然是最佳选择。但是机器不会开发新的test case,不会选择输入的数据,不会自动生成配置环境的脚本,更不会编写调度test case的框架。这些工作由谁去做呢?当然可以由dev去做,但是假设一些dev本身负担着产品的开发,同时还负担着测试框架和测试用例的开发,等于要同步并行开发至少两个产品,这样安排是否合理?如果合理,那为什么不并行同步开发3个甚至更多产品?为什么软件公司研发部门内部还要分team,不干脆每个人都同时上所有的项目?

    从一般实践的角度,测试框架和测试用例的开发会交给专门的人去做。这些专门的人,到未必是在专门的部门,完全可以和开发者同属一个团队,这就因公司而异了。这些人在有些公司的title是SET(google),有些地方是SDET(microsoft),有些地方叫QE(sun microsystems)。但是一般被更加广义的称为QA。

    建议楼主不妨先寻找一些和真正优秀QA合作的机会,然后在回头来论述整个行业。

  31. 我想LZ在这个问题上走向了很多误区
    第一我认为你误解了QA和QC之间的定义
    第二,任何一个软件开发团队达到一定规模以后都需要QA或者QC这是不容置疑的,软件行业在中国发展到今天的同时LZ居然还能提出这样的问题,我觉得非常奇怪,大概LZ只能够从开发的角度来理解一个项目的制作过程,这无疑是偏颇的
    另外
    “我想说明一下我观点里的这个“专职QA”是怎么定义的。

    其是很多公司成立的专门做测试的技术人员,仅测试不开发。
    这些QA对于软件开发技术并不熟悉,甚至不懂。”

    sorry,这完全不是QA/QC的定义。我这里并不是从一个QA/QC的角度来讨论QA/QC存在的意义,而是从一个软件从需求设计,到开发,到走向市场的角度,想想就能理解了

    “你看,我们都同意,Dev要懂测试,QA要懂开发,只不过分工不同”
    这句话我也不能理解,在很多时候,QA并不需要懂开发,甚至不懂开发才能从另外一个客观的角度对产品进行评估。
    关于LZ遇到的问题,我只能说LZ遇到或者身处在比较糟糕的QA团队,而不能用这一点来表明软件开发不需要QA。还有这些LZ总结出来的原因:

    “给了QA全部测试的权力,但是没有给相应的责任,
    QA没有体会过软件质量出问题后的痛苦(解决线上问题的压力),导致QA不会主动思考和改进。
    QA对Dev的开发过程和技术完全不了解,增加了很多QA和Dev的沟通。
    QA对软件项目的设计和实现要点不了解,导致了很多不有效的测试。
    (我认为没有一点是与我所得的经验相符合的,也就是说,LZ完全误解了QA、QC这个职业的工作。)

    还有LZ的观点:
    {开发人员做测试更有效,开发人员如果都不知道怎么做测试,这个开发人员就是一个不合格的开发人员。
    减少沟通,扯皮,和推诿
    QA 做的测试计划,测试案例设计,测试结果,总是需要Dev来评审和检查。
    QA在做测试的过程中,总是需要Dev对其测试的环境,配置,过程做指导。
    QA总是会和Dev争吵某个问题是不是BUG,争吵要不要解决。
    无论发现什么样的问题,总是Dev去解决,QA从不fix问题。
    我们总是能听到,线上发生问题的时候,Dev的抱怨QA这样的问题居然没测出来,
    QA也总会抱怨Dev代码太差,一点也不懂测试,没怎么测就给hand over 给QA了。
    QA总是会push Dev,这个bug再不fix,你就影响我的进度了。
    等等,等等。
    *******在我现在的公司,程序员要干几乎有的事*****请注意这句话,这可能就是导致你们产生以上那么多痛苦,出现那么多问题的原因

    总结以上,所以我觉得LZ之所以能够有这片奇文,是基于以下的原因:
    1. 完全误解QA/QC的含义,也没有理解QA和QC之间的区别(这一点是最主要的原因。)
    2. LZ身处在一个非常糟糕的QA团队之中,没能够给你正确的概念作为引导
    3. LZ仅仅从一个角度出发,然后宏观整个项目的制作,你所谓的整个产品的制作,也不包括产品投入市场阶段以及维护。

  32. 我相信除了公理意外,所有的事情都需要辩论,最后才能得到很好的结果,今天确实受教了!

  33. 楼主,你应该站在商业的角度去看问题,你想想如果一个程序员从开发到部署上线所有的工作都干,在一个团队里面不是所有人都全干吧,如果所有人都写代码,配置服务器,那就乱了。所以肯定是团队中的一个人或者两个人在干,但是你想想如果全能的那个人离职了,怎么办? 是不是很影响团队的工作? 把所有东西做成流程化,就像持续交付里面,每个人扮演好自己得角色,离职了,也是影响一小块。

  34. 这样思考一下:如果是你的用户来做你的QA,你还敢这么要求他懂得开发吗?你的用户要是也懂得开发,…?其实QA主要的职责是深入用户业务,调查开发出来的软件是否符合业务要求并能保证业务价值升值(为什么?因为你的Boss不想多次面对用户指责你的产品很烂,需要在用户发现问题之前找个人跟用户一样发现问题并修改)。你遇到的问题我们也遇到过,那是因为Dev们只愿意深入了解技术而不想深入了解业务而导致Manager只好帮你找一个QA来做这些事。现实是QA们既对业务了解不足,对技术了解也不足,导致了你看到的那种乱象。你提及的功能点其实就应该对应业务的需求点,如果QA完全了解需求点,那绝对不会遗漏你的功能点,除非你做的功能根本不是用户需要的。你提及的性能瓶颈和内存泄露等问题,那确实不应该由QA负责,因为那完全属于你开发实现的范畴,那两个术语不是来自用户业务需求,而是来自开发技术领域的限制。出现那种问题只能说开发没有做好,不能说QA没有发现后跟你讲,虽然QA能发现并告知你是更好的结果,其实只需要你提交测试之前告诉QA你的关注点在哪里,他会帮你看的,这属于沟通的范畴。

  35. 开发人员需要完善自身的代码质量,过程中就包括了大部分的测试;
    QA除了制定个各种测试计划,最重要的还是要和开发人员一起了解软件模块的需求、开发的流程、这样才能更好的完成测试,而不是各做各的。

  36. 我就是一名QA, 不过幸好是“懂一点技术的QA“。 不过我想说的是, 懂不懂技术并不是衡量一个QA的核心能力, 也就是不懂技术也能做QA。 我同意博主很多观点, 包括, 质量并不是QA决定的, DEV要测试自己的代码。 但是我绝对不同意”不需要QA“这样一个说法。

    在我眼里, 最合理的分工是这样的, DEV会做单元测试, 模块级别集成测试 (都是自动化的测试; DEV做测试时, 焦点在 验证(Validate) 函数/接口 的行为符合 “给定” 的预期。 QA会做系统级的集成测试, 也就是说被测试系统是极其相关系统都是起来的.

    在测试的时候, Test基本上处于一种”探索”状态, 也就是说在那个时候“没有一个给定”的预期, Tester沿着Testcae给定的路线, 左顾右盼, 考察系统的行为是不是”适合的“。

    我举个例子, 有一个软件具有一个搜索对话框, 在探出对话框的时候, 它的焦点并不在输入查询文字的那个edit控件。 这个软件行为就不是”合适的“, 但这个行为并不是”给定”的, 任何spec上面也不会讲这个, DEV的单元测试肯定也不会去覆盖。

    但是理想和现实总是差别很大。 我遇到的较多的情况是。 由于开发时间紧, DEV并没有做单元/接口测试的时间, 甚至没有充分的 设计并编写代码 的时间。结果是很多“给定”功能, DEV都没有做好。 这个时候 QA实际上是花很大功夫把系统搭建起来, 用手工测试这样一种低效率的方式(相对自动测试)来验证那些“给定”的软件行为, 而这个应该是DEV做的。

    博主的情况我认为是 1. 有很好的Dev team, 2. 遇到不负责任的QA。 但因此而否定QA的作用, 我认为是完全偏颇的。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注