济宁市建设工程招投标网站,湘潭网站建设网站,网站备案 价格,开发网站需要什么语言导读#xff1a;相信很多软件开发企业都有专职 QA。然而#xff0c;这些专职人员能否发挥其本身价值#xff1f;我们是否需要专职的QA#xff1f;针对这些问题#xff0c;本文作者提出了他的看法。 以下为文章原文#xff1a; 这个文章必然是有争议的#xff0c;我在我的…导读相信很多软件开发企业都有专职 QA。然而这些专职人员能否发挥其本身价值我们是否需要专职的QA针对这些问题本文作者提出了他的看法。 以下为文章原文 这个文章必然是有争议的我在我的微博上讨论过很多次了每次都是很有争议的。对于不同的观点有争论总是一件好事这样可以引发大家的思考。所以对于我的这篇博文如果你赞同我的观点我会感到高兴如果你会去认真地深入思考我也会高兴如果你反对没关系可以讨论。在此之前我想先说明一下我观点里的这个“专职QA”是怎么定义的 很多公司成立的专门做测试的技术人员仅测试不开发。 这些 QA 对于软件开发技术并不熟悉甚至不懂。 我之前供职过的公司几乎都有专职的QA团队专职的测试人员。自从在上个公司我的开发团队在一个项目上被QA部门搞得一团糟后我就越来越怀疑专职QA存在的意义。我的观点不一定对但请让我鲜明地表达一下——
企业不需要全职的QA甚至不需要QA这一专职角色或部门。因为不懂开发的人必然做不好测试就像不懂开发的研发经理必然管不好研发团队一样。现在
我越来越觉得Dev应该应该是做测试最合适的人选而这也必然是未来的趋势因为我已经看到了中国程序员的进步相比起10年前今天的程序员已经是非常全面了再来十年必然证明我的观点是对的。一、两篇文章 在我正在展开说明之前我想先引用两篇文章。一篇是《
On testers and testing》(
点击查看中文翻译)。本文的作者Sriram Krishnan是一名程序员曾在Yahoo和微软工作过开发过很多软件写过
一本书并曾接受过
纽约时报的采访。本文是他的一篇博客。他在文章中表达了以下这几个观点引用大多数的开发团队并不需要一个独立的测试角色。即使要有那么所有的开发时间比上所有的测试时间应该是 20:1的。证据吗光看看一些从古至今最成功的软件开发团队就知道了。不论是当今的Facebook还是30年前最初的NT团队很多伟大的产品都是出自没有或很少测试人员的团队。 开发人员应该测试自己的代码。这没什么可说的。背后的道理并不重要。这包括单元测试全覆盖的自动化测试、手工测试或组合测试等。如果你的开发人员不能、不愿意或认为这“不归我管”那你需要更好的程序员。另一篇文章是邹欣的《
现代软件工程讲义9 测试 QA 的角色和分工》。这是一篇很不错的文章。他在文章里提到了分工的必要性比如第三方的鉴定机构。并且也指出了分工的一些问题比如
画地为牢的分工、无明确责任的分工等等。这些问题直接命中了分工的要害。我隐约觉得我和邹欣的很多观点是相同的我们在内容上是相同的只是形式上还有分歧。另外我的观点太鲜明了从而容易引起极端的理解。你看我们都同意
Dev要懂测试QA要懂开发只不过分工不同。既然你中有我我中有你那就不要分彼此了一起携手开发测试吧。另外我个人觉得不懂开发的测试人员不可能测试得好。二、我的故事 我再说说我最糟糕的QA经历吧。之前我在一家公司工作这家公司的QA部门只做测试。他们的leader觉得所有的test design和test 的过程都不需要Dev参与他们是独立于Dev之外的部门他们几乎不关心Dev的设计和实现。他们只关心能跑通他们自己设计的测试用例。但是去执行测试用例的时候又需要Dev的支持尤其在环境设置、测试工具使用、确认是否是bug方面全都在消耗着Dev的资源。最让我感到绝望的是
他们对任何线上的问题不负责反正出了问题由Dev加班搞定。我有一次私自review他们的测试用例的时候发现很多的测试用例这样写到“Expected ResultMake sure every thing is fine”。
什么叫“Every thing is fine”而在测试用例设计的时候没有说明测试环境是什么没有说明测试数据在哪里测试用例、测试数据、测试配置都没有版本控制还有很多测试用例设计得非常冗余多个测试用例只测试了一个功能不懂得分析Function Point就做测试设计。另外我不知道他们为什么那么热衷于设计一堆各式各样的负向测试用例而有很多正向测试用例没有覆盖到。为什么呢
因为他们不知道开发和设计的细节所以没有办法设计出高效的测试用例只能从需求和表面上做黑盒。在做性能测试的时候需要Dev手把手的教怎么做性能测试如何找到系统性能极限如何测试系统的latency如何观察系统的负载CPU、内存、网络带宽、磁盘和网卡I/O、内存换页……如何做Soak Test如何观察各个线程的资源使用情况如何通过配置网络交换机来模拟各种网络错误等等等等。测试做得也不认真大量的False Alarm都是环境问题。比如安装新版本后没有重启服务没有使用新的配置文件网络配置等等等等。 在项目快要上线前的一周我又私自查看了一下他们的测试结果我看到5天的Soak Test 的内存使用一直往上涨很明显这是内存泄露。这个情况发生在2个月前但是一直都没有报告我只好和我的程序员每天都加班到凌晨赶在上线前解决了这个问题。但是
QA部门的同学们就像没发生什么事似的依然正常上下班。哎……为什么会这样我觉得有这么几点原因和邹欣的观点一样 给了QA全部测试的权力但是没有给相应的责任。 QA没有体会过软件质量出问题后的痛苦解决线上问题的压力导致QA不会主动思考和改进。 QA对Dev的开发过程和技术完全不了解增加了很多QA和Dev的沟通。 QA对软件项目的设计和实现要点不了解做了很多无效的测试。
注我无意在这里贬低QA的能力和工作只是我看到了QA因为没有参与开发的一些现实问题。 三、我的观点 邹欣对于分工出现的问题给出了两点解决方法 充分授权和信任Empower team members 各司其职对项目共同负责Establish clear accountability and shared responsibility 我的观点是
理论上正确操作上难以实现。 我无意在这里贬低QA的工作我也无意因为这个事走向另一个极端。但是我在现在公司的经历还有很多新兴公司的做法让我越来越觉得软件开发真的不需要专职的QA更不需要只写代码不懂做测试的专职的Dev。
观点如下 1、开发人员做测试更有效 开发人员本来就要测试自己写的软件。如果开发人员不懂测试或是对测试不专业那么这就不是一个专业的开发人员。 开发人员了解整个软件的设计和开发过程开发人员是最清楚应该怎么测试的这包括单元测试、功能测试、性能测试、回归测试以及Soak Test 等。 开发人员知道怎么测试是最有效的。开发人员知道所有的function point知道修复一个bug后哪些测试要做回归和验证哪些不需要。开发人员的技术能力知道怎么才能更好的做测试。 很多开发人员只喜欢写代码不喜欢做测试或者如他们所说开发人员应该关注于开发而不是测试。这个思路相当的错误。
开发人员最应该关注的是软件质量需要证明自己的开发成果的质量。
开发人员如果都不知道怎么做测试这个开发人员就是一个不合格的开发人员。另外我始终不明白为什么不做开发的QA会比Dev在测试上更专业 这一点都说不通啊。 2、减少沟通、扯皮和推诿 想想下面的这些情况你是否似曾相识 QA做的测试计划、测试案例设计、测试结果总是需要Dev来评审和检查。 QA在做测试的过程中总是需要Dev对其测试的环境、配置和过程做指导。 QA总是会和Dev争吵某个问题是不是bug争吵要不要解决。 无论发现什么样的问题总是Dev去解决QA从不解决问题。 我们总是能听到线上发生问题的时候Dev抱怨QA这样的问题居然没测出来。 QA也总会抱怨Dev代码太差一点也不懂测试没怎么测就给hand over 给QA了。 QA总是会催促 Dev这个bug再不修复你就影响我的进度了 如果没有QA那么就没有这么多事了DEV遇到自己的问题自己处理没什么好扯皮的。 一方面QA说Dev不懂测试另一方面Dev又说QA不懂技术。而我们还要让他们隔离开来没有沟通。
我们应该让Dev理解QA也要让QA理解Dev减少公说公有理婆说婆有理的现象出现。3、吃自己的狗食 真正优秀的开发团队都是要吃自己狗食的。
这句话的意思是如果你不能切身体会到自己糟糕的开发成果带来的痛苦就不会真正地去思考没有真正的思考就没有真正的进步。在我现在的公司程序员要干几乎所有的事需求分析、设计、编码、集成、测试、部署、运维、OnCall。因为 只有了解了测试的难度你才明白怎么写出可测试的软件怎么去做测试的自动化和测试系统。 只有自己真正去运维自己的系统你才知道怎么在程序里写日志、做监控、做统计…… 只有自己去使用自己的系统你才明白用户的反馈、用户的想法和用户的需求。
所以优秀的程序员深知这一点软件开发不单单只是编码还更明白整个软件工程。只明白或是只喜欢编码的那只能称之为码农不能称之为软件工程师。4、其它问题 关于SDET全称是Software Development Engineer on Test。像微软、Google、Amazon都有这样的职位。但我不知道这样的职位在微软和Google的比例是多少。那么像这样的懂开发的专职测试可以有吗我的答案是可以有但是我在想如果一个人懂开发为什么只让其专职做测试呢这样分工合理吗把程序员分成两等公民有意义吗试问有多少懂开发的程序员愿意只做测试开发呢所以SDET在实际的操作中更多的还是对开发不熟的测试人员。如果你说Dev对测试不专业、不细心、不认真那么我们同样也无法保证QA的专业、细心和认真。Dev遇到的的问题QA可能也会遇到。而出了问题QA不会来加班解决还是开发人员自己解决。所以如果QA不用来解决问题那么QA怎么可能真正的细心和认真呢如果你说不要QA的话Dev人手会不够。你这样想一下如果把你团队中现有的QA全部变成Dev。然后大家一起开发一起测试亲密无间沟通方便你会不会觉得这样会更有效你有没有发现在重大问题上Dev可以帮上QA的忙但是QA帮不上Dev的忙。第三方中立你会说程序员总是测不好自己写的东西因为有思维定式。没错我同意。但是如果是Dev交叉测试呢你可能会说开发人员会有开发人员的思维定式。那这只能说明开发人员还不成熟他们还不合格。没关系只要吃自己的狗食痛苦了就会负责的。磨刀不误砍柴功。如果你开发的东西自己在用那么自己就是自己天然的QA如果有别的团队也在用你开发的模块那么别的团队也就很自然地在帮你做测试了而且是最真实的测试。你可能会说吃狗食就是个笑话倘若换成我项目做得不好就离职走人让后来者去吃我的狗食。这个的确是这样的但是想一想你为什么在一开始不提醒他另外如果你的团队在设计评审和代码评审里没有把好关让某位程序员蒙混过关那么这为程序员离职后带来的问题还是要由你的团队来解决。于是整个团队都在吃自己的狗食这很公平。痛苦过一次你的团队就不敢随意招人、不敢随意评审代码、不敢让某位员工只做一块东西了。而这最终还是没有逃脱吃狗食的范畴。关于自动化测试。这是一个机械的重复劳动。我想让测试人员思考一下你是否在做这样的事如果你正在做这样的事那么你要思考一下你的价值了。但凡是重复性比较高的机械性劳动总有一天要被机器所取代。关于线上测试。我们都知道无论自己内测的怎么样到了用户那边总是会有一些测试不到的东西。所以有些公司可能会做用户验收测试做产品的公司会叫Beta测试。无论怎么样你总是要上生产线做测试的。对于互联网企业来说生产线上测试有的玩A/B 测试有的玩部分用户测试。比如新上线的功能只有10%的用户可以访问得到这样不会因为出问题让全部用户受到影响。做这种测试的人必然是开发人员。
