如果您已经阅读过
敏捷测试系列文章的第一篇，敏捷的实质，您应该已经了解敏捷的定义，了解什么样的团队是敏捷的团队了。而您也可能早已开始思考，什么是敏捷测试的实质？敏捷的测试团队又是如何形成自我管理、自我发展的组织呢？测试团队又是如何安排日常
工作呢？敏捷测试活动与传统测试活动有很大差异吗？为了进一步让您了解如何将敏捷原则运用到活生生的日常测试活动中，我们为您推荐敏捷测试系列文章的第二篇——敏捷测试的实践。
在敏捷活动如火如荼的推广运动中，我们显然无法预知如何在您的特定的复杂环境中您能否最后达成所愿，也无法为您预测出前进道路的分岔口可能唯一的正确的线路，我们却可以为您点起一盏明亮“街灯”，在这迷雾中驱除黑暗。我们将为您提供一个可以借鉴和可供参考的成功的敏捷测试实践案例。我们将逐一向您介绍、分析这个案例中的敏捷团队的组织结构，主要的敏捷测试行为，迭代的测试模型和一套以四周为周期的敏捷测试活动时间表。
请您运用您已具备的敏捷实质、敏捷原则的知识，并结合您的独特项目环境、带着您的问题，与笔者一起再度分析这个案例，希望您最终也能得到满意的答案，并随后开始实施部署敏捷测试。
敏捷测试的实质
测试不仅仅是测试软件本身，还包括软件测试的过程和模式。产品发布后才发现很多问题，很可能是软件开发过程出了问题。因此测试除了需要确保软件的质量，即软件做了正确的事情，以及软件做了应该做的事情以外，敏捷的测试团队还要保证整个软件开发过程是正确的。
敏捷开发的最大特点是高度迭代，有周期性，并且能够及时、持续的响应客户的频繁反馈。敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。敏捷测试人员因而需要在活动中关注产品需求，产品设计，解读源代码；在独立完成各项测试计划、测试执行工作的同时，敏捷测试人员需要参与几乎所有的团队讨论，团队决策。作为一名优秀的敏捷测试人员，他（她）需要在有限的时间内完成更多的测试的准备和执行，并富有极强的责任心和领导力。更重要的是，优秀的测试人员需要能够扩展开来做更多的与测试或许无关，但与团队共同目标直接相关的工作。他（她）将帮助团队其他成员解决困难、帮助实现其预期目标，发扬高度协作精神以帮助团队的最终获取成功。需要指出的是，团队的高度协作既需要团队成员的勇敢，更需要团队成员的主动配合和帮助。对于测试人员如此，对于开发、设计人员，其他成员也是如此。
敏捷测试的方法与实践
是的，敏捷测试也需要高度迭代工作、频繁得到 STAKEHOLDER、客户的反馈，需要动态调整测试计划、测试的执行。并且，敏捷测试人员参与到了更多的敏捷生产活动中，积极的影响了团队做出的决定和计划。
是的，“人”才是敏捷的实体，敏捷测试也是以人为本的。不难理解，“敏捷”的一切都围绕着人展开，如敏捷鼓励直接，平行的沟通；敏捷需要持续的客户反馈以及敏捷活动的设计，方案和决策需要团队协同制定等等，敏捷测试需要一支非同寻常的团队，不同于以往传统开发模式下的团队结构。关于敏捷团队、敏捷测试团队的组成和介绍，将是我们讲述敏捷测试实践的第一步。
“人”是重心，方法、策略是辅。为了适应不同的团队结构，不同的项目环境，敏捷项目和敏捷活动的实践也应该因“人”而异，但是，并不是说可以天马行空，我行我素。一旦脱离了正确的敏捷方法、和敏捷原则的指导，我们的敏捷活动就好比摸黑前行了。
这正是我们需要学习前辈和敏捷主义大师们的经验意义所在了，笔者在过去的实践中受益颇多的也正是前人的实践经验和方法。因此，学习前人的经验和方法，并运用这些最佳实践来帮助敏捷开发团队，甚至是传统团队来解决时下重要的问题是十分有意义的事情。笔者不敢妄自尊大将自己的一般实践纳入经典方法范畴，但经历了两年的研究和改进，笔者提出的敏捷测试的原则也得到了业内同僚和“大师”的普遍认可。经过多次和其他项目团队的经验交流，我们也不断的改进着我们的原则、方法。因此，笔者要非常感谢参与讨论的同僚们，没有你们的热情参与，也不会有今天的笔者信心百倍的执笔了。正如笔者在借鉴了前人的成功案例中的经验和方法之后定制了符合项目需求的测试原则一样，相信，读者们在阅读了笔者的敏捷测试原则和方法后，同样也会有所收获。而对笔者经历的敏捷实践活动中的方法和测试模型的讲解将成为我们讲述敏捷实践的第二步，也是本文的重点。
综上所述，笔者将运用本文的主要篇幅为大家讲解这个敏捷实践。它们是：
敏捷团队组织构成，敏捷测试团队的任务和使命；
敏捷开发团队以测试为驱动的开发方式——测试驱动开发，这是种独特的测试？还是开发？
递增型的迭代测试，它首先是对敏捷测试过程活动和生命周期模型的介绍，通过学习经典的敏捷增量测试模型，我们将敏捷测试的各类活动有机的组合到了一起。在此之上，对定制后的独特敏捷增量测试模型的分析和理解，帮助我们理解测试活动的规划和管理；
以及需要特别关注的递增型迭代测试的关键活动之一——“静态测试”；这也是笔者认为的最高难度、最具影响力的敏捷测试活动。它将测试团队最早的引入产品开发环节，测试人员以第一用户的角度判断设计的有效性，此活动较早的暴露了设计缺陷、避免了团队对目标的不一致理解等，是测试活动中最有创造性价值的部分；
最后，笔者将谈谈测试活动中的测试计划和管理，即关于测试任务估计，测试活动计划，各个重要测试活动时间分配与安排的介绍。
然而，敏捷测试不是一蹴而就的，做到真正的敏捷，无论是从传统测试模式向敏捷测试的过渡，还是组建全新的团队都是需要循序渐进的，同时也需要团队成员的通力合作和不断的实践来完善敏捷测试的实践原则和方法。
敏捷团队
考虑到敏捷团队的组织结构，让我们以笔者亲身经历的项目为例来说明。笔者曾共事的整支产品开发团队被划分成 4 个相对独立的敏捷开发队伍，而每支队伍拥有相同配置的 7 名成员，他们分别具有不同的职能属性。如图 1 所示，每支敏捷队伍组成成员角色包括 1 名 UCD（User Centered Designer），主要负责产品的主要设计，其工作主要包括界面设计、用户的用例设计等等； 1 名 Visual Designer，主要负责产品界面的色彩搭配、控件的外观设计和 UCD 界面设计方案的初步实现和美化；1 名 Information Developer，主要负责产品中信息的编辑和重要文档的撰写工作； 3 名开发人员，主要负责产品的实现。和 1 名 QA，主要负责产品质量的保障。（更多的我们将 QA 定义为具有相比于测试人员拥有更多责任的一个职能，在本文中，为了简便起见，我们仍称之测试人员）。4 支敏捷的队伍拥有相同的 SCRUM MASTER STAKEHOLDER。通常会在同一时间进入一个迭代周期，制定各自的敏捷计划，并在同一时间退出，发布各自功能实现。而 4 支队伍的劳动果实被集成到一起就形成了可发布的产品了。
图 1. 敏捷开发团队的组织结构
因为敏捷团队中只有 1 名测试人员，因此需要一臂承担测试策略的制定，测试计划，测试脚本，测试用例设计以及测试的执行，帮助团队发现潜在问题，并协助解决问题的工作。敏捷团队的敏捷原则也是测试人员敏捷活动的规范，测试也需要拥有和团队的良好沟通，高度迭代的活动和不断的获得 STAKEHOLDER 的反馈。那团队的结构与敏捷本身有什么直接关系呢？与敏捷测试又有多少关联呢？
谈到这里，想起曾经有朋友向我咨询有关敏捷团队的某些职能的人力配备的问题。其实，笔者也无意论证 7 个人为什么是最佳组合，为什么不是 17 个，20 个人的组合。但是，敏捷原则告诉我们敏捷团队是高度协同、民主和平等的团队，为了让团队中每个人充分高效的工作。相同职能下的组员至多不好超过 3 名，最佳配置也是不同职能下配置 1 个人头。因此、在这样一个小型、平行的组织结构里，沟通更加易于建立，沟通复杂度也相对较低，相比 17、20 人的团队组织，沟通的代价也小很多。相反，很难想象在一个敏捷团队中会拥有诸多不同风格的执行者，决策者将是个怎样的混乱情况。
此外，经历过敏捷测试的体验，我们发现一个单一的敏捷团队最好保持较小的“尺寸”。这是因为拥有很多测试人员的敏捷团队通常不但需要更大的实际工作量来匹配庞大的机体而导致团队任务量更巨大，更复杂，失去自我管理的信心，而每个测试人员也将要花费大量精力和时间投入到内部沟通，和可能因为内部缺乏一致而导致的更加频繁的反复沟通中。