|
|
|
|
敏捷专家何勉：让测试成为拉动组织敏捷实施的力量 |
| |
|
作者 张红月 火龙果软件 发布于 2014-10-20 |
|
|
|
敏捷测试是指在敏捷开发模式下测试活动的规划、测试流程的组织、测试技术的实施，测试用例的管理以及测试人员的发展。
2014年11月14日到11月15日，由CTO俱乐部开设的敏捷测试研修班将在北京开课，此次培训主要面向资深测试人员、测试经理、开发经理、项目经理等中高端职位人群。该培训采取小班授课、实战练习、案例分析、寓教于乐的形式开展，人数限制在 20人左右，最大可能的保证人员们的学习质量。
为了帮助大家更好地了解课程内容，我们专门采访了此次的培训讲师何勉，请他来谈谈有关敏捷实施、敏捷测试等话题。
上海贝尔公司精益和敏捷教练 何勉
拥有超过14年的行业经验，承担过产品开发中的各类角色，拥有丰富的项目管理和团队管理经验，先后负责和管理过软硬件开发、测试及过程改进团队，国内最早的精益和看板方法的实践者传播者，综合应用各类方法推动组织的敏捷实施和互联网化改造。InfoQ《解析精益产品开发》系列文章的作者，Agile China 2013大会主席。
CSDN：请您谈谈什么是敏捷测试？
何勉：我们讲敏捷测试是指在敏捷开发模式下测试活动的规划、测试流程的组织、测试技术的实施，测试用例的管理以及测试人员的发展。敏捷开发模式给测试带来了挑战，也带来潜在的机遇，如何应对这些挑战并实现潜在的机遇是敏捷测试要回答的问题。我们把敏捷测试看成敏捷实施不可分割的部分，有效的敏捷测试会让敏捷实施更加顺畅、持久，并且带来对业务可见的真实价值。
CSDN：敏捷测试在国内的实际应用现状如何？
何勉：根据我们所亲身经历或所见的组织和团队，国内敏捷测试的提升空间和必要性是巨大的。关注敏捷实施的人会发现，对于流程框架、技术实践和产品需求，都有系统可行的方法和实践体系。
关于测试，虽然也有实例化需求、验收测试驱动开发等实践的出现，然而国内的成功实施却还相对比较少，部分原因是因为这些实践相对比较新，从理解到成功推广应用需要时间。 然而更重要的原因是：第一，我们必须从整个产品开发周期的角度来规划测试 ，例如让测试过程和需求的过程更有机的融合，而不是把测试看成一个完全独立的环节。第二，我们必须建立正确的质量观。测试不只是用来最后检查质量的把门人，而是要构建整个产品开发周期的质量守护体系，虽然在传统开发中我们也会强调这一点，但是在敏捷开发中它变的更加突出，成为必须。
以上两点都涉及到思想的转变，然后才是方法论和具体实践的转变，我们还有很长的路要走。所以关于敏捷测试，我们总体还处在比较初始的阶段，这与敏捷产品开发如火如荼的声势是不相符的，它已经成为敏捷产品开发实施、推广和成功的瓶颈。
CSDN：测试团队在从传统开发模式向敏捷模式转变的过程中存在哪些障碍？如何克服？
何勉：第一个障碍来自思维的转变，也就是对待测试和对待质量的态度，我们要建立的是全程测试和全面的质量观，这并不容易。为了做到这一点，我们就必须超越测试，站在整个产品开发生命周期的视角来看，我们提出“测试即需求”，测试要验证需求的有效性和正确性，那么我们为什么不能更早的介入需求的挖掘、分析和概念验证呢？
敏捷开发倡导“测试前置”，前置的第一层含义是更早的参与，但光讲概念没用，我们要通过实践来落实它。实例化需求作为一个实践体系，要求我们开始开发之前，由测试、开发和业务共同分析和澄清需求，产出经过概念发掘和验证的并且三方理解一致的需求，而最具体的衡量和产出物就是需求验收用例，测试在这里面的作用相当核心。实例化需求从概念上是易于理解的，但到实际操作时又会遇到很多问题，这就需要从更多的案例和上下文中汲取经验。
“测试前置”的第二层含义才是更早的测试，但它必须以更早和更有效的参与为基础。
另外一个障碍是迭代开发模式下测试的量变大。一个自然的答案是更多的自动化测试。这是一个说来容易，做起来却充满陷阱的事。
会写自动化测试的门槛不高，但要做出易于维护、易于创建、易于理解和高可用的自动化测试集就不容易了。自动化测试集的维护成本高到一定程度，甚至比没有自动化测试更糟，这样的例子比比皆是。为此我们必须放弃对量的盲目追求，而把重心放到质上来，我们需要关注自动测试脚本的设计模式，从分层自动化测试的构建、测试集的组织、测试脚本的组织、反馈循环的建立等多方面来提高自动化测试的质量。
社区中对代码质量的讨论有很多，却很少有自动测试脚本质量改进的实践分享，大家对自动测试质量的关注还远远不够，测试脚本还处于野蛮生长时期，这让自动测试成为质量的重灾区，使大量的投入非但没有回报，反而成为负担。我们强调“脚本即代码”，是想说我们要像重视代码质量一样重视测试脚本的质量。客观的讲，脚本质量的提高比代码质量的提高要容易，在团队中的实践让我们对此很有信心，我们也从实践中总结了系统和可操作的原则实践来帮助大家。
CSDN：引入敏捷测试后效率提升让您印象深刻的案例请您跟大家分享一下。
何勉：我不会把敏捷测试和敏捷实施分开来看，敏捷测试是敏捷实施的一部分；敏捷实施也必须包含敏捷测试。
我从2007年开始应用敏捷开发，先后负责过3家公司的敏捷转型，第一次敏捷实施现在看来并不成功，忽视测试和测试团队是主要原因之一。之后的两次敏捷实施都非常成功，在这两个案例中，我都是把敏捷测试体系的构建作为最早的实践来实施的，这并不是出于我对测试的偏爱，而是因为：第一，一个好的敏捷实施必须能端到端地改善客户价值的交付，而在我看来从测试开始是最好的选择。我们让测试人员参与到需求的讨论、分析和拆分中去，在一开始就明确需求应该是什么样的，这在短平快的迭代开发中是非常重要的，否则需求的质量没有保障，或者大家对需求的理解不到位，就只能是“Garbage in, Garbage out”了；相反如果在一开始就建立对需求的一致理解，测试对需求的验收也会更加顺畅。
这就形成了一个以客户价值为导向的端到端的流程，基本上就是所谓“验收测试驱动开发了”。在这一模式下，整个团队一开始就会对最终要交付什么样的用户价值达成一致，我们把它总结为“以终为始”。敏捷测试还包含更多的内容，但验收测试驱动开发框架对敏捷测试的成功十分关键。
通过实施敏捷测试，我们还看到团队协作的更好了，开发过程也更有序和高效。这让我坚信，测试应该是敏捷实施的推动力量，而不应该经常性的成为障碍。敏捷测试所提升的和敏捷产品开发的目标是一致的，首先是更加注重端到端真实用户价值的交付，我一直说，在各类角色中，测试是最应该代表用户价值的；其次，更早交付价值和灵活的应变。没有有效测试的迭代是自欺欺人的，是不能让我们更早交付价值和更灵活的应变的。
CSDN：为期两天的培训中您着重想和大家分享和传递的内容是？为什么？
何勉：我们会从收集学员们观察到的敏捷给测试带来的机会和挑战开始，构建一个机会和挑战的列表，而课程的目的就是要最大化潜在的机会和有效的应对这些挑战，我们在课程结束时还会回到这个列表，确保效果的达成。
培训过程，我们将从建立正确的敏捷质量观出发，那也是敏捷测试背后的原则基础；接下来我们会引入分层质量守护体系的概念，并以一个真实的产品案例为蓝本，引导学员分析产品的架构、质量风险、测试方式、回归策略，并构建符合自身产品特征的分层质量守护体系；在敏捷质量观和分层质量守护体系的基础上，我们将深入探讨团队的有效协作和敏捷测试流程——实例化需求，我们会特别强调可操作性，通过现场的案例，在实际操作练习中保证学员能够掌握实践细节。
第二天，我们会开始介绍和练习自动化测试，把第一天实例化需求练习中生成的测试用例自动化，并总结出自动化测试脚本的设计模式。接下来我们将解析不同层面（如接口测试和界面测试）的自动化测试、它们之间关系以及如何配合形成有效的质量守护体系。
以此为基础，我们将从测试集的组织、测试脚本的编写、测试活动的管理等方面分别总结、阐述做好自动化测试的实践原则。贯穿始终的，我们会分享来自不同行业的自动化测试的真实脚本和案例。最后，我们会总结两天的内容，呈现一个系统、可操作和注重实效的敏捷测试流程和技术体系。
|
|
|
|
|
