我一直认为敏捷是以开发为中心的，如果敏捷宣言尚且是对传统软件开发模式原则上颠覆的话，那么敏捷所带来的N多最佳实践更是以开发过程改进为目标的，信手拈来的就是TDD、CI、XP、PP等诸多实践方式，就是跟测试拉上一点关系的UT和Acceptance Testing也是多由开发者自己来完成，那对专业测试工程师来说，当团队进入到Agile的环境后，会有怎样的不同遭遇呢?在Agile中如何到测试更有效呢?
测试在敏捷前后的不同
在敏捷环境中，测试可以早介入，从确认客户需求开始，到测试计划、测试案例、测试执行、缺陷跟踪、回归测试，一直到最后软件系统发布，测试会贯穿在整个流程中，这是明显区别于传统的瀑布型模式的。这样的优点毋庸置疑，让测试专家从客户的角度尽早的使用软件，及早发现与需求相悖的问题，尽量减小因设计实现所带来的缺陷问道所招致的维护成本。
这样的描述会在所有“敏捷测试”相关的国内外资料中都能看到的，也是为大家所承认的。但具体问题具体分析，在不同的团队构成、不同的软件系统等条件下，所谓“敏捷测试”总不得不去面对一些棘手的问题。
测试在敏捷中的困境及对策
虽然测试工作的内容无非包括计划、执行、回馈等几个环节，这在进入敏捷环境后也不会有怎样的变化，但面对采用了诸多开发最佳实践的开发者以及会产生快速迭代出新功能的软件系统，测试人员如何保持快速的响应，并实时地调整测试过程，是每个测试团队不得不面临的问题。即使是“敏捷测试”的推广者们，在宣扬了测试早介入之后，也鲜有值得推介的测试实践拿出手来。这对各个测试团队无疑是个考验，即使是采用了相同敏捷实践的开发者也不会表现出一样的生产力，只有测试工程师根据整个团队的特点，总结出一套最适合团队的测试模式，才是最理想的。
系统测试
不得不说的是，就算是“敏捷测试 ”也没有考虑到系统测试在敏捷环境中怎样做。这对一般不会太看重软件性能和集成性的系统来说不算个大问题，但对具有大大小小系统性能测试需求的测试团队来说，是不可想象的。测试早介入，在系统测试团队看来似乎是场噩梦，对尚未稳定的架构施加系统性能测试，多半会引起系统测试工程师们徒劳无功，因为开发人员这时不会太介意性能上的问题，他们有更重要的功能还没实现，但schedule如此紧张。如果中途需求变化甚至架构变化，开发者几乎可能把设计实现全部推到重来(这也是拜敏捷所赐了)。那之前系统测试工程师花费大量精力和时间，发现的问题很可能就此不可重现不再有效。相对白白付出的工作量，如果这段时间用来做技术调研准备和自动化测试开发，效益不可同日而语。这里需要开发团队和系统测试工程师相互配合，开发为测试定义一些系统测试的进入点，并及时对系统测试的defect作出响应，才是理想的行为。
分布式团队
敏捷专家推荐开发测试工程师们坐在一起工作，这样交流更加方便直接，减少沟通成本，这在软件快速迭代、快速响应需求变化的过程中是相当重要的。每天有scrum，有defect可以快速交互。但这在分布式团队中很难实现，两支不同时区的团队没有重合的工作时间，开会时间安排成了问题，如何把各自团队自己的scrum结果让另一方也知道呢?除了从分配story方面尽量减少两支团队的story依赖和耦合外，就是需要采用一些特定适合的方式来解决。如果能克服时差，一块scrum是最好的。不行的话，可以通过 scrum mail每天互相交换更新的状态。
迭代测试+自动化测试
每个迭代都会有一些新的功能被开发出来，如何制定计划既保证这些新功能的测试，又保证新功能或者defect的修复不会导致已有功能遭到破坏呢，这里有一些策略。首先是功能开发的迭代计划，项目经理需要仔细考量不同的story在各个迭代之间减少依赖和耦合，软件架构设计者也需要有同样的考虑，这里有软件可测试性的问题。这样在测试人员介入后，不会发生牵一发而动全身，顾此失彼的问题。
另外就是在软件系统随着迭代的不断进行，累加的功能越来越多，测试资源有限，不可能一直全面地测试到软件系统的所有方面。除了前面提到的不同迭代的软件交互很少依赖和耦合外，自动化的测试是保证不断迭代后继续保证软件质量的不可缺少的途径。自动化测试开发，这是另外一个话题，如果认为这全部只是测试工程师的责任，那就是短见和无知了。自动化测试要求软件系统开发者能够在UI上预先提供一些钩子，供自动化测试开发工具抓取UI对象进行识别并操纵，完成模拟用户的实际操作。如果这方面的软件可测性也无法保证的话，测试脚本维护成本居高不下，影响软件质量，除了测试工程师叫苦不迭之外，最终仍然会形成很多defect送到开发者的面前。所以，这是整个团队的责任。
缺陷管理
软件开始正式的迭代开发后，由持续集成所产生的软件交付成为测试工程师的工作目标，但如果一些功能还没有完全实现就因此产生了defect，测试工程师把它们记录在缺陷跟踪系统里面，越积越多，测试工程师据此为自己的工作量体现，姑且不说这对软件质量没什么意义，在功能实现彻底完成之后，之前的这些 defect中的大多数就会自行解掉设置无效，那么测试人员所做的又是大量的无用功了。需要时刻牢记在心的是，最终目标是软件质量的提升，而不是 defect的数量。测试和开发足量的沟通交流，足以消除掉大多数无谓的defect，只有那些已经完成的功能跟软件需求还相悖的话，才是真实有价值的 defect，值得记录值得跟踪。
团队观念
说到底，“敏捷测试”需要的是一支紧密协作的团队，开发和测试工程师互相配合，充分沟通交流，为提升软件系统的质量致力工作，不在意无谓的defect数量，减少功能模块间的耦合依赖，提高软件可测试性，合作开发自动化测试脚本。其实根本无需太较真在“敏捷”这个字眼上，更重要的是改进出最适合自己团队的软件开发测试模式。
文章来源于领测软件测试网 https://www.ltesting.net/
