脚本是自动化测试的产物，敏捷开发周期短，变化多，很难拿到一个稳定的产品再开始做自动化。而自动化脚本的设计自然要避免去测试不稳定部分，开始的迭代周期几乎百废待兴，自动化作用不大，到了中期，笔者的团队自动化测试才稍成气候。

测试人员需要的是在根据测试策略开发出这相应脚本和用例，需要把握测试范围，与计划和测试策略一致，测试也要量力而行，做到足够的测试，保障迭代的正常退出就很好了。

图 8. 依据 Business Scenario 制定测试策略

敏捷测试的活动时间表

通过实施上述的敏捷测试原则，测试团队可以逐渐形成符合自身特点的敏捷测试流程、敏捷测试最佳实践，久而久之形成独立的敏捷团队文化。以笔者所在团队为例，历时 1 年，经历 12 个迭代后，我们逐渐形成了一套可以遵循测试活动时间表。我将他放到文章的最后，这张表包含了敏捷测试团队的各项活动安排和必要的前提与进入条件。在这张表中，测试团队较早的涉入，较早的开展测试，以及各项相关工作，并与设计和开发人员紧密的合作，它确保了测试团队乃至整个敏捷团队的工作的按期完成，是值得向大家推荐一种最佳实践。因为篇幅关系，这里仅对其做简单的描述。

图 9. 敏捷测试 Work Flow 最佳实践

第一周的工作如先前所讲，做静态测试，确定测试策略和制定可行的测试计划，划定测试范围。这个阶段的前提是敏捷团队确定了当下迭代周期内需要完成的 Backlog 项目。

第二周的工作是准备开始测试的执行，因此要准备好测试用例和测试环境。特别的是，测试人员是根据需求和团队讨论、设计出的用例来开发测试用例的。虽然测试用例的细节程度不能与传统开发中针对已经开发完的产品、产品开发文档开发的测试用例相比，相反，许多细节，尤其是还未由团队最终确定的内容仍是待定状态；但是，这些细节并非影响测试的用例设计，相反它不但简洁、易懂，也拥有很好的灵活度，它能够实时响应各种变化。而且，测试用例记录了大量的待定部分，它时刻在测试人员的脑中，测试人员用这种方式简单的告知团队，我们还有未完成的设计和未定的方案，测试用例帮助团队对产品的理解同步于此。

第三周的第三天，第一个可以执行的 Build 已经能够发布了（这个前提需要开发人员的密切配合）我们开始功能测试了。到第三周周末，一部分功能测试已经完成，大部分关键功能得到验证。

第四周我们要结束测试，包括 Confirmative 的测试部分和 Investigative 的测试。在迭代验收之前团队要通力合作解决各种能够解决的问题，保障 Backlog 的如期完成。这里有一个问题值得再次提出来和大家讨论，或许曾在敏捷项目中的许多人也都遇到了，那就是出现了一些质量缺陷没有来得及在迭代退出前完全解决的现象。那是不是说明测试不能够退出呢？笔者的回答是“不”。迭代的验收时间即是迭代退出时间，也是测试团队必须退出的时间。在实施中，我们将这些来不及解决的质量缺陷分成三类，一类是“希望能够解决”的质量缺陷，这部分未解决质量缺陷将要成为新一轮迭代的“将做事宜”，甚至可能作为新一轮迭代的需求做到 Backlog 里。第二部分是“必须解决”，这部分因为直接关系到最基本，最关键的功能，这样的质量缺陷必须被立刻解决，否则就必须承认本次迭代的失败了。第三部分是“不再重要的” 质量缺陷，这部分质量缺陷可以因为技术的不可实现，对客户产生较小的影响或者考虑到不久因为代码重构，这样的问题不在存在的理由，经过团队和 STAKEHOLDER 的批准可以置成“推迟解决”，待日后解决或者定义到产品的版本说明文档中。

回页首

结束语

在本文中，我们承接了敏捷测试最佳实践系列文章的第一篇，将前文的敏捷原则融入到敏捷测试的实践活动中来。本文所讲的实践围绕“人”和“过程”两个重点展开，指出敏捷活动的主体仍然是“人”，是“敏捷团队”。笔者给出了一种基于 Scrum 敏捷开发模式下的敏捷测试团队组织结构。接着，讲述了这支团队的敏捷测试“过程”。因实践本身是对原则和方法的具体定制，不同的实施背景，敏捷活动的具体表现形式各异。所以，本文始终倾向于提供给您一个可以借鉴的并已经实施成功的敏捷测试“过程和方法”，并与您分享实践经验。

本文为敏捷测试最佳实践系列文章之二，帮助您更详细的了解了敏捷测试的具体实施。而关于如何将一支传统测试团队发展成为一支敏捷的测试团队，在敏捷实践中又有可能遭遇哪些困惑和问题？笔者将在本系列的最后一篇文章“向敏捷测试转变”继续为您讲解。

敏捷测试的最佳实践，第 3 部分: 向敏捷测试转

变

2008 年 6 月 30 日

本文讲述了作者在两年的敏捷测试和开发工作中的经验和体会。从敏捷的实质，敏捷测试的方法和过程，到如何帮助传统团队转变为敏捷团队做了详细阐述。本文是系列的第三篇文章，着重讲述如何帮助传统团队转变为敏捷团队。

查看本系列的第一篇及第二篇：

? ?

敏捷测试的最佳实践，第 1 部分: 敏捷的实质 敏捷测试的最佳实践，第 2 部分: 方法与实践

引言

简洁，轻量的敏捷开发模型是为了提供给软件开发团队一种迅速应对客户需求变化，能够高效完成项目工作，降低整体风险的开发模式。敏捷的测试也是服务于这个目标的测试团队对测试工作的敏捷定义。 传统测试模式下成长起来的测试团队要如何转向敏捷，从个人和团队的两个层面又要做出那些转变呢？有什么方法和标准衡量敏捷测试团队的绩效？如何帮助团队的每个人规划正确的发展路线？团队在部署敏捷的过程中又会遇到哪些问题呢？本文主体就这些问题展开论述。

回页首

有关敏捷测试团队和个人的绩效

在我们过去一年多开发敏捷项目的令人难忘的经历中，测试团队携手开辟了一条新的道路，并发展至今。测试团队也曾多次因其突出的能力，积极的态度以及卓有成效的工作成果屡受嘉奖。今天我们仍然在思考怎样做好敏捷测试，因为我们仍然遇到更新的问题，我们在积累成熟经验的同时也在不断尝试改进原有方式和突破对新问题的困扰。在这里，我们的实践或许因基于幸运的历史背景和人文环境，能够基本成功的部署敏捷，但我们对敏捷测试在整个软件开发过程中的角色定位，和职责的理解，仍然对将要采用敏捷测试，以及感兴趣于敏捷的测试团队，和对那些需要从传统测试转变到敏捷测试模式的团队起到参考作用。 “如何看待敏捷测试和对测试人员做绩效考评呢？”——敏捷团队中无论开发还是测试都不是个人的开发和测试，这是团队的工作。一名好的测试人员除了能够做好本职测试工作外，表现为愿意并能够做超出原有范围的工作，能够并愿意帮助团队其他成员解决其他复杂问题，实现团队的共同目标。测试人员能够主动发现并弥补团队中的重要缺失的环节，帮助团队其他成员完成工作任务。

测试团队的职责也从仅仅发现问题的工作中向着眼于整个项目质量保障转变。因此不难得到结论，在敏捷团队中，优秀的测试人员身上有其他成员的影子。在时间紧迫的情况下，他能转变成其他角色，做出更多的创造性的成绩。充分地发挥了个人战斗力，在帮助他人的同时，自信的态度和各项工作中的技能得到增强，自身也可以获得更大发展。

在一次关于敏捷开发、测试经验交流中，我们认为敏捷测试团队更需要其他团队的协助，在设计测试用例时，团队的设计人员应该帮助测试团队设计测试用例，并帮助测试团队做更多的面向客户环境的真实测试。

开发团队也要确保开发任务的按时推进，和测试团队保持紧密的合作，在测试任务紧要时，也能够转变其职能帮助测试团队完成测试任务。

回页首

测试人员向敏捷转变所需要的技能储备

这引出我们今天要探讨的一个问题，测试人员如何在技能上做好准备以面临敏捷开发的全新挑战。我们认为，一名优秀的敏捷测试人员，需要有较强的学习能力，至少有主动学习的意愿。除了需要了解各种类型测试以及各种测试工具，测试技术外，也需要了解项目中软件设计模式，软件语言，以及项目的程序组织架构以便建立和团队的共同语言空间。

因为敏捷团队是一个高度协作的团队，在这样的团队中工作需要很好的沟通技巧，语言能力和协作能力。 除此之外，团队的每个成员，都应该认真学习并努力寻找适合自己团队的敏捷模式，并沟通以达到团队成员对敏捷开发模式的统一认识，使得团队其他成员对自己工作的充分理解和建立起成员之间的相互信任。

回页首

测试人员向敏捷转变所需要的方法

培养好的敏捷测试人员，需要培养其技术能力，也需要用正确的培养成员的敏捷思想。敏捷的方法指导敏捷团队行动，是敏捷测试原则的实践。从一开始，就深刻影响着团队中每个人。当然，方法不是放之四海皆准的，需要团队对敏捷原则深入理解，执行敏捷测试实践后逐渐形成的规律。而一个传统的测试团队，在固有的行为规律下，在成熟的产品线里，或者层次分明的复杂组织结构里如何做好向敏捷的转变呢？似乎这种改变给许多人带来希望的同时伴随着一点恐慌？我们有没有可行的策略、方法可以遵循呢？可否让团队又能够发挥在传统开发模式下的力量集中的优势，又能够做到敏捷的随需应变呢？回答是肯定的。 在做转变的实施前，我们需要有心里准备，任何从传统开发到敏捷开发转变不可能一蹴而就，自然也没有人能够将一个传统开发模式下的测试团队一夜之间变成彻底的敏捷。对这些还没有敏捷起来，但仍然以此作为目标的项目团队我们建议循序渐进，基于笔者的亲身体验，提供以下实施的方法请大家参考。 首先我们建议采用迭代的开发模式作为向敏捷的模式转变的起点。很多传统开发模式或者基本上还是瀑布式的开发，或者是周期性的瀑布式开发，这些都不是敏捷的迭代。敏捷的迭代是高度的迭代，不是瀑布开发的不断累加。换句话说，传统开发是传递性的工作，一方完成，另一方接手。而敏捷活动的迭代行为更强调尽早开展各项活动，从迭代的一开始就协同工作，共同实现团队迭代的目标。而一旦抵达迭代的周期中最后一个工作日，此迭代宣布退出。

当完成了向迭代活动的转变完成后，接着，我们开始寻找项目过程、管理、执行中最紧要的问题，并使用敏捷开发中的最佳实践来一一解决这些实际问题。也许，一开始这个过程是很缓慢，而且很难做到一步成