• 很多团队采用Scrum体系主要是因为不像Kanban功能比较松散，也没有Safe体系那么庞大。

• 采用Scrum可以在中小型的企业中容易开展工作。

  
  来源网络.png

敏捷测试是什么

敏捷测试是一套遵循敏捷软件开发原则的软件测试实践。敏捷开发将测试集成到开发过程中，而不是将其作为单独的阶段。因此，测试是核心软件开发的一个组成部分，并积极参与软件开发过程

• 敏捷测试宣言

  
  来源网络.png

敏捷测试与传统测试的区别

• 敏捷测试是从客户角度测试
• 传统测试是用需求的角度测试

• 敏捷测试过程中主推自动化测试

  
  来源课程.png

敏捷测试原则与指南

来源课程.png

Scrum敏捷测试流程

• 如果需求模糊，或者用户故事不明确的情况下，需要参与sprint前面的参与工作
• 规划Sprint中的工作与参与人员确定用户故事
• 需要有三类人员参与：PO,Dev,QA
• Dev需要研发工作，主要是开发人员能够实现价值
• QA是可以验证价值的
• 测试2类人员：回归测试人员，测试开发人员

来源课程.png

基于Scrum的基础测试

• 课程回顾（Kanban的pull过程是类似瀑布模式，那如何实现敏捷）
  （比如Kan会将开发完成以后，Kanban状态改变以后，测试才能开始工作，这种属于瀑布类型）

解决的方法

1.添加两层Kanban，将一个Kanban内容划分成开发，测试。只有开发，测试都通过以后，Kanban状态再进行改变
2.Kanban内容可以添加不同的类型，比如开发，测试，前端，后端等不同的类型

Sprint冲刺流程

• 开发完成以后自动化测试，将开发的需求功能通过自动化测试工作
• 自动化测试以后如果还有bug，需要将这个bug重新创建成一个新的子集sprint backlog
• 将这个backlog重新进行修复然后再测试
• 如果开发完整的功能以后，可以通过CICD进行冒烟自动化测试
• 冒烟自动化测试是为了实现全功能的基础验证过程

来源课程.png

Daily Scrum Meeting

• 将昨天做完的工作质量需要汇报，比如自动化测试完成以后有什么问题
• 今天的工作是不是需要新写自动化脚本来覆盖新的功能
• 将测试过程中遇到的问题提出来并得到解答

来源课程.png

Scrum Review Meeting

• 一般是开发人员来主持，因为开发会比较熟悉业务
• 建议是测试人员来主持，因为除了业务还有是否满足用户的角度考虑，测试人员会更加合适
• 产品演示
• 确认可交付价值
• 准备下次计划会议
• 更新项目的进度

来源网络.png

Scrum Retrospective Meeting

• 本次系统问题的分析，缺陷分析
• 缺陷分析包括整体的缺陷覆盖哪些功能模块
• 本次交付的提升亮点
• 下次交付的可优化点

• 整体的评估

  
  来源网络.png
  image.png

基于Scrum的测试左移

• 确保进入Sprint Backlog的质量

• 验收标准是否明确

• Sprint Plan会议评审：AC的确定，有哪些Task，完成的标准有哪些

• 进入PB,SB的过程就称为测试左移

  
  来源课程.png

基于Scrum的测试右移

• 确保交付的质量

• 基于生产环境的灰度测试

• 灰度测试可以将某些需求进行回退

• 灰度测试需要有一定的环境，比如一些白名单，或者有效的验证码，跳过一些环境必要的验证环节

• 环境标签一般有:Dev,Pre,Test

• 环境版本标记是用来标记每次发布的版本信息，完成版本回退

• 问题尽量在测试环境中找到，不要出现在生产环境

  
  来源课程.png

跳出规范模式

• 最合适的才是正好

• 将所有的测试需要明确

• AC，DOD尽量明确，可以跟研发团队保持良好的沟通

• 持续反馈自己的问题，将反馈的时间尽量缩短，因为问题不能出现在开发完成以后

  
  来源课程.png

测试如何敏捷化

• TestOwner是一名测试教练的角色

• 流程化的书籍推荐《测试敏捷白皮书》

  
  来源课程.png

如果在敏捷测试中持续的改变自己

• 将自己能够胜任的工作先做好，然后将技术不断的提升

• 针对业务进行分析，能够将业务价值最大化

  
  来源课程.png