【专访】敏捷专家何勉:让测试成为拉动组织敏捷实施的力量

CSDN:请您谈谈什么是敏捷测试?

何勉:我们讲敏捷测试是指在敏捷开发模式下测试活动的规划、测试流程的组织、测试技术的实施,测试用例的管理以及测试人员的发展。敏捷开发模式给测试带来了挑战,也带来潜在的机遇,如何应对这些挑战并实现潜在的机遇是敏捷测试要回答的问题。我们把敏捷测试看成敏捷实施不可分割的部分,有效的敏捷测试会让敏捷实施更加顺畅、持久,并且带来对业务可见的真实价值。

CSDN:敏捷测试在国内的实际应用现状如何?

何勉:根据我们所亲身经历或所见的组织和团队,国内敏捷测试的提升空间和必要性是巨大的。关注敏捷实施的人会发现,对于流程框架、技术实践和产品需求,都有系统可行的方法和实践体系

关于测试,虽然也有实例化需求、验收测试驱动开发等实践的出现,然而国内的成功实施却还相对比较少,部分原因是因为这些实践相对比较新,从理解到成功推广应用需要时间然而更重要的原因是:第一,我们必须从整个产品开发周期的角度来规划测试 ,例如让测试过程和需求的过程更有机的融合,而不是把测试看成一个完全独立的环节。第二,我们必须建立正确的质量观。 测试不只是用来最后检查质量的把门人,而是要构建整个产品开发周期的质量守护体系,虽然在传统开发中我们也会强调这一点,但是在敏捷开发中它变的更加突出,成为必须。

以上两点都涉及到思想的转变,然后才是方法论和具体实践的转变,我们还有很长的路要走。所以关于敏捷测试,我们总体还处在比较初始的阶段,这与敏捷产品开发如火如荼的声势是不相符的,它已经成为敏捷产品开发实施、推广和成功的瓶颈。

CSDN:测试团队在从传统开发模式向敏捷模式转变的过程中存在哪些障碍?如何克服?

何勉:第一个障碍来自思维的转变,也就是对待测试和对待质量的态度,我们要建立的是全程测试和全面的质量观,这并不容易。为了做到这一点,我们就必须超越测试,站在整个产品开发生命周期的视角来看,我们提出“测试即需求”,测试要验证需求的有效性和正确性,那么我们为什么不能更早的介入需求的挖掘、分析和概念验证呢?

敏捷开发倡导“测试前置”前置的第一层含义是更早的参与,但光讲概念没用,我们要通过实践来落实它。实例化需求作为一个实践体系,要求我们开始开发之前,由测试、开发和业务共同分析和澄清需求,产出经过概念发掘和验证的并且三方理解一致的需求,而最具体的衡量和产出物就是需求验收用例,测试在这里面的作用相当核心。实例化需求从概念上是易于理解的,但到实际操作时又会遇到很多问题,这就需要从更多的案例和上下文中汲取经验。

“测试前置”的第二层含义才是更早的测试,但它必须以更早和更有效的参与为基础

另外一个障碍是迭代开发模式下测试的量变大。一个自然的答案是更多的自动化测试。这是一个说来容易,做起来却充满陷阱的事。

会写自动化测试的门槛不高,但要做出易于维护、易于创建、易于理解和高可用的自动化测试集就不容易了。自动化测试集的维护成本高到一定程度,甚至比没有自动化测试更糟,这样的例子比比皆是。为此我们必须放弃对量的盲目追求,而把重心放到质上来,我们需要关注自动测试脚本的设计模式,从分层自动化测试的构建、测试集的组织、测试脚本的组织、反馈循环的建立等多方面来提高自动化测试的质量。

社区中对代码质量的讨论有很多,却很少有自动测试脚本质量改进的实践分享,大家对自动测试质量的关注还远远不够,测试脚本还处于野蛮生长时期,这让自动测试成为质量的重灾区,使大量的投入非但没有回报,反而成为负担。我们强调“脚本即代码”,是想说我们要像重视代码质量一样重视测试脚本的质量。客观的讲,脚本质量的提高比代码质量的提高要容易,在团队中的实践让我们对此很有信心,我们也从实践中总结了系统和可操作的原则实践来帮助大家。

CSDN:引入敏捷测试后效率提升让您印象深刻的案例请您跟大家分享一下。

何勉:我不会把敏捷测试和敏捷实施分开来看,敏捷测试是敏捷实施的一部分;敏捷实施也必须包含敏捷测试。

我从2007年开始应用敏捷开发,先后负责过3家公司的敏捷转型,第一次敏捷实施现在看来并不成功,忽视测试和测试团队是主要原因之一。之后的两次敏捷实施都非常成功,在这两个案例中,我都是把敏捷测试体系的构建作为最早的实践来实施的,这并不是出于我对测试的偏爱,而是因为:第一,一个好的敏捷实施必须能端到端地改善客户价值的交付,而在我看来从测试开始是最好的选择。我们让测试人员参与到需求的讨论、分析和拆分中去,在一开始就明确需求应该是什么样的,这在短平快的迭代开发中是非常重要的,否则需求的质量没有保障,或者大家对需求的理解不到位,就只能是“Garbage in, Garbage out”了;相反如果在一开始就建立对需求的一致理解,测试对需求的验收也会更加顺畅。

这就形成了一个以客户价值为导向的端到端的流程,基本上就是所谓“验收测试驱动开发了”。在这一模式下,整个团队一开始就会对最终要交付什么样的用户价值达成一致,我们把它总结为“以终为始”。敏捷测试还包含更多的内容,但验收测试驱动开发框架对敏捷测试的成功十分关键

通过实施敏捷测试,我们还看到团队协作的更好了,开发过程也更有序和高效。这让我坚信,测试应该是敏捷实施的推动力量,而不应该经常性的成为障碍。敏捷测试所提升的和敏捷产品开发的目标是一致的,首先是更加注重端到端真实用户价值的交付,我一直说,在各类角色中,测试是最应该代表用户价值的;其次,更早交付价值和灵活的应变。没有有效测试的迭代是自欺欺人的,是不能让我们更早交付价值和更灵活的应变的。

CSDN:为期两天的培训中您着重想和大家分享和传递的内容是?为什么?

何勉:我们会从收集学员们观察到的敏捷给测试带来的机会和挑战开始,构建一个机会和挑战的列表,而课程的目的就是要最大化潜在的机会和有效的应对这些挑战,我们在课程结束时还会回到这个列表,确保效果的达成。

培训过程,我们将从建立正确的敏捷质量观出发,那也是敏捷测试背后的原则基础;接下来我们会引入分层质量守护体系的概念,并以一个真实的产品案例为蓝本,引导学员分析产品的架构、质量风险、测试方式、回归策略,并构建符合自身产品特征的分层质量守护体系;在敏捷质量观和分层质量守护体系的基础上,我们将深入探讨团队的有效协作和敏捷测试流程——实例化需求,我们会特别强调可操作性,通过现场的案例,在实际操作练习中保证学员能够掌握实践细节。

第二天,我们会开始介绍和练习自动化测试,把第一天实例化需求练习中生成的测试用例自动化,并总结出自动化测试脚本的设计模式。接下来我们将解析不同层面(如接口测试和界面测试)的自动化测试、它们之间关系以及如何配合形成有效的质量守护体系。

以此为基础,我们将从测试集的组织、测试脚本的编写、测试活动的管理等方面分别总结、阐述做好自动化测试的实践原则。贯穿始终的,我们会分享来自不同行业的自动化测试的真实脚本和案例。最后,我们会总结两天的内容,呈现一个系统、可操作和注重实效的敏捷测试流程和技术体系。

转自http://www.csdn.net/article/2014-10-16/2822126-agile-testing


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值