敏捷测试的最佳实践，三向敏捷测试转变
简洁，轻量的敏捷开发模型是为了提供给软件开发团队一种迅速应对客户需求变化，能够高效完成项目工作，降低整体风险的开发模式。敏捷的测试也是服务于这个目标的测试团队对测试工作的敏捷定义。
传统测试模式下成长起来的测试团队要如何转向敏捷，从个人和团队的两个层面又要做出那些转变呢？
有什么方法和标准衡量敏捷测试团队的绩效？如何帮助团队的每个人规划正确的发展路线？团队在部署敏捷
的过程中又会遇到哪些问题呢？本文主体就这些问题展开论述。
有关敏捷测试团队和个人的绩效
在我们过去一年多开发敏捷项目的令人难忘的经历中，测试团队携手开辟了一条新的道路，并发展至今。
测试团队也曾多次因其突出的能力，积极的态度以及卓有成效的工作成果屡受嘉奖。今天我们仍然在思考怎
样做好敏捷测试，因为我们仍然遇到更新的问题，我们在积累成熟经验的同时也在不断尝试改进原有方式和
突破对新问题的困扰。在这里，我们的实践或许因基于幸运的历史背景和人文环境，能够基本成功的部署敏
捷，但我们对敏捷测试在整个软件开发过程中的角色定位，和职责的理解，仍然对将要采用敏捷测试，以
及感兴趣于敏捷的测试团队，和对那些需要从传统测试转变到敏捷测试模式的团队起到参考作用。
“如何看待敏捷测试和对测试人员做绩效考评呢？”——敏捷团队中无论开发还是测试都不是个人的开
发和测试，这是团队的工作。一名好的测试人员除了能够做好本职测试工作外，表现为愿意并能够做超出
原有范围的工作，能够并愿意帮助团队其他成员解决其他复杂问题，实现团队的共同目标。测试人员能够
主动发现并弥补团队中的重要缺失的环节，帮助团队其他成员完成工作任务。
测试团队的职责也从仅仅发现问题的工作中向着眼于整个项目质量保障转变。因此不难得到结论，在
敏捷团队中，优秀的测试人员身上有其他成员的影子。在时间紧迫的情况下，他能转变成其他角色，做出
更多的创造性的成绩。充分地发挥了个人战斗力，在帮助他人的同时，自信的态度和各项工作中的技能得
到增强，自身也可以获得更大发展。
在一次关于敏捷开发、测试经验交流中，我们认为敏捷测试团队更需要其他团队的协助，在设计测试
用例时，团队的设计人员应该帮助测试团队设计测试用例，并帮助测试团队做更多的面向客户环境的真实
测试。开发团队也要确保开发任务的按时推进，和测试团队保持紧密的合作，在测试任务紧要时，也能够
转变其职能帮助测试团队完成测试任务。
测试人员向敏捷转变所需要的技能储备
这引出我们今天要探讨的一个问题，测试人员如何在技能上做好准备以面临敏捷开发的全新挑战。
我们认为，一名优秀的敏捷测试人员，需要有较强的学习能力，至少有主动学习的意愿。除了需要了解各
种类型测试以及各种测试工具，测试技术外，也需要了解项目中软件设计模式，软件语言，以及项目的
程序组织架构以便建立和团队的共同语言空间。
因为敏捷团队是一个高度协作的团队，在这样的团队中工作需要很好的沟通技巧，语言能力和协作
能力。
除此之外，团队的每个成员，都应该认真学习并努力寻找适合自己团队的敏捷模式，并沟通以达到
团队成员对敏捷开发模式的统一认识，使得团队其他成员对自己工作的充分理解和建立起成员之间的相
互信任。
测试人员向敏捷转变所需要的方法
培养好的敏捷测试人员，需要培养其技术能力，也需要用正确的培养成员的敏捷思想。敏捷的方
法指导敏捷团队行动，是敏捷测试原则的实践。从一开始，就深刻影响着团队中每个人。当然，方法不
是放之四海皆准的，需要团队对敏捷原则深入理解，执行敏捷测试实践后逐渐形成的规律。而一个传统
的测试团队，在固有的行为规律下，在成熟的产品线里，或者层次分明的复杂组织结构里如何做好向敏
捷的转变呢？似乎这种改变给许多人带来希望的同时伴随着一点恐慌？我们有没有可行的策略、方法可
以遵循呢？可否让团队又能够发挥在传统开发模式下的力量集中的优势，又能够做到敏捷的随需应变呢？
回答是肯定的。
在做转变的实施前，我们需要有心里准备，任何从传统开发到敏捷开发转变不可能一蹴而就，自然
也没有人能够将一个传统开发模式下的测试团队一夜之间变成彻底的敏捷。对这些还没有敏捷起来，但
仍然以此作为目标的项目团队我们建议循序渐进，基于笔者的亲身体验，提供以下实施的方法请大家参考。
首先我们建议采用迭代的开发模式作为向敏捷的模式转变的起点。很多传统开发模式或者基本上还是
瀑布式的开发，或者是周期性的瀑布式开发，这些都不是敏捷的迭代。敏捷的迭代是高度的迭代，不是瀑
布开发的不断累加。换句话说，传统开发是传递性的工作，一方完成，另一方接手。而敏捷活动的迭代行
为更强调尽早开展各项活动，从迭代的一开始就协同工作，共同实现团队迭代的目标。而一旦抵达迭代的
周期中最后一个工作日，此迭代宣布退出。
当完成了向迭代活动的转变完成后，接着，我们开始寻找项目过程、管理、执行中最紧要的问题，
并使用敏捷开发中的最佳实践来一一解决这些实际问题。也许，一开始这个过程是很缓慢，而且很难做
到一步成功，但是必须通过不屑的努力和足够的耐心，慢慢转变团队的固有思维方式，并最终努力获得
团队对改进后结果的统一认可。而一个问题被解决，或者不再是项目中最严峻的问题时，我们应该开始
寻找下一个待解决的困难了。重复这个过程直至成功的将团队中有悖于敏捷原则和实践的过程和方法调
整过来，同时将正确的思路和方法带给团队。
在最近的几次与其他敏捷测试团队的讨论中，我们同时了解到许多软件开发项目中的测试团队遇到过
类似的一些问题，如开发团队没有做单元测试或做得太少，继而在开发过程中的遗留了大量质量缺陷和频
繁的回归现象。这使得测试压力急剧加大，测试过程严重受阻，甚至影响到整个迭代的退出和项目的输出
结果等等。又或者传统的开发中的测试团队因为很少有条件去认识客户，了解和实际用户相关业务需求。
测试脚本和用例的设计只是基于开发人员撰写的功能说明。因此，难以做到对需求变化做出快速反应。经
过讨论，我们推荐给对这样的团队如下参考方案。
首先开始采用测试驱动开发 (Test Driven)。
开发人员首先要善于使用测试驱动开发方法写每一行代码，先写测试脚本后写代码，并反复使用单元
测试脚本验证所写代码的正确性。
列出需求
为需求撰写一个单元测试脚本
执行测试确信测试结果是失败的
然后，写上仅仅足够的代码以使得先前的测试可以通过
当所有测试通过了，便可以开始写下一个测试脚本
针对需求有效的实现所有测试脚本
另外，当需要代码重构时候，也应该先重构单元测试脚本，在改动代买之前同样先改写测试脚本。
尽早的开始测试，开始系统测试，不要等待到功能完全做好才开始。
了解计划中的待实现的功能，了解其权重分配，设计系统测试和功能测试用例。测试执行的一开始
可以是针对部分功能的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划
分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分（组件，构件）做完整
的安全测试，性能测试，压力测试，并发测试，全球化测试等。接着的迭代周期可以做边缘化的功能测
试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。
然后策略性的进行自动化测试，设计并开发可以用于日后回归测试（Regression）和用户接收测试（
Acceptance Test）的自动化脚本，持续维护与开发这些脚本。自动化测试为团队带来的是长期效益，自
动化测试的开发也应该首先选择部分测试对象，例如，API，框架等比较稳定和关键的功能做功能测试的
自动化；对产品的性能指标，压力测试也要较早的制定自动化测试的计划。
最后，要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。
而且，要做好敏捷测试，我们需要转变测试等待开发的思想，测试人员需要了解开发，需要读懂代码，才能够更好的帮助开发人员分析和分离复杂问题。有甚者，测试人员可以成为开发人员的后备力量。当团队中需要更多的人撰写代码时，测试人员应该勇当其职。
楼主说的我深有体会，在迭代开发过程中，测试主动协助开发分析和分离复杂问题能够更高的提高代码质量，实际上开发人员更多的关注到自己负责的特性上，对跟其他特性的交互上关注的没那么多，也不一定充分，这样测试就可以更多的从这方面提高关注，帮助开发共同完成这部分的工作，发现薄弱处，共同发力，提高质量。
页:
[1]
