第一部分：敏捷的实质
敏捷开发有益于个人发展
就测试而言，测试人员就是好比一辆跑车里的唯一的驾驶员，项目就好比这辆跑车，测试人员需要及时修正行驶方向的偏差，确保这辆车在正确的道路上稳步前行。如果，测试人员没有具备足够的责任心和领导力，只是人云亦云，恐怕这种测试要与不要没什么分别，敏捷项目的质量也更让人担忧，而敏捷也就失去了原有的意义。因此，作为唯一的测试人员，他（她）将拥有对测试的所有权，计划、设计并且执行所有的测试工作。而也因为拥有了更多的主人翁精神，积极的工作热情，测试人员勇敢的面对工作中的各种挑战，学习新的知识和努力培养自己的工作技能。敏捷无疑对个人发展产生了很大的推动作用。
敏捷团队中的每个人，需定时和团队的其他成员坐下来看看团队的整体进度，计划下一步工作，并一起探讨所遭遇问题的解决方案。也需适时的寻求团队中其他成员的帮助解决时下紧要的问题。通过频繁的合作与沟通，个人的协作能力、沟通能力也得到了较大的提高。
敏捷开发培养了个人的协作能力
与传统开发不同，敏捷开发更加侧重以人为本，发挥人的积极性，以此提高团队的工作效率。真正实现以结果为导向的职场守则。作为团队的一份子，无论是测试、开发人员，还是设计人员，他们都将为团队成败担当不可或缺的责任。团队是高度协作的团队，个人除了做好本职工作外，敏捷开发模式要求个人能够了解和争取更多的扩展性的工作，也能帮助团队其他成员解决他们的遇到的各种独特问题，以加快实现团队的统一目标，即在更少的时间里生产出能够推向市场的可靠产品。
这里再次提及高度协作，笔者认为高度的团队协作主要表现为以下特点：
- 团队成员积极分享经验，知识，自我培养所需技能和自我成长；
- 团队成员相互帮助，愿意成为他人后备队员，随时做好准备投入新的战斗，因而保障了团队的高昂士气和强大的生命力。
- 任何决策是团队共同的决策，工作是团队共同的工作，团队工作的最后成果因而也是来自团队中每个人的辛勤培养和贡献。而团队的失败更是整个团队的失败，绝不会是某个人的单方面的过失。这种荣辱与共，共生共息的信念将让团队的力量超过团队各个力量之和。同时，项目团队的工作效率在团队成员技能的提升和信念的巩固中不断提高。
敏捷开发锻炼了个人沟通能力
我们把团队看做一个高度协作整体的同时，不可忽视的是团队内部仍存在的各种矛盾，对这些问题的听之任之将破坏团队的凝聚力、生产力。这中间反映出来的很多问题不是敏捷方式独有，但团队成员因为敏捷，学会了自己解决各种问题。而相应的沟通能力也随着问题的解决得到很大幅度的提高。
在过去的项目经验中，我们不难发现种种人与人之间矛盾的产生。而经典的矛盾论也让我们不得不的接受，矛盾是永远存在的，但这并没有什么可怕。而是一旦我们发现了矛盾的存在，就要迅速找到解决办法，这也是团队的相当重要的工作。尤其是在团队组建初期，团队开始采纳新开发模式时，锻炼团队解决如下矛盾的工作非常重要：
- 测试人员是质量的工程师，开发人员是产品的缔造者，在对质量标准的认同上常有不一致（当然，传统开发也会产生）；
-
- UCD 的设计实时反应用户需要，但有时不能顾及代码的可实现性；
- 开发人员而却更喜欢用想当然的理解，和习惯的方式填写代码，甚至主观的抵制接受新设计思想和拒绝新类型缺陷的修复，因此与团队的整体目标、出发点产生分歧；
- 从整个项目组织结构看来，敏捷团队之间（一个项目通常有多个敏捷团队组成，各个团队有自己的侧重点）存在设计，开发的不一致性，这使得产品在整合阶段产生额外的成本。
正如前面所论述，矛盾总是有能够解决的途径，敏捷项目的组织中用管理方式去干预是一种直接、快速的方式，而今天敏捷方法论者们更加推崇的是鼓励团队内部进行很好的交流和沟通后自行解决。也正是通过不断加强团队间和团队内部的相互理解，不但矛盾得到很好的解决（解铃还须系铃人嘛），个人的交流和沟通技能也得到了进一步提高。
敏捷开发培养了个人的创新意识
创新能够为企业带来新发展契机，创造新价值，因此，创新对于企业还是个人而言都非常之重要。不断培养员工的创新能力、鼓励创新活动也是几乎所有企业的人才培养战略之一。而敏捷开发恰恰就是要打破传统的模式，形成全新的敏捷开发、敏捷测试方法、实践和过程，并鼓励团队采用新技术和技术创新。因此，团队的每个人需要能够创造性的工作，并乐于接受新事物，通过不断的改进、突破过时的做法，努力提高团队的工作效率，来适应产品的增量发展需要。
而也因为敏捷开发模式对于很多团队仍很陌生，在运用敏捷开发的过程中我们会遭遇许多新挑战、新困难。如何处理这些问题，解决方案本身就是无以借鉴的，自主创新才是唯一出路。
举个例子，敏捷项目初期，产品停留在原型论证和底层架构初步设计中，产品功能不多，复杂度较小，一般的手动测试就可以将质量保障做好。产品的中后期，因不断有新需求、新功能的加入，产品复杂度增大。团队倘若仍仅凭固有的手动测试方式来覆盖产品的各个功能、非功能点需求只恐怕是力不从心了。因此，考虑用自动化测试来提高团队工作效率是可取的方法之一。但是，当产品发展到中后期，也没有富余的资源可以被抽取出来做自动化测试了。即使现招聘新人，也因为新人对产品不了解，只怕自动化测试的效果也未如人愿。那我们是否应该在开发活动的初期就尝试自动化测试的设计、并自动化一部分功能测试呢？也未然，因为在产品开发初期，产品的功能和界面的变动会比较大，自动化测试收入产出比异常低。因此，何时、何地、如何设计、运用自动化测试来帮助降低人力成本，提高测试效率是需要我们大胆创新的。
敏捷方法的共性
虽然各种敏捷方法的名称、所需环境、适合的团队有很大差异，但是他们拥有相似、相同的以下几大特点：
无论是多么明智，多么正确的决定，也有可能在日后发生改变。因此，团队要能够充分理解我们的利益干系人（Stakeholder）和客户代表为什么经常提出新的需求和设计要求，一句话，就是心中有数“唯一不变的是变化”。团队更要信任 利益干系人（Stakeholder）做出的每次决定和需求的调整都是将产品开发推向更正确的发展方向，新变化将进一步降低风险，实现团队最大化利益，理解这是适应市场变化的必然行为。
而在接受变化的同时，我们应该积极的向 利益干系人（Stakeholder）和客户代表反映实现活动中暴露出来的可能的设计缺陷和错误。在实际工作中，团队成员应该用优先级制度来划分事情和目标先后顺序，在迭代周期内对于还没有最终决定的设计方案可以予以后来实现、测试，不用急于投入资源展开全面的开发、测试活动。这样一来，开发测试团队也会人员也将更加适应，真正拥抱变化。
- 客户的参与（With Customer Representative on site）
首先谁是客户（Customer），客户代表（Customer Representative） 呢？利益干系人（Stakeholder），或者我们可以理解为我们的客户（Customer），产品的最终使用者（End user），内部使用者（Insider），商业伙伴（Business Partner）。利益干系人（Stakeholder）作为团队中最了解业务（Business）的人物将帮助开发团队的快速达到目标和做出适时决策。开发团队拥有很好的技术但在业务（Business）方面他们需要 利益干系人（Stakeholder）的帮助。而通常在敏捷的开发项目中，团队中的任何一个人若需要帮助时，只要简单的邀请大家参加一个 15 分钟会议，或一封邮件、一个电话便可以解决。
但是，如果利益干系人（Stakeholder）各执一词怎么办呢？为解决这个问题，将 Product Owner 引入到讨论中来，作为 Product Owner 他可以作为是 利益干系人（Stakeholder）的代表，能够在分歧中做最后抉择。因此，通过这样的客户代表的参与，团队更好的了解了所做事情的价值和意义，其工作效率也因而得到很大提高。
利益干系人（Stakeholder）能够帮助团队中的每一个人更好，更快的完成了工作，他们的直接参与成为了敏捷开发、敏捷测试的重要前提。
- 较少的文档（With less documents）
敏捷开发更重视生产出可用的产品而不是详细文档。而时常有发觉文档又是无论敏捷还是传统开发、测试不可或缺的一部分。笔者认为，传统开发的文档在敏捷开发里仍有大用，只是原来十来页的内容精炼到现在的一页半页。
敏捷主义者相信文档不是最佳的沟通方式，他们鼓励通畅的交流和沟通，要求避免和减少陈词滥调和空头支票。尤其是复杂的文档说明只是增加了沟通成本，因而敏捷开发、测试的文档不需要长篇累读，需要的是简洁，清晰。任何一段清楚的文字，甚至一张图片，照片，一封记录着会议记录的邮件都是我们认可的敏捷文档。因为是无论是通过文字板书的文件还是其他的沟通方式和载体都是为了帮助团队进行更高效的交流和沟通。只有团队保持着沟通上、理解上的一致后才能够充分发挥出团队最佳战斗力。但凡这是帮助团队有效沟通的方式，敏捷开发是不会放弃的。
- 最大化的生产力（Maximize Productivity）
敏捷开发模式要最大化的提高团队的工作效率。无论是依靠剪除冗余的文档工作，还是提供民主的、通畅的沟通平台都是为了帮助团队能够集中有限的精力处理有意义的问题。据调查，通常人会在两个、多个任务并行的情况下产生出出最高工作效率。而敏捷也恰恰使用了各种方法得到团队的最大生产力。
敏捷开发的 Scrum 模式，要求在计划阶段，团队成员主动定制迭代周期的所有工作任务，因此，本身从团队开始迭代活动的那时起，已经在在多重工作的压力下紧张工作了。而在日常的迭代生产活动里，各个成员需要当众简单汇报当天的工作进度和承诺下一个 24 小时的工作计划。因此，通过增加敏捷人员的工作的透明度，无形之中，团队成员的生产力进一步得到提高。
- 测试驱动开发（Test Driven Development）
测试驱动开发，是让开发人员在编写功能代码之前，根据对需求的理解先设计和编写单元测试代码。先思考如何对将要实现的功能进行验证，再考虑功能的实现。然后迭代的增加新功能的单元测试和功能代码编写，直到完成全部功能的开发。
- 自动化冗余工作（Automate the redundant work）
将团队成员从冗余的劳动中解放出来，无论是自动化的测试还是自动化工具的开发只要能够节约成本都是敏捷开发、敏捷测试的目标。
敏捷团队是一支民主的团队，团队关系是平行的，每个团队成员能够平等的参与讨论，决策。传统开发的垂直的官僚机构在敏捷开发中已是过时的。
敏捷团队的决定权交有团队自己，决定是团队统一制定。无论是产品设计方案还是产品的功能实现都是的最佳结果。团队脱离了任何一个成员的工作都是不完整的，所以我们应当足够尊重其他成员的劳动果实和表达对其他成员的充分信任。尊重团队，尊重团队中的每一个成员都是敏捷开发的原则之一。
你敏捷了吗？
- 项目中有利益干系人（Stakeholder）的参与
- 团队拥有并且可随时执行的回归测试
- 关注产品自身而不是冗余的文档
- 项目开发拥有严格的源码管理、版本控制
- 开发能够积极面对和响应项目需求变化
- 团队作为整体直接担负项目责任
- 能够自动化重复性的活动
第二部分：方法与实践
敏捷测试的实质
测试不仅仅是测试软件本身，还包括软件测试的过程和模式。产品发布后才发现很多问题，很可能是软件开发过程出了问题。因此测试除了需要确保软件的质量，即软件做了正确的事情，以及软件做了应该做的事情以外，敏捷的测试团队还要保证整个软件开发过程是正确的。
敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。敏捷测试人员因而需要在活动中关注产品需求，产品设计，解读源代码；在独立完成各项测试计划、测试执行工作的同时，敏捷测试人员需要参与几乎所有的团队讨论，团队决策。作为一名优秀的敏捷测试人员，他（她）需要在有限的时间内完成更多的测试的准备和执行，并富有极强的责任心和领导力。更重要的是，优秀的测试人员需要能够扩展开来做更多的与测试或许无关，但与团队共同目标直接相关的工作。他（她）将帮助团队其他成员解决困难、帮助实现其预期目标，发扬高度协作精神以帮助团队的最终获取成功。需要指出的是，团队的高度协作既需要团队成员的勇敢，更需要团队成员的主动配合和帮助。对于测试人员如此，对于开发、设计人员，其他成员也是如此。
敏捷测试的方法与实践
- 敏捷团队组织构成，敏捷测试团队的任务和使命；
- 敏捷开发团队以测试为驱动的开发方式——测试驱动开发，这是种独特的测试？还是开发？
- 递增型的迭代测试，它首先是对敏捷测试过程活动和生命周期模型的介绍，通过学习经典的敏捷增量测试模型，我们将敏捷测试的各类活动有机的组合到了一起。在此之上，对定制后的独特敏捷增量测试模型的分析和理解，帮助我们理解测试活动的规划和管理；
- 以及需要特别关注的递增型迭代测试的关键活动之一——“静态测试”；这也是笔者认为的最高难度、最具影响力的敏捷测试活动。它将测试团队最早的引入产品开发环节，测试人员以第一用户的角度判断设计的有效性，此活动较早的暴露了设计缺陷、避免了团队对目标的不一致理解等，是测试活动中最有创造性价值的部分；
- 最后，笔者将谈谈测试活动中的测试计划和管理，即关于测试任务估计，测试活动计划，各个重要测试活动时间分配与安排的介绍。
然而，敏捷测试不是一蹴而就的，做到真正的敏捷，无论是从传统测试模式向敏捷测试的过渡，还是组建全新的团队都是需要循序渐进的，同时也需要团队成员的通力合作和不断的实践来完善敏捷测试的实践原则和方法。
敏捷团队
笔者曾共事的整支产品开发团队被划分成 4 个相对独立的敏捷开发队伍，而每支队伍拥有相同配置的 7 名成员，他们分别具有不同的职能属性。
每支敏捷队伍组成成员角色包括：
1 名 UCD（User Centered Designer），主要负责产品的主要设计，其工作主要包括界面设计、用户的用例设计等等；
1 名 Visual Designer，主要负责产品界面的色彩搭配、控件的外观设计和 UCD 界面设计方案的初步实现和美化；
1 名 Information Developer，主要负责产品中信息的编辑和重要文档的撰写工作；
3 名开发人员，主要负责产品的实现；
1 名 Tester，主要负责产品质量的保障。
4 支敏捷的队伍拥有相同的 SCRUM MASTER STAKEHOLDER。通常会在同一时间进入一个迭代周期，制定各自的敏捷计划，并在同一时间退出，发布各自功能实现。而 4 支队伍的劳动果实被集成到一起就形成了可发布的产品了。
因为敏捷团队中只有 1 名测试人员，因此需要一臂承担测试策略的制定，测试计划，测试脚本，测试用例设计以及测试的执行，帮助团队发现潜在问题，并协助解决问题的工作。敏捷团队的敏捷原则也是测试人员敏捷活动的规范，测试也需要拥有和团队的良好沟通，高度迭代的活动和不断的获得 STAKEHOLDER 的反馈。那团队的结构与敏捷本身有什么直接关系呢？与敏捷测试又有多少关联呢？
敏捷原则告诉我们敏捷团队是高度协同、民主和平等的团队，为了让团队中每个人充分高效的工作。相同职能下的组员至多不好超过 3 名，最佳配置也是不同职能下配置 1 个人头。因此、在这样一个小型、平行的组织结构里，沟通更加易于建立，沟通复杂度也相对较低，相比 17、20 人的团队组织，沟通的代价也小很多。相反，很难想象在一个敏捷团队中会拥有诸多不同风格的执行者，决策者将是个怎样的混乱情况。
此外，经历过敏捷测试的体验，我们发现一个单一的敏捷团队最好保持较小的“尺寸”。这是因为拥有很多测试人员的敏捷团队通常不但需要更大的实际工作量来匹配庞大的机体而导致团队任务量更巨大，更复杂，失去自我管理的信心，而每个测试人员也将要花费大量精力和时间投入到内部沟通，和可能因为内部缺乏一致而导致的更加频繁的反复沟通中。
每名敏捷的测试人员需要和其他敏捷团队成员保持频繁而必要的沟通以保证对目标，需求、设计的充分正确的理解，对需求变化能够迅速的做出反应。另外，还需要与职能队伍中的其他测试成员保持一致性。如此一来，沟通代价激增了，它将占到测试人员的工作中的较大比例。而这种内部沟通、协调，却不能定义为敏捷的 Backlog 项目来计入团队整体的工作输出。因此，整体的测试效率并不一定随着人力资源的投入而递增。非但没有实现敏捷原则，而恐怕因为团队的组织结构变得更加庞杂。所谓的“自我管理、自我发展”的团队只能因而依靠传统的管理和规划了。笔者认为，除了因为特殊阶段，特殊时期，敏捷团队需要“聚合”更多资源来一并解决存在的高优先级的体力型问题外，敏捷的团队应该尽量保持着较小的“尺寸”。
果真项目投入了很多的人力资源，无论设计还是实现、测试团队拥有较大的人数，那么我们应该考虑将这样的团队可以分得更小些，工作量也相应分得更精细些，直至接近我们建议的最佳组合。至少我们认为要做好敏捷测试，就要确保敏捷团队中的每一个职能拥有足够清晰的职责范围和一定程度下自由空间和在这个空间内的充分授权。因此，但从人数和职能构成上，敏捷团队的构成一定是不可忽略的重点。
正像我们前面提到的，确认软件开发过程的正确性也尤为重要，因此作为敏捷的测试人员，更要了解敏捷的过程，比如说，测试人员需要帮助 UCD 和开发人员确定需求的可行性，测试人员要督促开发人员及时发布 build，以保障迭代结果最终能够在通过足够的测试后成功发布等。在 build 发布后，测试人员要首先验证当前迭代的任务是否已经完成，其次才是验证产品功能的正确性。也为了能够在日后重复性和体力型劳动中解放出宝贵的时间去覆盖测试更加紧要的内容，如可用性，全球化等，测试人员需要自动化一部分测试，创新的、灵活的工作。
敏捷团队是自我管理的团队，高度协作的团队，质量目标即是测试团队也是整个开发团队追求的目标，因此开发团队应将做好单元测试，设计团队将帮助测试团队设计好测试用例作为计划内的一项工作。这里我们推广、建议开发人员采用、普及测试驱动开发模式。
测试驱动开发
测试驱动开发表现出迭代开发的最核心的就是开发人员自己能够第一时间确认其需求得到了正确实现，而当单元测试覆盖了更多的内容，代码质量也将得到提高。测试驱动开发的指导思想就是让开发人员在编写功能代码之前，先根据需求编写测试代码。先思考如何对将要实现的功能进行验证，并完成单元测试脚本的编写，然后编写足够，仅仅足够的功能代码满足这些测试用例，直至通过测试。按照这个方法，递增的在迭代中增加新功能的单元测试和功能代码编写，直到完成全部功能的开发。
在单元测试活动中，测试人员也被鼓励参与到单元测试的设计中来，不但可以帮助开发人员构思出更多的单元测试用例来扩大单元测试的覆盖率，还可通过学习如何使用单元测试，如何复用单元测试用例到回归测试和功能测试，以达到最大化利用有效的资源（如下图）和节约成本的作用。同时，在回归测试和用户接收测试（User Acceptance Test）中如能将单元测试脚本有机的关联起来，并自动化其执行，更能够进一步提高测试的成效并降低测试成本。
单元测试脚本因随需求、设计的变化随时更新。需要开发人员站在全局的立场，开发始终坚持先修改测试脚本，再修改产品原代码。此时，也建议测试人员参与单元测试脚本的改进，帮助开发人员合理的变更单元测试脚本，同时着手修改测试计划和测试策略。
静态测试
一个好的测试人员能够第一时间找到需求分析、设计中的模棱两可，遗漏，错误的地方，能够促进团队前期工作的高效完成，将很大程度降低将来产品的质量缺陷的数量，积极影响了敏捷开发的最终输出。这部分工作是测试团队，开发、设计团队最默契合作的阶段，交流非常频繁，正是通过积极的沟通和及时的修正与团队目标“误差”使得团队更加明确其方向，更有凝聚力和也得以发挥了团队的最佳战斗力。在笔者的项目经历中，往往这个阶段会需要一个迭代周期 1/4 左右的时间。这同时也说明了静态测试在敏捷测试类型中的重要性。
在敏捷开发过程的静态测试即项目迭代开发前期测试人员的最主要工作。值得再次强调的是，在这段时期测试人员的工作重心是认真了解需求和用例设计，并针对设计的可行性，可用性进行验证，确认设计是对需求的准确实现，最佳实现。
测试人员应该领导团队帮助明确出用例更多的细节。比如，在一次设计用例讨论中，设计者提出“我需要一个 Overlayer”。那么测试人员应该要问：“如何打开这样一个 Overlayer，如何关闭？”“这个 Overlayer 需要多大平面尺寸，是否支持调整，是否支持对屏幕大小的自动适应”，“Overlayer 的打开和关闭是否需要有动态渐变的效果？”，“Overlayer 的是否需要滚动条？”，等等。
这个过程能够帮助团队发现早期的设计缺陷，通过发现问题，并定制新的设计方案，团队也通过这个过程，更好的了解了测试的重要性，也摒除了可能存在的对需求的种种“假设”，因而更加明确了团队的目标和方向。这是个非常关键的过程。尤其是对测试人员而言，任何“假设“都是有害的，所以一定需要把不清楚和模棱两可的问题从一开始就理清楚。
敏捷测试的计划与管理
测试用例的撰写和传统测试基本没什么差异，按照已有的模式撰写就好了。笔者的测试团队，使用了 XML 文件格式保存所有测试用例，原因主要是沿用了测试团队原有的习惯，而同时也因为 XML 测试用例能够更好的匹配自动化测试的需要，并且便于更新。测试脚本是自动化测试的产物，敏捷开发周期短，变化多，很难拿到一个稳定的产品再开始做自动化。而自动化脚本的设计自然要避免去测试不稳定部分，开始的迭代周期几乎百废待兴，自动化作用不大，到了中期，笔者的团队自动化测试才稍成气候。
在迭代验收之前团队要通力合作解决各种能够解决的问题，保障 Backlog 的如期完成。这里有一个问题值得再次提出来和大家讨论，或许曾在敏捷项目中的许多人也都遇到了，那就是出现了一些质量缺陷没有来得及在迭代退出前完全解决的现象。那是不是说明测试不能够退出呢？笔者的回答是“不”。迭代的验收时间即是迭代退出时间，也是测试团队必须退出的时间。在实施中，我们将这些来不及解决的质量缺陷分成三类，一类是“希望能够解决”的质量缺陷，这部分未解决质量缺陷将要成为新一轮迭代的“将做事宜”，甚至可能作为新一轮迭代的需求做到 Backlog 里。第二部分是“必须解决”，这部分因为直接关系到最基本，最关键的功能，这样的质量缺陷必须被立刻解决，否则就必须承认本次迭代的失败了。第三部分是“不再重要的” 质量缺陷，这部分质量缺陷可以因为技术的不可实现，对客户产生较小的影响或者考虑到不久因为代码重构，这样的问题不在存在的理由，经过团队和 STAKEHOLDER 的批准可以置成“推迟解决”，待日后解决或者定义到产品的版本说明文档中。
第三部分：向敏捷测试转变
引言
传统测试模式下成长起来的测试团队要如何转向敏捷，从个人和团队的两个层面又要做出那些转变呢？有什么方法和标准衡量敏捷测试团队的绩效？如何帮助团队的每个人规划正确的发展路线？团队在部署敏捷的过程中又会遇到哪些问题呢？本文主体就这些问题展开论述。
有关敏捷测试团队和个人的绩效
“如何看待敏捷测试和对测试人员做绩效考评呢？”——敏捷团队中无论开发还是测试都不是个人的开发和测试，这是团队的工作。一名好的测试人员除了能够做好本职测试工作外，表现为愿意并能够做超出原有范围的工作，能够并愿意帮助团队其他成员解决其他复杂问题，实现团队的共同目标。测试人员能够主动发现并弥补团队中的重要缺失的环节，帮助团队其他成员完成工作任务。
测试团队的职责也从仅仅发现问题的工作中向着眼于整个项目质量保障转变。因此不难得到结论，在敏捷团队中，优秀的测试人员身上有其他成员的影子。在时间紧迫的情况下，他能转变成其他角色，做出更多的创造性的成绩。充分地发挥了个人战斗力，在帮助他人的同时，自信的态度和各项工作中的技能得到增强，自身也可以获得更大发展。
在一次关于敏捷开发、测试经验交流中，我们认为敏捷测试团队更需要其他团队的协助，在设计测试用例时，团队的设计人员应该帮助测试团队设计测试用例，并帮助测试团队做更多的面向客户环境的真实测试。开发团队也要确保开发任务的按时推进，和测试团队保持紧密的合作，在测试任务紧要时，也能够转变其职能帮助测试团队完成测试任务。
测试人员向敏捷转变所需要的技能储备
这引出我们今天要探讨的一个问题，测试人员如何在技能上做好准备以面临敏捷开发的全新挑战。我们认为，一名优秀的敏捷测试人员，需要有较强的学习能力，至少有主动学习的意愿。除了需要了解各种类型测试以及各种测试工具，测试技术外，也需要了解项目中软件设计模式，软件语言，以及项目的程序组织架构以便建立和团队的共同语言空间。
因为敏捷团队是一个高度协作的团队，在这样的团队中工作需要很好的沟通技巧，语言能力和协作能力。
除此之外，团队的每个成员，都应该认真学习并努力寻找适合自己团队的敏捷模式，并沟通以达到团队成员对敏捷开发模式的统一认识，使得团队其他成员对自己工作的充分理解和建立起成员之间的相互信任。
测试人员向敏捷转变所需要的方法
首先我们建议采用迭代的开发模式作为向敏捷的模式转变的起点。很多传统开发模式或者基本上还是瀑布式的开发，或者是周期性的瀑布式开发，这些都不是敏捷的迭代。敏捷的迭代是高度的迭代，不是瀑布开发的不断累加。换句话说，传统开发是传递性的工作，一方完成，另一方接手。而敏捷活动的迭代行为更强调尽早开展各项活动，从迭代的一开始就协同工作，共同实现团队迭代的目标。而一旦抵达迭代的周期中最后一个工作日，此迭代宣布退出。
当完成了向迭代活动的转变完成后，接着，我们开始寻找项目过程、管理、执行中最紧要的问题，并使用敏捷开发中的最佳实践来一一解决这些实际问题。也许，一开始这个过程是很缓慢，而且很难做到一步成功，但是必须通过不屑的努力和足够的耐心，慢慢转变团队的固有思维方式，并最终努力获得团队对改进后结果的统一认可。而一个问题被解决，或者不再是项目中最严峻的问题时，我们应该开始寻找下一个待解决的困难了。重复这个过程直至成功的将团队中有悖于敏捷原则和实践的过程和方法调整过来，同时将正确的思路和方法带给团队。
在最近的几次与其他敏捷测试团队的讨论中，我们同时了解到许多软件开发项目中的测试团队遇到过类似的一些问题，如开发团队没有做单元测试或做得太少，继而在开发过程中的遗留了大量质量缺陷和频繁的回归现象。这使得测试压力急剧加大，测试过程严重受阻，甚至影响到整个迭代的退出和项目的输出结果等等。又或者传统的开发中的测试团队因为很少有条件去认识客户，了解和实际用户相关业务需求。测试脚本和用例的设计只是基于开发人员撰写的功能说明。因此，难以做到对需求变化做出快速反应。经过讨论，我们推荐给对这样的团队如下参考方案。
- 首先开始采用测试驱动开发 (Test Driven)。
开发人员首先要善于使用测试驱动开发方法写每一行代码，先写测试脚本后写代码，并反复使用单元测试脚本验证所写代码的正确性。
- 列出需求
- 为需求撰写一个单元测试脚本
- 执行测试确信测试结果是失败的
- 然后，写上仅仅足够的代码以使得先前的测试可以通过
- 当所有测试通过了，便可以开始写下一个测试脚本
- 针对需求有效的实现所有测试脚本
另外，当需要代码重构时候，也应该先重构单元测试脚本，在改动代买之前同样先改写测试脚本。
- 尽早的开始测试，开始系统测试，不要等待到功能完全做好才开始。
了解计划中的待实现的功能，了解其权重分配，设计系统测试和功能测试用例。测试执行的一开始可以是针对部分功能的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分（组件，构件）做完整的安全测试，性能测试，压力测试，并发测试，全球化测试等。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。
然后策略性的进行自动化测试，设计并开发可以用于日后回归测试（Regression）和用户接收测试（Acceptance Test）的自动化脚本，持续维护与开发这些脚本。自动化测试为团队带来的是长期效益，自动化测试的开发也应该首先选择部分测试对象，例如，API，框架等比较稳定和关键的功能做功能测试的自动化；对产品的性能指标，压力测试也要较早的制定自动化测试的计划。
最后，要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。
而且，要做好敏捷测试，我们需要转变测试等待开发的思想，测试人员需要了解开发，需要读懂代码，才能够更好的帮助开发人员分析和分离复杂问题。有甚者，测试人员可以成为开发人员的后备力量。当团队中需要更多的人撰写代码时，测试人员应该勇当其职。
团队组织的变化
敏捷的测试团队在实战中常常不需要其他人帮助做计划和分配任务，成员在各自的敏捷团队中自我管理模式下制定可行的计划与自行分配任务，并直接报告给项目的管理层。只有在特定的集中测试模式下才需要通过测试团队的领导者形成整体的测试计划和报告。因此，敏捷测试团队是一支即能独当一面又能够默契合作的适应力，灵活性很强的团队，这正是团队自我管理的核心思想。因此，转变到敏捷开发模式，传统组织结构也需要经历一次调整，调整围绕两个主题，第一，团队充分授权各成员，对于如何交付结果，成员可以保持较大的灵活性，但成员自身需要对这些结果负责。第二，团队领导者需要协调团队成员对资源的共享和竞争，当敏捷团队各自计划和实施其工作时，团队领导者应该帮助团队成员建立比较清晰的责任界限，团队角色划分，协调团队中各种资源的使用，鼓励团队之间的相互交流和协作，帮助培养团队成员对其所属的自主决策能力。
团队需要建立良好的鼓励机制，这里我没有用激励一词，因为我们认为团队成员已经饱受着来自自身、外部的各种压力和刺激。团队要在这种高压的环境里保持高昂的斗志，一定需要更多的鼓励和关心团队中的每一个成员。并且，通过鼓励团队的创新，尊重团队的多样性，培育各种想法，使得团队自身更加善于思考，高效的达到预期目标。相反，处处压制和迫使团队成员按自己的方式做事情，将使得团队的活力降低，生产率下降。
当然，在这里我们更要需要关注团队的核心人物——团队的领导者，在敏捷团队中，团队的领导者更多是一个实战经验丰富，能够独立完成自身所承担的敏捷项目组工作外，也能够辅导和帮助其他团队成员做好各项工作的重要角色。优秀的团队领导者往往会成为主导项目成败的关键，然而一个不能够很好转变固有思路，自身都不能做好敏捷测试所涉及的工作的所谓的领导者是自然没有能力去完成培养和发展自我组织，自我管理的团队的艰巨任务的了。很显然，越来越多的传统团队的领导者具备了领导者和管理者的双重身份，然而，敏捷的团队中，并不需要这样的双重身份。而团队民主，平等的建立才是团队领导者和团队所有人需要尽力保护和推崇的原则。而敏捷团队中的领导者更多是团队的领军人物，他 ( 她 ) 明确下一步要做的事情，勇于挑战新事物，不怕承担责任，具备正值，公正，协调能力强的特点，更重要的是他（她）是团队中的模范，他 ( 她 ) 的影响力，正是领导力的源泉。因此，如果传统测试团队需要发展成为敏捷测试团队，那么团队领导者的职责和形态的转变也必然十分重要。
最后，团队用人和人才配置仍然需要慎重考虑，换句话说，就是因人而异的安排工作。举个例子，在一个分布式的敏捷团队中，集中在中国的测试团队需要划分出几只小团队分别服务于不同的敏捷开发团队，其中有美国、德国、日本三个实验室参与到这个项目中来，面对时区差异，项目所需技能差异。我们建议在没有更好的办法的情况下，选择了体力很好的同事在有时差 12 个小时左右的敏捷团队中，将学习能力强的同事放到新技术含量最高的敏捷团队中，代码经验丰富的同事放到做底层架构的敏捷团队中，这样来以达到测试团队的最佳组合与配置。
其它：
由于敏捷开发的流程是不断迭代的过程，所以很多复杂的功能可能会在未来的 Sprint 周期中被优化。对测试人员而言，一个有效的方法是尽量将一些验证基本功能的测试用例作为基本验证测试用例（Basic Verification Test Case）在第一时间实现自动化；而对一些复杂的功能测试用例，可以先采用手工的方法测试，直到在未来 Sprint 周期中该功能达到稳定时候再考虑自动化。
