分布式团队

敏捷开发测试工程师们坐在一起工作，这样交流更加方便直接，减少沟通成本，这在软件快速迭代、快速响应需求变化的过程中是相当重要的。每天有scrum，有defect可以快速交互。但这在分布式团队中很难实现，两支不同时区的团队没有重合的工作时间，开会时间安排成了问题，如何把各自团队自己的scrum结果让另一方也知道呢？除了从分配story方面尽量减少两支团队的story依赖和耦合外，是需要采用一些特定适合的方式来解决。如果能克服时差，一块scrum是好的。不行的话，可以通过 scrum mail每天互相交换更新的状态。

迭代测试+自动化测试

每个迭代都会有一些新的功能被开发出来，如何制定计划既保证这些新功能的测试，又保证新功能或者defect的修复不会导致已有功能遭到破坏呢，这里有一些策略。首先是功能开发的迭代计划，项目经理需要仔细考量不同的story在各个迭代之间减少依赖和耦合，软件架构设计者也需要有同样的考虑，这里有软件可测试性的问题。这样在测试人员介入后，不会发生牵一发而动全身，顾此失彼的问题。

另外是在软件系统随着迭代的不断进行，累加的功能越来越多，测试资源有限，不可能一直全面地测试到软件系统的所有方面。除了前面提到的不同迭代的软件交互很少依赖和耦合外，自动化的测试是保证不断迭代后继续保证软件质量的不可缺少的途径。自动化测试开发，这是另外一个话题，如果认为这全部只是测试工程师的责任，那是短见和无知了。自动化测试要求软件系统开发者能够在UI上预先提供一些钩子，供自动化测试开发工具抓取UI对象进行识别并操纵，完成模拟用户的实际操作。如果这方面的软件可测性也无法保证的话，测试脚本维护成本居高不下，影响软件质量，除了测试工程师叫苦不迭之外，终仍然会形成很多defect送到开发者的面前。所以，这是整个团队的责任。

缺陷管理

软件开始正式的迭代开发后，由持续集成所产生的软件交付成为测试工程师的工作目标，但如果一些功能还没有完全实现因此产生了defect，测试工程师把它们记录在缺陷跟踪系统里面，越积越多，测试工程师据此为自己的工作量体现，姑且不说这对软件质量没什么意义，在功能实现彻底完成之后，之前的这些 defect中的大多数会自行解掉设置无效，那么测试人员所做的又是大量的无用功了。需要时刻牢记在心的是，终目标是软件质量的提升，而不是 defect的数量。测试和开发足量的沟通交流，足以消除掉大多数无谓的defect，只有那些已经完成的功能跟软件需求还相悖的话，才是真实有价值的 defect，值得记录值得跟踪。

团队观念

说到底，“敏捷测试”需要的是一支紧密协作的团队，开发和测试工程师互相配合，充分沟通交流，为提升软件系统的质量致力工作，不在意无谓的defect数量，减少功能模块间的耦合依赖，提高软件可测试性，合作开发自动化测试脚本。其实根本无需太较真在“敏捷”这个字眼上，更重要的是改进出适合自己团队的软件开发测试模式。