(转)敏捷测试的最佳实践，第 3 部分: 向敏捷测试转变
引言
简洁，轻量的敏捷开发模型是为了提供给软件开发团队一种迅速应对客户需求变化，能够高效完成项目工作，降低整体风险的开发模式。敏捷的测试也是服务于这个目标的测试团队对测试工作的敏捷定义。
传统测试模式下成长起来的测试团队要如何转向敏捷，从个人和团队的两个层面又要做出那些转变呢？有什么方法和标准衡量敏捷测试团队的绩效？如何帮助团队的每个人规划正确的发展路线？团队在部署敏捷的过程中又会遇到哪些问题呢？本文主体就这些问题展开论述。
有关敏捷测试团队和个人的绩效
在我们过去一年多开发敏捷项目的令人难忘的经历中，测试团队携手开辟了一条新的道路，并发展至今。测试团队也曾多次因其突出的能力，积极的态度以及卓有成效的工作成果屡受嘉奖。今天我们仍然在思考怎样做好敏捷测试，因为我们仍然遇到更新的问题，我们在积累成熟经验的同时也在不断尝试改进原有方式和突破对新问题的困扰。在这里，我们的实践或许因基于幸运的历史背景和人文环境，能够基本成功的部署敏捷，但我们对敏捷测试在整个软件开发过程中的角色定位，和职责的理解，仍然对将要采用敏捷测试，以及感兴趣于敏捷的测试团队，和对那些需要从传统测试转变到敏捷测试模式的团队起到参考作用。
“如何看待敏捷测试和对测试人员做绩效考评呢？”——敏捷团队中无论开发还是测试都不是个人的开发和测试，这是团队的工作。一名好的测试人员除了能够做好本职测试工作外，表现为愿意并能够做超出原有范围的工作，能够并愿意帮助团队其他成员解决其他复杂问题，实现团队的共同目标。测试人员能够主动发现并弥补团队中的重要缺失的环节，帮助团队其他成员完成工作任务。
测试团队的职责也从仅仅发现问题的工作中向着眼于整个项目质量保障转变。因此不难得到结论，在敏捷团队中，优秀的测试人员身上有其他成员的影子。在时间紧迫的情况下，他能转变成其他角色，做出更多的创造性的成绩。充分地发挥了个人战斗力，在帮助他人的同时，自信的态度和各项工作中的技能得到增强，自身也可以获得更大发展。
在一次关于敏捷开发、测试经验交流中，我们认为敏捷测试团队更需要其他团队的协助，在设计测试用例时，团队的设计人员应该帮助测试团队设计测试用例，并帮助测试团队做更多的面向客户环境的真实测试。开发团队也要确保开发任务的按时推进，和测试团队保持紧密的合作，在测试任务紧要时，也能够转变其职能帮助测试团队完成测试任务。
测试人员向敏捷转变所需要的技能储备
这引出我们今天要探讨的一个问题，测试人员如何在技能上做好准备以面临敏捷开发的全新挑战。我们认为，一名优秀的敏捷测试人员，需要有较强的学习能力，至少有主动学习的意愿。除了需要了解各种类型测试以及各种测试工具，测试技术外，也需要了解项目中软件设计模式，软件语言，以及项目的程序组织架构以便建立和团队的共同语言空间。
因为敏捷团队是一个高度协作的团队，在这样的团队中工作需要很好的沟通技巧，语言能力和协作能力。
除此之外，团队的每个成员，都应该认真学习并努力寻找适合自己团队的敏捷模式，并沟通以达到团队成员对敏捷开发模式的统一认识，使得团队其他成员对自己工作的充分理解和建立起成员之间的相互信任。
测试人员向敏捷转变所需要的方法
培养好的敏捷测试人员，需要培养其技术能力，也需要用正确的培养成员的敏捷思想。敏捷的方法指导敏捷团队行动，是敏捷测试原则的实践。从一开始，就深刻影响着团队中每个人。当然，方法不是放之四海皆准的，需要团队对敏捷原则深入理解，执行敏捷测试实践后逐渐形成的规律。而一个传统的测试团队，在固有的行为规律下，在成熟的产品线里，或者层次分明的复杂组织结构里如何做好向敏捷的转变呢？似乎这种改变给许多人带来希望的同时伴随着一点恐慌？我们有没有可行的策略、方法可以遵循呢？可否让团队又能够发挥在传统开发模式下的力量集中的优势，又能够做到敏捷的随需应变呢？回答是肯定的。
在做转变的实施前，我们需要有心里准备，任何从传统开发到敏捷开发转变不可能一蹴而就，自然也没有人能够将一个传统开发模式下的测试团队一夜之间变成彻底的敏捷。对这些还没有敏捷起来，但仍然以此作为目标的项目团队我们建议循序渐进，基于笔者的亲身体验，提供以下实施的方法请大家参考。
首先我们建议采用迭代的开发模式作为向敏捷的模式转变的起点。很多传统开发模式或者基本上还是瀑布式的开发，或者是周期性的瀑布式开发，这些都不是敏捷的迭代。敏捷的迭代是高度的迭代，不是瀑布开发的不断累加。换句话说，传统开发是传递性的工作，一方完成，另一方接手。而敏捷活动的迭代行为更强调尽早开展各项活动，从迭代的一开始就协同工作，共同实现团队迭代的目标。而一旦抵达迭代的周期中最后一个工作日，此迭代宣布退出。
当完成了向迭代活动的转变完成后，接着，我们开始寻找项目过程、管理、执行中最紧要的问题，并使用敏捷开发中的最佳实践来一一解决这些实际问题。也许，一开始这个过程是很缓慢，而且很难做到一步成功，但是必须通过不屑的努力和足够的耐心，慢慢转变团队的固有思维方式，并最终努力获得团队对改进后结果的统一认可。而一个问题被解决，或者不再是项目中最严峻的问题时，我们应该开始寻找下一个待解决的困难了。重复这个过程直至成功的将团队中有悖于敏捷原则和实践的过程和方法调整过来，同时将正确的思路和方法带给团队。
在最近的几次与其他敏捷测试团队的讨论中，我们同时了解到许多软件开发项目中的测试团队遇到过类似的一些问题，如开发团队没有做单元测试或做得太少，继而在开发过程中的遗留了大量质量缺陷和频繁的回归现象。这使得测试压力急剧加大，测试过程严重受阻，甚至影响到整个迭代的退出和项目的输出结果等等。又或者传统的开发中的测试团队因为很少有条件去认识客户，了解和实际用户相关业务需求。测试脚本和用例的设计只是基于开发人员撰写的功能说明。因此，难以做到对需求变化做出快速反应。经过讨论，我们推荐给对这样的团队如下参考方案。
首先开始采用测试驱动开发 (Test Driven)。
开发人员首先要善于使用测试驱动开发方法写每一行代码，先写测试脚本后写代码，并反复使用单元测试脚本验证所写代码的正确性。
列出需求
为需求撰写一个单元测试脚本
执行测试确信测试结果是失败的
然后，写上仅仅足够的代码以使得先前的测试可以通过
当所有测试通过了，便可以开始写下一个测试脚本
针对需求有效的实现所有测试脚本
另外，当需要代码重构时候，也应该先重构单元测试脚本，在改动代买之前同样先改写测试脚本。
尽早的开始测试，开始系统测试，不要等待到功能完全做好才开始。
了解计划中的待实现的功能，了解其权重分配，设计系统测试和功能测试用例。测试执行的一开始可以是针对部分功能的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分（组件，构件）做完整的安全测试，性能测试，压力测试，并发测试，全球化测试等。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。
然后策略性的进行自动化测试，设计并开发可以用于日后回归测试（Regression）和用户接收测试（Acceptance Test）的自动化脚本，持续维护与开发这些脚本。自动化测试为团队带来的是长期效益，自动化测试的开发也应该首先选择部分测试对象，例如，API，框架等比较稳定和关键的功能做功能测试的自动化；对产品的性能指标，压力测试也要较早的制定自动化测试的计划。
最后，要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。
而且，要做好敏捷测试，我们需要转变测试等待开发的思想，测试人员需要了解开发，需要读懂代码，才能够更好的帮助开发人员分析和分离复杂问题。有甚者，测试人员可以成为开发人员的后备力量。当团队中需要更多的人撰写代码时，测试人员应该勇当其职。
团队组织的变化
敏捷的测试团队在实战中常常不需要其他人帮助做计划和分配任务，成员在各自的敏捷团队中自我管理模式下制定可行的计划与自行分配任务，并直接报告给项目的管理层。只有在特定的集中测试模式下才需要通过测试团队的领导者形成整体的测试计划和报告。因此，敏捷测试团队是一支即能独当一面又能够默契合作的适应力，灵活性很强的团队，这正是团队自我管理的核心思想。因此，转变到敏捷开发模式，传统组织结构也需要经历一次调整，调整围绕两个主题，第一，团队充分授权各成员，对于如何交付结果，成员可以保持较大的灵活性，但成员自身需要对这些结果负责。第二，团队领导者需要协调团队成员对资源的共享和竞争，当敏捷团队各自计划和实施其工作时，团队领导者应该帮助团队成员建立比较清晰的责任界限，团队角色划分，协调团队中各种资源的使用，鼓励团队之间的相互交流和协作，帮助培养团队成员对其所属的自主决策能力。
图 1. 传统组织结构转变为敏捷组织
团队需要建立良好的鼓励机制，这里我没有用激励一词，因为我们认为团队成员已经饱受着来自自身、外部的各种压力和刺激。团队要在这种高压的环境里保持高昂的斗志，一定需要更多的鼓励和关心团队中的每一个成员。并且，通过鼓励团队的创新，尊重团队的多样性，培育各种想法，使得团队自身更加善于思考，高效的达到预期目标。相反，处处压制和迫使团队成员按自己的方式做事情，将使得团队的活力降低，生产率下降。
当然，在这里我们更要需要关注团队的核心人物——团队的领导者，在敏捷团队中，团队的领导者更多是一个实战经验丰富，能够独立完成自身所承担的敏捷项目组工作外，也能够辅导和帮助其他团队成员做好各项工作的重要角色。优秀的团队领导者往往会成为主导项目成败的关键，然而一个不能够很好转变固有思路，自身都不能做好敏捷测试所涉及的工作的所谓的领导者是自然没有能力去完成培养和发展自我组织，自我管理的团队的艰巨任务的了。很显然，越来越多的传统团队的领导者具备了领导者和管理者的双重身份，然而，敏捷的团队中，并不需要这样的双重身份。而团队民主，平等的建立才是团队领导者和团队所有人需要尽力保护和推崇的原则。而敏捷团队中的领导者更多是团队的领军人物，他 ( 她 ) 明确下一步要做的事情，勇于挑战新事物，不怕承担责任，具备正值，公正，协调能力强的特点，更重要的是他（她）是团队中的模范，他 ( 她 ) 的影响力，正是领导力的源泉。因此，如果传统测试团队需要发展成为敏捷测试团队，那么团队领导者的职责和形态的转变也必然十分重要。
最后，团队用人和人才配置仍然需要慎重考虑，换句话说，就是因人而异的安排工作。举个例子，在一个分布式的敏捷团队中，集中在中国的测试团队需要划分出几只小团队分别服务于不同的敏捷开发团队，其中有美国、德国、日本三个实验室参与到这个项目中来，面对时区差异，项目所需技能差异。我们建议在没有更好的办法的情况下，选择了体力很好的同事在有时差 12 个小时左右的敏捷团队中，将学习能力强的同事放到新技术含量最高的敏捷团队中，代码经验丰富的同事放到做底层架构的敏捷团队中，这样来以达到测试团队的最佳组合与配置。
敏捷测试遇到的哪些问题？
任何方法都不是百分之百正确，部署敏捷原则的测试团队仍然会遇到了许多困难。需要我们勇敢的面对和并痛痛快快的解决他们。这里笔者给出了一些被大家讨论得最多的热点问题，结合实际经验分享一些解决方案，希望可以有所帮助。
时区地域的差异增加了沟通成本
某些著名企业在部署敏捷开发项目时曾不允许将同一项目的开发团队跨地域分离，原因是为了方便团队成员间的，团队间的沟通和交流，降低成本。而在面临外包所带来的巨大利润诱惑下仍然存在许多跨地域，跨时区的敏捷项目团队。部署敏捷开发时的常有人质疑这种方式下的敏捷是否能够真正成功。也不乏听到源于时区地区差异造成的沟通不便而引起的声声抱怨。
图 2. 时区地区差异增加沟通成本
不得不说地域和时区的差异带来了团队沟通的额外的开销，但是恐怕这也是短期内无法改变的事实，在不能改变环境的前提下，我们选择了改变自身。因此，敏捷团队更需要通过各种方法保障沟通的通畅，做到沟通即有效。因为不能实施面对面的讨论，所以为了更好的交流，我们建议采用会议以外的方法，如电话，即时通讯，邮件来弥补时区地区差异的障碍。在我们的深刻体验中，建立起通畅的即时通讯，和信息共享的数据库空间是项目成功的不可或缺的因素。而团队成员之间经常的感情交流，更能够促进团队间的相互信任和润滑之间的摩擦从而加快沟通。
除了鼓励团队的自我管理，自我建设外，在初期帮助分布在不同地域的团队间建立一些官方交流通道是非常有帮助的。例如，我们建议对这些跨区域、分布式的敏捷项目在项目初期就找出能够被双方甚至是多方接受的稳定的定期的会议时间和其他有效沟通方式，也建议建立起活动经费经常用于组织团队之间的各项增进感情交流的活动。另外，帮助团队的成员依据团队整体工作时间的最佳的安排和改变个人的正常工作时间的也或许成为必要的选择之一。
不会休息的团队
敏捷开发中因为是高度迭代，周期短，任务紧，而自身的积极工作态度更使得团队成员不愿意休假并长时间的高度紧张的工作，甚至频繁的加班加点。在我们的项目中，中国人更加表现出积极的一面。在过去的一段时间里，中国软件开发实验室的很多人中，当然也包括我们，倾向于牺牲个人时间来满足分配更多工作的要求。从感情上我佩服这种孜孜不倦，无私的工作态度，更惊讶这样的旺盛的精力。然而，很快我们发现我们错了。
这样长时间缺乏休息的团队成员工作效率，工作状态的在四五个月后发生了变化，也突然发现他们一个接一个的开始变得萎靡不振，身体健康状态也随之变坏，以致后来很多人甚至卧病在床了。而这时恰恰又是项目中后期产品开发的重要时期，项目因此承受很大风险。
不会休息的团队是不健康的团队。其实，项目往往不是短期行为，通常一个产品的发布需要经历半年以上的不懈努力和投入，而长时间的超负荷运转会使得工作效率和员工身体透支甚至可能导致难以控制的严重后果。所以，如果你的项目还要长期发展，应该帮助团队认识到轻松的团队氛围，张弛有度的工作安排是保障项目最终按时交付的重要因素。
而造成团队不能休息和压力过大的原因，恐怕也是团队自己，为什么这样说呢？原因是敏捷开发团队在计划每一个迭代任务时，许多团队成员对任务量和计划外突发情况估计不足，导致一开始就承诺了过多的项目任务。因此，团队成员除了加强对这场耐力赛跑的认知，和建立正确的计划外，敏捷团队的管理者，有义务和责任帮助各个团队建立起适量的工作计划，动态调整团队的工作任务，以保障整体的稳步前进。关注团队压力承受能力的提高和合理分配团队的工作计划，时间，从长远看来，对团队成员的工作效率和团队的工作绩效的提高具有非常重要的作用。
团队间的协作
越大型的项目，敏捷团队的体积可能越大，迭代的次数越多，产品的架构也更容易产生变化，设计的复杂度也更大。因而，我们需要更加重视产品架构建设，代码重构策略和加强团队间的协作。
最好的设计来自团队而不是某个人，无论是代码还是架构设计还是测试方案都很大程度的依赖于团队的共同承担。而实际项目经验告诉我们，敏捷模式下，往往因为各个团队具有较为独立的活动能力和决策力，团队成员通常更关注所属团队的责任范围内工作，无论是开发人员还是测试人员都潜意识的将依赖于其他团队开发和测试的工作放到靠后的开发周期，寄希望于所有需要的前提和依赖条件最终一定得到解决，而那时后再开始这部分工作也不迟。因此，这种弱势的团队协作成为项目进度不能保障的罪魁祸首。
在我们项目中，也曾经因为某些组件间接口定义时没有做好统一规划，以致产品整合阶段测试和开发进展非常缓慢，回归现象频繁出现，团队的士气受到了极大的伤害。因此作为敏捷团队，特别是敏捷测试团队应该更早的暴露接口缺陷，来设计适量的测试用例覆盖这些耦合部分的活动将为产品的整合带来更小的风险。帮助开发人员尽早认识到其后果的严重性，项目将最终受益。而敏捷原则中提到的不断的整合的思想正是我们克服这个困难的最佳实践。
除了项目管理层通过干预手段解决这部分问题外，鼓励团队成员主动承担额外的工作也是做好协调团队间工作，降低总体风险的最佳途径。
结束语
在这份共分三部分的系列文章中，笔者介绍了如何理解敏捷，敏捷测试，以及分析了笔者亲身经历的一个成功的敏捷测试案例；并基于敏捷开发原则，拟出了一套可供大家借鉴的敏捷测试原则和方法。
本系列的最后一篇文章介绍了传统测试团队向敏捷测试转变的条件和方法。并分享笔者在敏捷测试的实践过程中遇到过的几类问题和解决这些问题的主要途径。
而这里，我们应该指出并不是只有敏捷了，你才能将项目做成功。敏捷项目要有诸多条件和良好的环境去培养，例如“优秀的敏捷主义者”，“民主的组织管理制度”，“灵活的产品体系”和“创新的思维”。因而，不是所有的项目都能够，或者有必要转向敏捷测试，敏捷开发。敏捷测试也不是万能解药。
TAG:
