- 很多团队采用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
