大话敏捷测试 | IDCF

来源：精益敏捷

作者：赵卫David

敏捷测试

• 从广义上来讲，测试是整个敏捷团队的活动，而不仅仅是测试同学的活动，因为原则上我们期望的敏捷团队的产出是经过代码编写+代码集成+代码测试之后的增量，所以开发同学也需要在这个目标指引下，如果测试有积压，开发同学需要针对故事进行测试，以便完成整个敏捷团队的交付承诺，而不仅仅是编码，仅仅编码不是用户和公司期望的，而经过测试的代码才是期望的；
• 而从狭义上来讲，敏捷测试，首先从测试同学角度，在敏捷开发的环境和上下文下，如何进行测试，思维和方法有何转变。

一、什么是敏捷测试？

来源：老话题新解说：究竟什么是敏捷测试？

在敏捷环境里，测试要想生存，需要转变认知，测试不再是传统意义上的测试阶段，而是变成了测试活动，从而才可以进行持续测试。

来源：https://www.luxoft-training.com/news/the-agile-testing-manifesto/

二、敏捷测试人员

《敏捷测试》：

• 敏捷测试人员：专业的测试人员，适应变化，与技术人员和业务人员展开良好协作，并理解利用测试记录需求和驱动开发的思想。
• 敏捷测试人员往往具有优秀的技术能力，知道如何与他人合作以实现自动化测试，同时也擅长探索性测试。他们希望了解客户在做什么，一次更好地理解客户的软件需求。

敏捷测试人员成为敏捷团队中的一员，通常敏捷团队采用最流行的Scrum框架，那么团队包括负责产品方向和ROI的产品负责人，负责引领敏捷Scrum的团队服务型领导Scrum Master，负责将产品愿景和需求实现的开发团队（包含所需各种技能的团队成员，例如开发前端技能，开发服务端技能，测试技能，测试自动化技能等等）。

三、敏捷测试思想

《敏捷测试》：以客户为中心，注重结果，勤于耕作、协作、富有创造力、乐于学习和适时地创造业务价值。

敏捷测试前提是敏捷开发，那么需要在认同和执行敏捷宣言的价值观和12原则前提下，从测试技能、测试活动角度，应该具备的思想，就是敏捷测试思想。

四、敏捷测试十大法则

来源：《敏捷测试》，强调态度和心态比特定技术能力更重要。

1、提供持续反馈

• 反馈需求以便描述清楚每个用户故事；

• 和团队共同将每个用户故事转化成可执行的测试；

• 和同队共同执行测试，不断接收有价值的反馈

2、为客户创造价值

• 聚焦关键路径，确保最小核心功能首先完成，边边角角复杂完美功能逐渐迭代上线。

• 敏捷测试人员不仅从利益相关者角度考虑软件系统，也会了解开发面对的技术限制和实施细节。尽早经常地向客户、产品负责人、开发提出问题，把他们的答案塑造成正确的测试。

• 自动化黄金流程/常用路径的测试；稍后增加负面测试和边界测试。

• 如果一个应用关注安全性，增加负面测试是必要的；

• 在迭代计划会议上，需要评估测试时间，确保迭代按计划发布安全可靠的应用

3、进行面对面沟通

• 敏捷测试人员和开发，产品负责人，业务代表甚至用户，面对面沟通

4、勇气

• 有勇气避免等待所有功能代码完成再测试，有勇气推动敏捷转型，一个用户故事一个用户故事测试。

• 有勇气践行测试先行，推进测试自动化和持续集成，无论是自动化单元测试，还是自动化其他各种类型测试，每个迭代持续积累自动化测试脚本。

• 有勇气允许犯错，从而持续改进。

• 有勇气说我们，而不是说我，说你。

5、简单化

• 从简单着手，开发进行简单设计编写简洁代码，测试人员采用轻量的工具和技术恰到好处地进行测试。

• 对测试分层，采取必要的测试策略。

6、持续改进

• 持续改进是整个敏捷团队的核心，也是敏捷测试人员的核心，持续学习，持续改进，尝试更出色的工作，只要能可持续的高效的为用户、客户的创造价值、交付价值，并且提升测试的专业。

7、响应变化

• 测试人员和开发人员一起适应和响应变化，在专注和变化之间找到平衡，自动化测试是一个关键。

8、自我组织

• 所有的产品实施交付活动都是团队的职责，敏捷团队贯彻敏捷测试理念，持续关注测试和自动化测试。最高优先级的问题需要整个团队解决。

9、关注人

• 敏捷团队成员互相尊重并认可个人成就，并有机会提高和发展各自领域的技能，也进行跨界扩展技能领域的广度，所有人是平等的，仅仅是具有不同技能的人而已，整个敏捷团队关注一个一个的用户故事的交付，任何人只有具备相应的技能，都可以贡献。只要测试工作得到执行，不一定要指定某些成员为测试人员。

10、享受乐趣

• 所有成员协作，整个团队负责质量和测试，从而激发和珍视敏捷测试人员对工作的激情，因为从测试角度，对团队和客户产生了真正的价值，而不是成为最后甩锅对象，出现问题，被各种人逼问，为啥测试没有把关好，把问题测试出来？

五、敏捷过程的测试策略

因为敏捷中落地实践最直接的是迭代，并且在迭代中是围绕一个故事一个故事进行开发和测试：故事设计->故事开发->故事测试->故事验收->故事上线 。 

所以就可以避免在迭代内做成小瀑布，测试人员在迭代后期等待大批量故事累积在一起之后再进行测试。这样就很好的践行了测试左移、持续测试、测试先行的敏捷理念。

这里的test first，是说测试先行，或者说测试动作/活动先行，而不必等到迭代后期测试。而TDD, Test Driven Development测试驱动开发，是开发人员先写函数/单元的测试代码，导致测试失败，再写功能代码，让测试通过，再重构成简洁代码的过程。

从用户视角，ATDD（验收测试驱动开发，Acceptance Test Driven Development）/BDD（行为驱动开发，Behavior Driven Development），是整个敏捷团队一起进行的测试用例识别和测试用例自动化的方法。

那么什么叫做一个故事一个故事进行开发测试呢？如下图最下边的情况，跨职能特性团队进行迭代，针对每个故事进行DBT，定义产品方案、构建开发、测试。

迭代内的进一步描述如下：

来源：《敏捷测试》

来源：《深入敏捷测试》

六、敏捷测试和传统测试的对比

来源：究竟什么是敏捷测试和探索式测试？

来源：爆肝全面分享什么是敏捷测试？

七、敏捷测试象限

来源：你被“敏捷测试四象限”蒙蔽多少年了？

八、自动化测试金字塔

自从Mike Cohn在2003年提出测试自动化金字塔之后，在自动化测试领域，对测试自动化的计划很有帮助，我们需要考虑在哪一层进行自动化测试。

来源：《深入敏捷测试》

Alister Scott为了更加强调探索性测试，在自动化测试金字塔上增加了上帝之眼（探索式测试）。

来源：《深入敏捷测试》

Sharon Robson扩展了测试金字塔，展现了多种质量维度、工具和测试类型。

1、在右边增加了针对测试类型和测试人员选择出来的测试工具。

• 用户验收测试：透明、易安装、易于重新运行，比如捕捉回放

• 系统：特定的活动或技术、打桩和驱动、命令行

• 单元：特定的技术，集成到持续集成环境

2、在左边，增加了测试类型或系统属性，保证可以考虑到解决方案所需测试的各个方面，例如功能性、非功能性。

• 用户交互的易用性、功能性

• 底层的可靠性、性能、易维护性

3、同时在最外围，对任何系统属性进行回归，把回归作为测试的一部分来考虑。

来源：《深入敏捷测试》

九、敏捷测试宣言

来源：http://www.growingagile.co.za/2015/04/the-testing-manifesto/

来源：敏捷测试宣言与原则解读 

来源：老话题新解说：究竟什么是敏捷测试？

来源：敏捷测试宣言与原则解读

 

来源：老话题新解说：究竟什么是敏捷测试？

12月3日（周四）晚8点，【冬哥有话说】12月专题【老R记】，邀请到德勤管理咨询系统集成线测试负责人陈晓鹏老师分享《敏捷环境下如何进行测试自动化》，识别下图二维码回复“老R记”即可获取直播地址~