软件测试什么是敏捷测试？

Posted 2020-11-02 shuozhang

转自微信：Rick Chen 晨小菜 TestOps

正在写DevOps培训总结的我看到了Rick Chen的文章，深表赞同，转发一下！原文地址

https://mp.weixin.qq.com/s/muwde7PsQkkJeZF4CIUDEQ

 

随着这几年敏捷概念和方法的流行，越来越多的组织和项目选择了敏捷开发模式。那么对于测试人员来说，究竟敏捷测试与传统测试有什么区别？测试人员在一个敏捷项目中需要如何转变才能适应当前这种流行的测试模式呢？请看下文介绍。

 

敏捷测试的定义

 

埃森哲对敏捷测试的定义（与维基百科的定义基本一致）大概如此：敏捷测试是遵从敏捷软件开发原则的一种测试实践。敏捷开发模式把测试集成到了整个开发流程中而不再把它当成一个独立的阶段。因此测试变成了整个软件开发过程中非常重要的环节。敏捷测试包含了具备专业技能测试人员在内的跨职能团队，这使得这种组合式的团队能更好的交付价值，满足项目的业务、质量和进度目标。

 

从定义中可以看出敏捷测试主要的核心内涵有三个：

1. 是遵从敏捷开发的原则（强调遵守）

2. 测试被包含在整体开发流程中（强调融合）

3. 跨职能团队（强调协作）

除此之外，敏捷测试用到的基本测试方法和技术与传统测试是一样的。

 

敏捷测试的特点

 

既然敏捷测试属于一种新的测试实践，那么到底它有什么的特点呢？我用“四个更”来归纳：

 

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

 

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

 

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

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

 

为什么要敏捷测试

 

一个很直接的原因是如果整个项目都在采用敏捷开发模式，比如两周一个迭代，你还在跟项目谈传统的各个测试阶段，就好像两个不同转速的齿轮，根本无法结合。试问，两周时间能完成得了所有的测试阶段吗？所以必须要有新的测试实践来取代原有的模式，才能更好的适应敏捷小步快跑的特点。当然，除了适应开发的节奏外，敏捷测试还是有其特有的价值：

 

缩短价值交付周期

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

 

更早发现测试风险

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

 

强调质量属于大家

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

 

化繁为简节省成本

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

 

敏捷测试VS. 传统测试

 

那么敏捷测试和我们熟悉的传统测试比，他们到底有什么样的区别呢？我整理了如下对比表：

 

传统测试	敏捷测试
1. 测试发生在最后阶段	1. 测试发生在每一个Sprint迭代里
2. 组与组之间的沟通是正式的	2. 组与组之间除了正式沟通外也有很多非正式沟通
3. 测试自动化是可选项	3. 测试自动化被高度推荐
4. 测试以需求文档为准	4. 测试以最终用户为准
5. 详细的测试计划	5. 精益化的测试计划
6. 计划是一次性活动	6. 计划分为不同的级别 - 开始阶段为粗粒度的计划 - 在Sprint 0及后续Sprint为’Just-In-Time’ 式的计划
7. 项目经理计划整个团队的工作	7. 团队被授权和主动参与到计划中
8. 开始阶段要求详细需求	8. 开始阶段允许High-Level需求
9. 需求被定义后客户有限的参与	9. 客户参与贯穿到整个项目生命周期

  

传统测试如何迁移到敏捷测试

 

1. 组织文化的转变

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

 

2. 组织架构的调整

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

 

3. 人员培训与指导

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

 

4. 轻流程

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

 

敏捷测试成功的关键要素

 

Lisa Crispin在《敏捷软件测试：测试人员与敏捷团队的实践指南》中总结了敏捷测试成功的七大关键要素，我觉得可以精简为下面五大关键要素：

 

1. 领导层的大力支持

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

 

2. 测试人员具备敏捷思维

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

 

3. 要有勇于尝试的信心

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

 

4. 与各方紧密协作

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

 

5. 自动化、自动化

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

 

 

 

 

 

参考资料：

1.《敏捷软件测试：测试人员与敏捷团队的实践指南》

2. 维基百科

3. 埃森哲敏捷测试方法论

4. 德勤《From Waterfall to Agile - Anorganization and culture change perspective》