①强调从客户的角度，即从使用系统的用户角度，来测试系统。

②重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。

③建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

①更强的协作

敏捷开发人员和测试人员工作得更加紧密，喜欢更直接的沟通方式而不是通过邮件文档这种一来一回反反复复的沟通模式；

②更短的周期

需求验证或测试的时间不再是按月来计算，而是按天甚至按小时计算。用户验收测试在每个sprint的结尾都会进行；

③更灵活的计划

敏捷测试也需要拥抱变化，测试计划不再是一成不变的文档，而会根据业务价值交付的顺序进行灵活的调整；

④更高效的自动化

相比传统测试，自动化在敏捷测试中扮演了极其重要的角色。它是实现快速交付确保质量的一种非常有效的手段

①缩短价值交付周期

通过采用敏捷测试这种模式，可以契合整个敏捷开发周期，使得整个敏捷开发按照相同而快速的迭代速率和周期交付，让最终用户尽快获取到业务价值；

②更早发现测试风险

敏捷测试使得测试人员尽早开始进行测试，尽早的发现系统缺陷或存在的问题，避免所有的问题都堆积在最后的测试阶段形成“Big-bang”的结果，降低整体系统风险；

③强调质量属于大家

质量是构建出来的，而不是测出来的。敏捷测试一直强调质量属于每一个人的责任，除了测试之外，开发、产品经理等都有义务对自己的交付件质量负责，这样才能确保项目的整体质量；

④化繁为简节省成本

敏捷测试没有要求需要详细的测试计划和测试文档，也没有定义繁复的测试流程及缺陷流程，这种轻量级的管理模式为测试人员减少不必要的负担，节省了工作量及成本。

①组织文化的转变

德勤在介绍敏捷开发相关文章中提到，组织文化是一个被用在覆盖组织方方面面的术语——从基本的认识、态度和价值观到组织特定的语言、知识和技术等。在敏捷文化中，相比于流程，敏捷更关注人，所以敏捷测试组织是应该是以人为导向、自组织、协作式的一种文化氛围。但是据笔者观察，不少敏捷项目仍然缺乏这样的文化基因。比如在站会的时候，还是会看到所谓的TeamLead站在“C位”主持和领导着会议，团队都站在后面等待汇报工作。

②组织架构的调整

从项目特点来看，敏捷是属于“强项目型”管理的方式，所以如果以前是属于职能型的组织架构，比如开发人员隶属开发部门，测试人员隶属测试部门，那么在敏捷项目中需要进行调整。开发和测试同属一个项目一个团队，大家的目标是一致的，就是要保证项目的成功。所以测试人员可能会帮开发人员评审代码，开发人员也会帮测试人员进行测试，人员角色的职能变得模糊化。

③ 人员培训与指导

任何新的方法如果没有进行相关培训和了解，会让具体执行人觉得不安而没有底气。同样，敏捷项目中测试人员在进行测试前也需要接受敏捷知识的培训。如果可能的话，最好是由具有丰富经验的敏捷教练帮忙进行导入，在教练的帮助下进行成长，避免走错方向。

④轻流程

传统项目的开发管理方法体系比如CMMI相对来说比较重流程，要求的交付件也非常多。而敏捷强调轻流程，尽量减少不必要的文档，使得整个开发模式变得轻快。所以在设计流程和交付件时，需要充分考虑这个特点，尽量简化。当然，少文档不是代表不用写任何文档，一些必要的文档还是需要有的。

① 领导层的大力支持

任何一个改变要想实施成功，都离不开领导层的大力支持。从领导层的角度需要提供一个宽松的环境，让整个敏捷测试团队能够形成自组织的模式。当遇到问题时不是进行追责，而是给予足够的信任和支持，帮助团队度过难关，陪伴团队的成长。

②测试人员具备敏捷思维

测试人员需要了解敏捷，掌握敏捷的基本知识和原则，从而才能在整个敏捷体系中更快的融入到敏捷环境中，从而更好的开展整个测试工作。

③要有勇于尝试的信心

相比传统测试来说，敏捷测试比较新。很多测试人员对于新的事物不敢去尝试，做事畏畏缩缩、裹足不前。因此需要测试人员有敢于尝试的决心，不怕做不好，就怕不去做。只有做了，才知道哪里行哪里不行。然后再根据不足进行优化，从而最终取得成功。

④与各方紧密协作

在敏捷项目中，测试人员与其他方的直接沟通会非常频繁。测试人员不仅需要和开发人员紧密协作，还需要和产品经理甚至是最终用户保持频繁的沟通，使得整个测试更有效率。

⑤ 自动化、自动化

自动化是敏捷测试非常重要的元素。在敏捷开发这种极短的交付周期内，如果仅仅靠手工测试，则非常难以满足快速发布要求的。所以自动化测试是必不可少的一种手段。另外这里谈到的自动化不仅仅只是指单纯的自动化测试，还包括自动化测试如何集成在整个交付管道中，缩减整个交付时间，实现持续集成甚至是DevOps，最终给项目带来价值。