BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

QA部门将会消亡

| 作者 Eli Lopian 关注 0 他的粉丝 ,译者 王瑜珩 关注 0 他的粉丝 发布于 2012年11月6日. 估计阅读时间: 8 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

工业革命始于250年前,在工厂中、农田里、矿井上,机器开始代替人类进行生产劳动。这在极大的促进了经济增长的同时,也深深的伤害了那些技能一般、无法找到新工作或者没有足够知识去转行的人,这与目前QA所处的境地有着惊人的相似。上世纪九十年代,由于互联网泡沫的出现,对软件开发的需求急速膨胀,这就需要大量QA来进行测试,以保证软件能够顺利发布。因此,像Mercury Interactive这样的测试公司便如雨后春笋般出现。然而,当互联网泡沫破裂时,公司纷纷消减预算,敏捷开发变得更加普及,自动化测试开始接手(QA的手工测试)。就像工业革命时手工劳动者被机器所淘汰一样,以手工测试为生的QA也面临同样的困境。很多QA人员从质量保证转移到了需要编程技能的岗位上去,独立的QA团队消失,QA融合到开发团队中产生了跨职能团队。柏林墙倒了。

让我们回过头来,看看以前我们是怎么开发软件的。自五十年代开始,瀑布模型被大多数软件开发团队所采用。开发人员首先对整个系统进行预先设计,然后集中编写代码,再把写好的软件交给QA进行测试,最后修复QA找到的缺陷。当进度压力总是伴随着开发人员,使得开发人员永远无法按时交付时,开发人员对QA的依赖也越来越强。恶性循环由此产生,雇佣的QA越多,开发人员就越多的依赖QA,同时也越少对他们自己的代码进行测试,由此又需要雇佣更多的QA……最后开发人员干脆就不测试自己的代码了。

这种方式对于开发人员和测试人员都是低效的,软件交付被拖延,最终产品无法及时交付到客户手中。

在互联网泡沫破裂的同时,2001年2月敏捷宣言发布了,一种新的开发思想浮出水面。敏捷开发方法将开发人员带入了崭新的世界,适应变化和快速交付可工作的软件成为开发团队的关注点。敏捷还使得整个团队都参与到开发的各项工作中,特别是对开发人员测试的重视胜过QA的手工测试。随着敏捷更加普及,效率持续提高,对QA的需求变得更少,QA已经有一只脚踏出了(软件行业)这扇们。

QA越多,问题就越多

企业级软件开发是复杂并且昂贵的,管理层经常会发现无法达成计划的目标,从而需要决定如何应对这种情况。他们有三个选择来解决按时交付的问题。

  1. 增加预算 —— 你不是每次都能给项目增加预算的,但如果可以,这或许可以帮助你按时完成项目,同时也需要考虑效果递减法则。
  2. 减少特性 —— 开发人员和管理层一般都不倾向于让客户花同样的钱却买到更少的东西,对很多公司来说这不是一个可行的办法。
  3. 降低质量 —— 虽然我们无法摆脱软件缺陷,但软件质量可能对任何产品来说都是最重要的部分,不幸的是,降低质量通常是人们最先选择的方案。

当开发人员面临压力(或者仅仅因为懒惰),而写出质量不高的代码时,管理层却在减少QA的数量。这就是问题的根本所在,也是敏捷将要解决的问题。

敏捷就是答案

随着敏捷方法的流行,开发人员和管理者似乎找到了构建高质量软件的钥匙。虽然两方之间仍有很多不同的观点,但至少大家都希望能够在最短的时间内将软件构建出来,当然管理者还希望尽可能少花钱。

互联网泡沫破裂后,随着经济形势的回落,企业也意识到他们需要降低软件开发的成本,但他们该如何减少QA部门的高昂花销呢?

敏捷软件开发让开发人员自己测试自己的代码,单元测试通过就表示单元级别的代码能够正确完成预期的功能,当然这还需要整个团队一起努力。产品经理负责保证产品能够满足客户的需要,开发人员和测试人员一起编写测试用例,然后开发人员编写单元测试来保证质量。构造良好的测试是保证软件交付的唯一方法,也是敏捷软件开发的核心,它可以保证代码按照开发人员的意图工作。在开发人员承担测试自己代码的职责后,QA仍有存在的价值,他们需要寻找那些非常难以发现的问题。敏捷软件开发的一个支柱就是可以工作的软件,有些敏捷方法包含了测试驱动开发和开发人员执行的单元测试,而单元测试被用来检查你写的代码。通过这种保证局部的方式来让整体获益,以便得到持续的、及时的反馈,是一种快速、高效的抵御缺陷的方式。如果没有足够的单元测试覆盖,你很难敏捷起来,因为设计是在持续变化的,而变化会引入缺陷,如果无法在开发时发现这些缺陷,项目就会陷入困境。

单元测试-潜在的QA杀手

单元测试可以用来测试一小段代码,以保证代码做了正确的事,并能够被集成到整个软件系统中去。单元测试已经被证明可以达到90%以上的代码覆盖率,和QA使用的手工测试工具相比,构建良好、自动执行的单元测试可以随着代码一起演进,实时对代码进行测试。

我并不是说单元测试可以解决所有的开发问题,但作为测试代码(和促进设计)的工具,单元测试可以用更低的成本快速提升软件质量。自动化单元测试和测试驱动开发也是构建高质量软件所需要的,它们可以让开发人员更快速的适应新需求和其他的变化。

QA手工测试可能是九十年代互联网泡沫时期的救世主,但公司纷纷意识到QA团队阻碍了对变化的适应。单独的QA团队只会拖延开发人员修复错误的时间,敏捷开发和单元测试则保证了开发人员写完代码时,软件就可以工作了。

我们将去往何处?

我打赌你一定很奇怪为什么我会选择这样一个标题,这可能与我是Don McLean的粉丝有关。此外,我觉得对于一篇关于QA是如何从软件开发的主力走向边缘的文章,这会是一个很贴切的标题,QA即将消亡。可现实是,QA部门依然存在于很多公司之中,这种情况还将持续多久?我个人认为这只是时间问题,测试的任务迟早会转移到开发人员身上,开发人员需要测试自己的代码,而不依赖于任何QA部门。

当然,还会有很多专业QA继续呆在这个行业之中,不同的是他们不再是独立的部门,而是成为开发团队的一分子。敏捷需要跨职能角色之间的沟通,推倒降低效率的部门隔阂。传统的QA部门只会降低开发速度,拉高开发成本,只有一种方法可以解决:开发人员测试。这不意味着不再需要QA,而是需要QA重新定义自己的角色,与时俱进。不能再一成不变了,他们需要融入开发团队,在自动化单元测试中贡献价值;或者加入到产品管理中去,致力于定义让客户满意的产品。

当我们将(测试)职责转移到开发人员身上时,开发人员将会写出更干净的代码,构建出缺陷更少、质量更高的软件。这一切都取决于公司如何组织,以便在不降低质量的情况下降低成本。

关于作者

Eli Lopian是单元测试工具公司Typemock的创始人和首席执行官。在创建Typemock之前,Eli曾在AMDOCS(NYSE:DOX)和DEC等国际公司工作,拥有17年的研发经验,并曾负责优化开发流程和改善开发环境与工具。
 

 

查看英文原文:http://www.infoq.com/articles/day-qa-dept-died


给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

同意 by song zhang

最后说的好

其实软件开发者也在消亡 by s l

越来越多的业务需求主要难点出现在业务对象的映射上,研发不是那么重要,加之以可复用模块的应用,更多的是架构设计,具体代码实现显得不是非常的重要了。
当年Java语言的出现,极大的助长了“便宜”编程人员的增加,更多的c++人员被挤榨,面向对象那些年基本是java的天下,开发人员越来越廉价,架构师和QA共同约束和验证研发的劳动成果。这就如同工厂生产线一样,工作流程、模块划分、架构模式均规定好的情况下,研发只要按照既定的模式做就可以了,研发的人员成本也大幅下降,缩减了研发成本,同时使人员替代性增加,降低人员流动带来的风险,对于企业来讲,更多的利润H和更稳定的盈利才是吸引人的,至于有多少研发、是不是要QA部门这都看企业基因和利益至上决定的。

Re: 其实软件开发者也在消亡 by Yang Yang

不大同意。

敏捷开发的东西,一般都是没有架构师的。

同样的,你说的这些基于一个成熟的需求,成熟的实现。这样开发人员就按部就班的开发,基本上就不需要开发了。这样的情况确实存在,但是稍微一演变就变成了另外一种情况:比如说ERP领域。这样的行业发展的结果,就是诞生了SAP这样的公司。整个ERP领域的开发人员只需要去少数几家公司,而这几家公司以外的人,都变成了ERP的用户和使用者。 这就是行业软件的诞生。同样的还有甲骨文对数据库行业的统治。在它之外已经基本上不需要数据库的开发人员了。……但是,甲骨文和SAP的软件开发人员的工资都是高得吓人的

此外,在其他的行业,领域软件尚未出现的,或者是根本没有办法出现的行业。则有大量的开发。开发是一种创新性劳动,有的时候因为要实现需求,架构也可以随意被推倒。而正是因为这些行业的不成熟,开发人员的智力劳动非常有价值,他们的劳动根本没有办法用现成的模块来做。很多时候,都是从头搭建,没有任何可以参考的。典型的例子,就是淘宝和支付宝。……淘宝和支付宝的工资是十分可观的。

第三种,那就是手机等小型app的开发。这里开发人员就几个人,根本不需要架构师。

Re: 其实软件开发者也在消亡 by biao jiang

同意你的看法,大型软件(企业级服务)多半都需要架构师和QA主管,程序员只是可替换的零件

Re: 其实软件开发者也在消亡 by 瑜珩 王

没有任何一个敏捷流方法说过不要架构师,需不需要取决于项目规模和人员构成,和使用不使用敏捷没有半毛钱关系

Re: 其实软件开发者也在消亡 by 瑜珩 王

程序员如果可以随便替换,早就被机器所代替了,就像流水线上的机器人

Re: 其实软件开发者也在消亡 by Yang Yang

传统的架构师,是瀑布流的产物,是提供重量级解决方案的。

都敏捷了,迭代开发了。架构师已经没有任何存在的价值。敏捷团队最多需要的是“敏捷架构师”——这更类似于教练,而不是架构师。他的职责是沟通团队,协调团队。他只能提出建议,不能决定架构。

敏捷团队根本就不需要架构师提供的整套解决方案,如果都有整套架构和解决方案了。那要敏捷干什么?瀑布流,不就行了么? 敏捷的产生,就是因为架构师搞不定,不能从一开始搞架构,概要设计详细设计,直到把任务分解到最小。然后程序员搬砖头。凡是这样的模式,都是假敏捷,真瀑布!

Re: 其实软件开发者也在消亡 by cy shun

我到觉得没必要计较什么瀑布敏捷,任何方法都有其优缺点,取其精华去其糟粕,对一些基本可以确定的需求,去架构设计,不确定变化大的需求,使用敏捷,需求稳定后再设计、重构,即能保证系统的灵活性,又能保证软件架构的完整。总结为一句话,任何方法的最终目的都是为结果服务的,那样适用就使用哪个。

Re: 其实软件开发者也在消亡 by Yang Yang

我也没否定瀑布方法啊。

在需求明确的情况下,瀑布方法比较好。

需求不明确的情况下,敏捷比较好。

但是比较适合用瀑布方法开发的软件,比较容易做成产品。这样,如果不是更新换代,确实不需要开发人员什么事情。但是,大多数情况下……更新换代还是需要的

看清楚标题:QA部门将会消亡 by lee ken

QA部门将会消亡,不是说测试要消亡。测试的岗位存不存在不重要,关键质量控制要有人做。如facebook,没有测试title的人,但是有开发工程师在做测试。还有发布前的dog food。等等,所以有没有QA部门不重要,重要的是有人关注质量,控制质量。

Re: 其实软件开发者也在消亡 by s l

不妨把你理解的"敏捷"说一下,这样别人才有可喷的地方;
如果你个人的发展路径有过 研发——>研发经理——>产品经理,哪怕一部分,也不至于说出架构师不被需要这种话来。
敏捷对架构的需求远胜于传统瀑布模型,有预见性的架构才能极大的支撑的起快速变化的需求,不然的话,变化的需求最后会将软件弄成一堆不可维护的烂代码。

Re: 看清楚标题:QA部门将会消亡 by s l

+1
研发如果有测试者的心态的话,就是对质量的最大控制。。。

单元测试仅是测试的一部份,不是全部 by guan anfan

开发人员自测代码可以提高一些不必要的缺陷,但是像兼容性,易用性这些开发怎么可能自己能把握的好?有了单元测试并不是说不需要测试人员了;自动化测试也不是万能的,它的存在又不是一天两天了,很多大公司一直在做,但是QA也仍然存在;不同意作者的观点,夸大了单元测试的作用

QA部门将消失,测试人员将会长期与团队共存 by zhao xiaobin

这里所说的QA部门很多公司称为测试部门,独立存在的测试部分会逐渐消失,同时跨职能团队的兴起,也将减少测试与开发的差异。

Re: 其实软件开发者也在消亡 by 瑜珩 王

你反对的其实不是“架构师”这个角色,而是事先做大量详细的预先设计的问题

Re: 单元测试仅是测试的一部份,不是全部 by 瑜珩 王

确实,单元测试只能在一个层面上保证质量,还需要其他种类的测试,包括手工测试,来覆盖其他层面

Re: 单元测试仅是测试的一部份,不是全部 by sheng yan

现在有些应用,主要在业务测试、界面测试。单元测试很难覆盖到这方面。

可见的趋势下 QA的确需要重新定位自己 by hui an

我相信这会是一个长期的过程 因为测试不光有数量 测试本身也有质量 并且单元测试也不是包治百病的
从长期的趋势看 确实只会手动重复的功能测试的QA确实会逐渐没有市场了 开发过程的不断演进中 QA需要找到自己新的定位
比如可以利用自己善于设计case的长处提高单元测试的质量
保障团队开发实践的质量
或保障项目的测试策略
还有一些非功能性测试也可以成为将来QA的用武之地

Re: 其实软件开发者也在消亡 by jim dash

第三种,那就是手机等小型app的开发。这里开发人员就几个人,根本不需要架构师。----只是你没有见过大的而已。

Re: 同意 by 闫 志红

是时候给程序员配俩小密了,一个管测试,一个管文档。

Re: 其实软件开发者也在消亡 by hunk hsu

同意!尤其是稍微业务多一些的项目,如果开始的架构有问题,后期的plus每加一个功能就是一个炼狱

QA不应是个独立部门,而更应是整个开发项目组的一部分 by Chen Fei

我认为QA就不应独立出来,应从项目一开始就介入。测试这一角色也会一直保持下去。至于测试是否也要像开发那样往代码上攻破技能,我觉得可以是个人选择。测试包含范围很广。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

22 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT