第3章 敏捷测试转型框架
1 敏捷测试转型模型
敏捷测试转型模型概述
- 文化
- 组织
- 流程
- 实践
- TDD
- BDD
- ATDD
实施重要程度和实施困难程度
- 实施重要程度
- 实施困难程度
敏捷测试转型模型实施顺序
- 自顶向下：领导不重视
- 自低向上：领导重视
- 混合
2 敏捷测试文化
组织文化转变
- 小心变成“质量警察”
- 保持可持续的速度，而不是在项目的最后阶段进行快速激烈的测试
- 合作伙伴式的客户关系
管理文化转变
1.每个团队都有能力做出决策
一是外部相关，是指组织或需要赋权给团队，让团队有权利自己做出相关的决策
二是内部相关，是指团队必须有能力判断并做出正确的决策。
2.提倡免责文化
敏捷是基于经验的
3.管理层需要具备敏捷知识
Richard Knaster 和 Dean Leffingwell 在《SAFe4.0精粹:运用规模化敏捷框架实现精益软件与系统工程》中提道:“企业的领导者必须拥抱精益-敏捷”思维。如果领导者只是通过语言而不是自身的行动来支持“精益-敏捷”思维人们很快就会认识到他们不是在全心全意地推动变革。他们必须知晓方法,强调终身学习需要用新的行为践行这些价值观、原则和实践。所以在规模化敏捷 SAEe的系列培训课程中，专门有一门课程叫作Leading SAFe,主要对管理层和主管级别以上的领导进培训。
文化转型障碍及解决方法
1.组织变化带来的恐惧
在 Sprint 回顾会上正面讨论测试人员的恐惧，团队集思广益，共同解决
组织需要规划和制订属于测试人员的职业发展路线
2.缺乏对敏捷概念的基本认识
为测试人员提供敏捷相关知识培训
敏捷教练在辅导团队的时候，需要对这些没有敏捷经验的测试人员多加关注
3 无法满足更高的技能要求
成立测试实践社区
对于部分技能要求较高的岗位，可以考虑从外部招聘合适的人员来补充团队力量。
3 敏捷测试组织与个人
敏捷测试组织架构转变
组织架构转变后的测试人员的归属感问题
1 组织内成立卓越测试中心(Testing Center of Excellence)
卓越测试中心不能于涉和管理测试人，测试人员完全属于项目。
项目结束，测试人员回归卓越测试中心，准备再分配
2 成立测试实践社区(Testing Communities of Practice，TCoP)
传统测试人员的转变法则
敏捷测试专家 Lis Crispin 和 Janet Gregory 在合著的 Agile Testing: A Practical Guide for Testers and Agile Teams中列出了对于敏捷测试人员来说非常重要的 10 条法则。
- 提供持续反馈:测试人员天生就是信息反馈者。
- 为客户创造价值:测试人员比开发人员更了解客户需要什么。
- 进行面对面沟通:业务团队和开发人员经常使用不同的语言，测试人员可以帮助他们拥有一种共通语言。
- 勇气:要有勇气允许自己失败、他人失败，要有勇气寻求帮助。简单化: 通过最简单的方法验证功能已经达到客户的质量要求
- 持续改进:努力把工作做得更好。
- 响应变化:响应变化是敏捷实践的重要价值。
- 自我组织:团队文化贯彻于敏捷测试理念。
- 关注人:敏捷团队成员互相尊重并认可个人成就。
- 享受乐趣:保持对工作的激情。
4 敏捷测试流程
Scrum层级与需求抽象层级
- 产品组合规划
- 产品规划
- 版本规划
- Sprint 规划
- 日常规划（每日立会）
2.需求的不同抽象层级
- 史诗
- 特性
- 用户故事
- 任务
- 主题
敏捷测试的类型
- 代码：质量扫描和单元测试 Sprint内
- 用户故事：验收标准进行测试 Sprint内
- 特性：用户故事之间如何协同工作，大部分Sprint内，小部分Sprint外
- 非功能性，比如性能测试，全程
Sprint 内测试
- 代码质量活动，如代码扫描等
- 单元测试
- 用户故事验收测试
- 部分特性和能力验收测试
跨 Sprint 测试
- 特性和能力验收测试
- 史诗验收测试
- 端到端集成测试
- 回归测试
敏捷测试角色
1.Sprint 内测试角色
(1)Sprint 内测试工程师。
(2)测试开发工程师(Software Development Engineer in Test，SDET)。
2.跨Sprint (版本发布级别)测试角色
(1)自动手铲架构师。
2)测试架构师
(3) 回归/发布/集成/UAT 测试工程师
(4) 测试经理
敏捷测试角色所需技能
(1)自动化架构师
自动化架构师必须完全掌握包括技术架构和 DevOps、环境/数据/监控、非UI和服务器虚拟化、UI自动化测试、测试执行、测试设计和测试管理等知识技能。
(2) 测试开发工程师
开发、技术架构和 DevOps、环境/数据/监控和服务虚拟化、UI自动化测试、测试执行等知识技能。
(3)Sprint内测试工程师
UI自动化测试、测试执行、测试设计和测试管理等知识技能
(4)回归/发布/集成/UAT 测试工程师
非UI和服务虚拟化、UI自动化测试、测试执行、测试设计和测试管理等知识技能
(5)测试架构师和测试经理
包括环境/数据/监控、非 UI 和服务虚拟化、UI自动化测试、测试执行、测试设计和测试管理等知识技能
敏捷测试流程
类型 | 步骤 | 角色 | 描述 |
|---|---|---|---|
Sprint 内测试流程(针对每个用户故事) | 1 | 产品负责人、团队 | 在本次 Sprint 开始前，产品负责人和敏捷实施团队一起梳理和角色产品负责人、团队准备用户故事 (《Scrum 精髓:敏捷转型指南》建议开发团队花费不超过 10%的工作时间参与需求梳理工作) |
2 | 产品负责人、团队 | 在 Sprint 计划会上，产品负贵人和敏捷实施团队一起评审用户故事并确定验收标准 | |
3 | 开发人员 | 在 Sprint 计划会后，开发人员针对需求进行特性分解，或者对用户故事进行技术设计或验证工作 | |
4 | Sprint 内测试工程师、测试开发工程师、回归/发布/集成/UAT 测试工程师 | 与步骤3 同时进行:Sprint 内测试工程师编写需求验收测试用例回归/发布/集成/UAT 测试工程师编写端到端验收测试用例测试开发工程师与 Sprint 内测试工程师、回归/发布/集成UAT 测试工程师共同编写需求验收和端到端的自动化测用例(脚本) | |
5 | 开发人员 | 在 Sprint 内的开发环境中，开发人员须遵从测试驱动开发(TDD)的规则，定义单元测试并编写代码，直到所有的单元测试通过。另外，还需要运行代码扫描工具进行代码质量检查 | |
6 | 开发人员、测试开发工程师、Sprint内测试开发工程师和 Sprint 内测试工程师合并需求验收自动化测测试工程师 | 与步骤 5 同时进行:测试开发工程师和 Sprint 内测试工程师合并需求验收自动化测试用例到CI/CD部署流水线 | |
7 | 回归/发布/集成/UAT 测试工程师 | 与步骤 5 同时进行:回归/发布/集成/UAT测试工程师把准备好的端到端验收自动化测试用例合并到端到端回归测试用例集 | |
8 | 开发人员 | 开发人员将代码提交并合并到服务端代码主干，触发 DevOps部署流水线 | |
9 | NA | CI流程自动构建被测应用，执行静态代码扫描和自动化单元测试。如果通过“质量门”，那么二进制代码的应用将被部署到CICD 的测试环境中 | |
10 | NA | CICD 流程执行自动化验收测试(包括 API和UI) | |
11 | Sprint 内测试工程师 | Sprint 内测试工程师进行探索式测试，如发现缺陷立即反馈给开发人员修复并执行回归测试。运行所有安全扫描测试，最后完成用户故事的测试 | |
跨 Sprint测试流程(本次版本所有已完成用户故事) | 12 | 产品负责人、团队、利益干系人等 | 在本次 Sprint的所有用户故事通过测试后，进行 Sprint 演示如果演示通过，那么表示本次 Sprint 结束，此时将已接受的用户故事设置为已完成 |
13 | NA | 如果通过“质量门”，CI/CD 流程将部署候选版本到系统测试环境，并且运行端到端的自动化回归测试集 | |
14 | 回归/发布/集成/UAT 测试工程师 | 回归/发布/集成/UAT 测试工程师执行端到端探索式测试。如果有缺陷，就将缺陷加入产品待办列表并排列优先级 | |
15 | NA | 达到预发布状态 |
敏捷测试交付物
Sprint 内测试交付物列表
测试交付物 | 描述 |
|---|---|
测试工件 | Sprint 内测试的输出物(测试计划、测试用例、测试报告等)，并且通过测试管理工具记录，或者根据需要检入配置管理工具 |
测试自动化工件 | 自动化配套结构，包括:·Page Objects (模块/组件)·已封装的通用功能·步骤定义(如果正在使用 BDD/ATDD)·己评审的自动化脚本 |
测试数据 | 需求定义的业务数据，以及团队需要准备或提供的数据 |
缺陷 | 可能不会作为正式缺陷在缺陷管理系统中进行跟踪，但会在 Sprint 中得到处理。当需要延迟解决时，可以作为一个用户故事添加到产品待办列表中 |
虚拟服务 | 为支持 Sprint 内测试而开发的可以使用的虚拟服务 |
跨Sprint 测试交付物列表
测试交付物 | 描述 |
|---|---|
版本发布级别测试策略 | 版本发布级别的总体测试策略，定义将要进行的所有类型的测试，同时概述包括工具、度量标准和沟通计划等公共部分 |
测试工件 | 跨 Sprint 范围内测试的输出物(测试计划、测试用例、测试报告等)，并且通过测试管理工具记录，或者根据需要检入配置管理工具。 利用来自Sprint 内功能测试(不是单元测试)的可重用部分,如可重用的 PageObjects |
测试数据 | 对于跨 Sprint测试范围，团队能够很好地理解并准备或提供数据 |
缺陷 | 缺陷记录在缺陷管理系统中并进行跟踪，同时报告质量度量 |
发布测试计划 | 定义发布的测试范围、环境、依赖、资源、时间框架和退出标准 |
虚拟服务 | 为支持集成/回归测试而开发的可使用的虚拟服务 |
发布测试结束备忘录 | 测试结果和交付/质量度量的总结 |
