|
此外，经历过敏捷测试的体验，我们发现一个单一的敏捷团队最好保持较小的“尺寸”。这是因为拥有很多测试人员的敏捷团队通常不但需要更大的实际工作量来匹配庞大的机体而导致团队任务量更巨大，更复杂，失去自我管理的信心，而每个测试人员也将要花费大量精力和时间投入到内部沟通，和可能因为内部缺乏一致而导致的更加频繁的反复沟通中。项目管理者联盟
每名敏捷的测试人员需要和其他敏捷团队成员保持频繁而必要的沟通以保证对目标，需求、设计的充分正确的理解，对需求变化能够迅速的做出反应。另外，还需要与职能队伍中的其他测试成员保持一致性。如此一来，沟通代价激增了，它将占到测试人员的工作中的较大比例。而这种内部沟通、协调，却不能定义为敏捷的 Backlog 项目来计入团队整体的工作输出。因此，整体的测试效率并不一定随着人力资源的投入而递增。非但没有实现敏捷原则，而恐怕因为团队的组织结构变得更加庞杂。所谓的“自我管理、自我发展”的团队只能因而依靠传统的管理和规划了。笔者认为，除了因为特殊阶段，特殊时期，敏捷团队需要“聚合”更多资源来一并解决存在的高优先级的体力型问题外，敏捷的团队应该尽量保持着较小的“尺寸”。项目管理者联盟
果真项目投入了很多的人力资源，无论设计还是实现、测试团队拥有较大的人数，那么我们应该考虑将这样的团队可以分得更小些，工作量也相应分得更精细些，直至接近我们建议的最佳组合。至少我们认为要做好敏捷测试，就要确保敏捷团队中的每一个职能拥有足够清晰的职责范围和一定程度下自由空间和在这个空间内的充分授权。因此，但从人数和职能构成上，敏捷团队的构成一定是不可忽略的重点。项目管理者联盟
正像我们前面提到的，确认软件开发过程的正确性也尤为重要，因此作为敏捷的测试人员，更要了解敏捷的过程，比如说，测试人员需要帮助 UCD 和开发人员确定需求的可行性，测试人员要督促开发人员及时发布 build，以保障迭代结果最终能够在通过足够的测试后成功发布等。在 build 发布后，测试人员要首先验证当前迭代的任务是否已经完成，其次才是验证产品功能的正确性。也为了能够在日后重复性和体力型劳动中解放出宝贵的时间去覆盖测试更加紧要的内容，如可用性，全球化等，测试人员需要自动化一部分测试，创新的、灵活的工作。blog.mypm.net
敏捷团队是自我管理的团队，高度协作的团队，质量目标即是测试团队也是整个开发团队追求的目标，因此开发团队应将做好单元测试，设计团队将帮助测试团队设计好测试用例作为计划内的一项工作。这里我们推广、建议开发人员采用、普及测试驱动开发模式。项目管理者联盟
测试驱动开发项目管理者联盟
测试驱动开发表现出迭代开发的最核心的就是开发人员自己能够第一时间确认其需求得到了正确实现，而当单元测试覆盖了更多的内容，代码质量也将得到提高。测试驱动开发的指导思想就是让开发人员在编写功能代码之前，先根据需求编写测试代码。先思考如何对将要实现的功能进行验证，并完成单元测试脚本的编写，然后编写足够，仅仅足够的功能代码满足这些测试用例，直至通过测试。按照这个方法，递增的在迭代中增加新功能的单元测试和功能代码编写，直到完成全部功能的开发。项目管理者联盟
在单元测试活动中，测试人员也被鼓励参与到单元测试的设计中来，不但可以帮助开发人员构思出更多的单元测试用例来扩大单元测试的覆盖率，还可通过学习如何使用单元测试，如何复用单元测试用例到回归测试和功能测试，以达到最大化利用有效的资源(如下图)和节约成本的作用。同时，在回归测试和用户接收测试(User Acceptance Test)中如能将单元测试脚本有机的关联起来，并自动化其执行，更能够进一步提高测试的成效并降低测试成本。项目管理培训
单元测试脚本因随需求、设计的变化随时更新。需要开发人员站在全局的立场，开发始终坚持先修改测试脚本，再修改产品原代码。此时，也建议测试人员参与单元测试脚本的改进，帮助开发人员合理的变更单元测试脚本，同时着手修改测试计划和测试策略。项目管理者联盟
图 2. 测试驱动开发项目管理者联盟
项目管理者联盟
递增的迭代测试项目管理者联盟
测试驱动开发的原则应该运用于每一迭代周期的开发中。但是，测试驱动开发的单元测试仍然是以开发为目的的活动，虽然自动化测试，回归测试和用户的接收测试(User Acceptance Test)可以通过复用单元测试脚本提高以后的测试工作的效率，但单元测试不是我们敏捷测试讨论的重点。项目管理者联盟
敏捷测试活动的主要承载者还是敏捷测试人员。测试人员如何运用敏捷原则指导测试活动还是笔者在敏捷测试实践一文中要讲述的重点。以下，笔者将通过两个迭代测试模型来帮助了解测试人员如何结合敏捷原则实践敏捷的测试活动。pmp.mypm.net
经典敏捷增量测试模型项目管理者联盟
测试是敏捷开发过程重要的环节，自始自终测试贯穿于每个迭代。Scott W. Ambler 认为就整个产品的敏捷开发生命周期可以分为 4 个阶段，即初始阶段，项目的建设阶段，产品发布阶段和产品的维护阶段，在关键的项目建设阶段中，测试被分成两个部分，Confirmatory 测试和 Investigative 测试。 1 下面，我们来讲讲迭代的测试的这两个方面。项目管理者联盟
图 3. 敏捷测试生命周期talent.mypm.net
项目管理者联盟
Confirmative 测试就是对 build 的有效性和关键的功能是否正确进行验证，测试人员依据测试用例和测试脚本的完整测试是工作的重心。原文中的 Confirmative 测试包含了开发人员的单元测试(必不可少的重要开发活动)和被称之为 Agile Acceptance Testing 的测试部分，这段时间的测试任务用来保障迭代的必须输出的质量。基本的功能、非功能的任务，但凡是在迭代开始时制定的计划中承诺的高优先级需求，哪怕是很繁琐的细节工作都要被充分的测试和验证。项目管理者联盟
Investigative 测试是对 Confirmative 测试的补充和是更广泛的测试活动，测试团队在完成 Confirmative 测试后的时间用来做这部分测试，它包含功能测试，文档测试和系统测试以及和其他产品、环境之间产生的必然的 Integration 测试，还有个非常有趣的测试活动叫做 Exploratory 测试，笔者认为这部分测试是测试人员创造性的采用多种不同途径去尝试测试产品。就好比“猴子敲键盘”一样，测试员使用各种手段来考验 build 和产品的稳定和正确性等。项目管理者联盟
图 4. 敏捷测试的 Incremental Testingbbs.mypm.net
项目管理者联盟
自定制的敏捷增量测试模型项目管理者联盟
我们在敏捷项目开发的过程中使用了定制的测试流程，我们同样有相同的两部分测试，即 Confirmative 和 Investigative 两部分。不同的是，我们原则的将这两部分测试都放在当前迭代的计划内完成。原因是，敏捷测试团队针对当前迭代的任务计划本应服务于当前的产品，过去的迭代产物，或者因为需求变更不再适用，又或者因为未解决的质量缺陷使得实际测试效果不佳。而同时，因为 Product Owner 和 STAKEHOLDER 的期望是团队能够高效的完成当前迭代的任务，完成更高优先级的工作，每个迭代的考核亦非常清晰。为了完成服从当前的高优先级任务，计划，也为了 STAKEHOLDER 更好的关注和帮助当前问题的及时解决，测试人员对以往 Build 的测试应应合理的计入先前迭代的任务而不是当前迭代计划。倘若真要测试以往的产品而不是最新的，敏捷测试的管理也将变得有些困难，同时测试团队所关注的问题也只能是过时的，只能成为团队的低优先级的问题。这不是与团队整体的目标背离吗?因此，我们建议测试团队使用我们改进后的敏捷增量测试模型，即在当前迭代仅仅完成当前迭代的计划，而所有测试都需要围绕最新的产品 Build 进行。项目管理者联盟
图 5. 定制的 Incremental Testing项目经理博客
|
