华为 孔德晋 - 大规模敏捷下的测试管理

2020-02-27 256浏览

  • 1.大规模敏捷下 的测试管理
  • 2.• 敏捷与测试 • 组织变革与敏捷文化建设 • 流程再造与基础设施 • 测试管理的挑战 • 总结
  • 3.敏捷与测试 • 互联网行业，ICT行业竞争激烈 • 软件，越来越需要客户快速反馈 • 瀑布模式向敏捷模式转变 • 核心：快 天 下 武 功 唯 快 不 破 • 测试需要在快和高质量之间进行平衡
  • 4.敏捷与测试
  • 5.敏捷与测试 对敏捷的整体认识：理念一致、流派众多、优秀实践丰富 理念 敏捷宣言 12条原则 流派 Crystal XP Scrum ASD FDD DSDM 精益开发 DAD RUP … LeSS SAFe 优秀实践 持续 交付 滚动 排序 特性 团队
  • 6.敏捷与测试 • 敏捷宣言遵循的十二项原则，在测试人员看来重要的是： • 协作与反馈 • 开放 • 承诺 • 简单 • 专注
  • 7.敏捷与测试 • 敏捷测试：持续地对软件质量问题进行及时地反馈。
  • 8.敏捷与测试
  • 9.敏捷与测试 • 惯性作用，文化和思维改变很难 • 测试人员的地方保护主义，改变后没有存在感 • 管理者不重视测试，开发人员不想做测试，能力弱 • 测试人员向左向右转的能力不足 • 开发与专业测试人员配比的矛盾 • 跨团队的大规模敏捷，沟通成本、返工成本都很高 • 过程比较混乱，项目进度紧张，迭代内任务很赶 • 自动化测试能力、水平低，自动化率低，有效性差 • 测试充分性到底如何？ • 容易回到传统的测试
  • 10.组织变革与敏捷文化建设 技术和 业务对齐 管控 实践 敏捷转型 框架 绩效 组织 文化 过程 敏捷转型7个方面优先级 中小规模 中大规模 超大规模 实践 组织 流程 绩效 管控 文化 技术与业务对齐 阶段1 1 2 2 阶段2 1 2 2 1 阶段3 2 1 1 2 3 1 2 阶段4 3 1 2 2 1 1 2 阶段5 4 3 3 1 2 1 2  大规模敏捷转型是系统工程，覆盖7大方面：实践、绩效、组织、流程、文化、管控、技术和业务对齐  根据敏捷转型的不同规模和阶段，敏捷转型框架的7个方面引入的优先级不一样
  • 11.组织变革与敏捷文化建设 Director Group 主管：Director Team A 主管：manager (10人左右) Team B 主管：manager (10人左右) Team C …... Dev 5人 Test 5人 Rel 1人（Opt） Dev Test Rel Dev Test Rel
  • 12.组织变革与敏捷文化建设 Direct Group 60 人 QA 6-10 Team 人 SDE-T QAE QAE QAE Service Team A (SDM) 2-pizza (8-12人) SDE SDE SDE-T QAE Service Team B (SDM) …... SDE SDE SDE-T QAE
  • 13.组织变革与敏捷文化建设 120 System Design 某产品线 20 Project Office 1XXX 5XX GBSC 120 Integration & Verification 100 System Design 50 Project Office 200 Software Design &Test 5 Test Methodology 26 Test Tools 14 Test Management 45 Test Designers 150 Integration & Verification 60 Testers
  • 14.组织变革与敏捷文化建设 Portfolio Program A Program B Test Team 核心价值：  对齐  质量  透明  项目执行  众多团队协同 Team … Team1 Team2 Team 3 Test A Test B Test A+B 大规模敏捷的测试组织形式
  • 15.组织变革与敏捷文化建设 • 尽早和持续地开展测试 • 基于风险（质量与进度平衡）的测试策略 • 测试计划、设计和执行力求简单 • 能及时完成对软件质量全面评估 • 软件本身是测试研究和分析的主要对象 • 在满足要求的质量下，测试进行越快越好 • 测试的工匠精神：测试设计、自动化测试
  • 16.组织变革与敏捷文化建设 • 让组织真正敏捷起来 • 站在研发的高度看测试 • 基层团队自治 • 更早更频繁的release • 以经济效益驱动敏捷测试 • 文化改变只能循序渐进
  • 17.组织变革与敏捷文化建设 一些公司的实践： 微软：取消SDET 亚马逊：微服务化 谷歌：XFT中的TestOwner
  • 18.流程再造与基础设施 课堂练习：精益看板演练  角色及职责介绍： • 业务分析师：把便利贴撕下来交给架构设计师。 • 架构设计师：在便利贴的左下角画一个圆形（一圆硬币大小，涂满），贴在看板“架构设计、已完成”列。 • 软件设计师：从看板上取下便利贴，在右上角画一个正方形（边长1CM大小，涂满），贴在看板“软件设计 已完成”列。 • 开发人员：我看板上取下便利贴，在中间画一个五角星型（涂满，要对称），贴在看板“开发 已完成”列。 • 测试人员：保证产品符合质量标准，将合格产品交给客户，从看板上取下卡片，检查是否按照要求涂好，如 合格交给项目经理统计，如不合格则打回 • 项目经理：给生产过程计时和统筹。客户（教师）：最终接受制成品。 • （每组派一个观察员，到其他组观察，确保按照规则开展） 总共三轮迭代，每轮迭代5分钟，迭代完后有2分钟时间回顾 迭代一：按照每五个完成（业务分析师撕下五张便利贴，架构师涂满五个后贴在看板上。。。 迭代二：按照单个完成（WIP Limit=1），每完成一个就可以往下传 迭代三：项目组自行讨论 结果统计 迭代1 迭代2 第一个产品交付时间 完成的产品 合格的产品 未完成的产品（WIP） 迭代3 18
  • 19.流程再造与基础设施 • 分层分级的持续集成和持续的并行测试 XX侧流水线 个人级构建 项目级构建 版本级构建 本地开发 特性分支(仓) 模块发布 编译打包 静态检查 UT 环境申请搭建 功能自验 环境释放 代码提交 个人仓 编译打包 静态检查 环境申请搭建 LLT 环境释放 发起MR Review dev分支 环境申请建 平台门槛 业务门槛 环境释放 版本归档 发起MR bugfix分支 归档服务器 α环境供给 α环境供给 β环境供给 α环境池 β环境池 公共服务池 伪镜像包入库 组件制品仓库 个人级构建 本地开发 静态检查 编译出包 环境更新 新特性验证 YY侧流水线 服务构建 编译出包 静态检查 环境更新 套件门槛测试 部件脚本环境更新 版本级构建 版本门槛测试 CP4 版本归档库 升级α 正式版本发布 环境 升级β环境 α环境供给 α环境供给 β环境供给 环境供给系统 α环境池 公共服务池 β环境池
  • 20.流程再造与基础设施 • DevOps的闭环敏捷 --Market-Product-Develop-Test-Operation-Customer --向前连接市场团队和产品经理 --向后连接客服团队 --测试人员会和产品经理同时获得到来自市场的产品反馈， 这些反馈会变成测试需求融入测试活动
  • 21.流程再造与基础设施 • 迭代过程中的关键活动 – 每人手上的问题单不超过2个 – 问题解决优于新需求开发 – 测试人员是直接给开发人员提单 – 通过的新增特性用例发生在每周，而不是迭代后期 – 系统需求拆分后仍然是系统需求，而不是模块功能点
  • 22.流程再造与基础设施 • 代码和架构的内在质量 • 持续重构，小规模重构 • UTDD： • ATDD： BDD（Behavior Driven Development）：软件行为 EDD（Example Driven Development）：特定实例数据 FDD（Feature Driven Development）：特性 CDCD（Consumer Driven Contract Development）：Web Service API契约
  • 23.流程再造与基础设施 • 单元测试 • 代码检视
  • 24.流程再造与基础设施 • 基础设施基本要求： 1、快：代码编译、静态检查、构建、自动化测试、覆盖率、部署；实时 度量 2、可视：全员、全面，KPI、计划、目标、需求、排序、缺陷、运维 3、基础设施即代码：基础设施的自动搭建以API形式提供
  • 25.流程再造与基础设施 • Docker：容器 一致性、可靠性 • K8：容器编排 复制、故障转移
  • 26.流程再造与基础设施 • 客户反馈系统 客户可选择性加入 自动的反馈收集组件 统计和聚类分析 有效转化客户反馈为行动 很好的可视性 每天实施
  • 27.测试管理的挑战 • xFT（全功能）团队的组建 分层测试 产品集成测试 系统专项测试 团队 测试人数建议 占比 xFT 每个特性组1-2人 SIT 特性集成、专项系 统测试人员 总人 数 20-40% 60-80% 100% 人选 1-3年 专业测试技能 特性集成测试 特性功能测试 特性专项测试 UT/IT xFT团队： 1、测试策略、测试方案的设计能力，主要以TC及特性Owner为主要掌握，TC赋能。 2、测试用例的设计能力，全员必须掌握等价类和边界值，偏白盒、灰盒。 3、测试用例的执行能力，全员必须掌握，要求SDV的自动化测试，尽量贴近开发使用习惯。 SIT团队： 1、测试策略、测试方案、测试用例、测试执行，为xFT团队赋能，明确具体要求。 2、自动化框架分层搭建，SDV的自动化框架贴近开发，方便掌握，方便执行；SIT的自动化框 架瞄准端到端场景。 3、安全、性能、可靠性等专项测试能力提升。 4、功能场景，站在最终用户的角度思考问题。 5、测试技术规划，xFT团队和SIT团队的，都由SIT团队负责。
  • 28.测试管理的挑战 • xFT团队的测试赋能 培训+实战演练+及时评优 测试活动主体 测试设计 测试执行 测试管理 需掌握能力 测试策略制定能力 特性测试方案设计能力 特性测试用例设计能力 自动化建模设计能力 安全专项测试设计能力 可靠性专项测试设计能力 测试用例管理工具使用能力 测试用例执行能力 测试工具使用能力 自动化脚本写作能力 各专项用例执行要求及技巧 特性测试质量评估能力 测试报告输出能力 测试过程管理能力 掌握人员 TC/项目经理 TC TC/特性Owner TC TC TC 全员 全员 全员 全员 TC/特性Owner TC/特性Owner TC/项目经理 TC/项目经理 培训方式 集中讲解+实战 集中讲解+实战 集中讲解+实战 集中讲解+实战 要点讲解+实战 要点讲解+实战 集中讲解+实战 实战 集中讲解+实战 集中讲解+实战 实战 集中讲解+实战 集中讲解+实战 贴身辅导+实战
  • 29.测试管理的挑战 • 五星测试认证计划 级别 级别1 级别2 级别3 级别4 级别5 要求 使用测试覆盖率工具。 使用持续集成。 测试分级为小型、中型、大型。 明确标记哪些测试是非确定性的测试 创建冒烟测试集合。 如果有测试运行结果为红色就不会做发布。 在每次代码提交之前都要求通过冒烟测试。 各种类型测试的整理增量覆盖率都大于50%。 小型测试的量覆盖率要大于10%。 每一个功能特性至少有一个与之对应的集成测试用例。 所有重要的代码变更都要经过测试。 小型测试的增量覆盖率要大于50%。 新增的重要功能都要经过集成测试的验证。 在提交任何新代码之前都会自动运行冒烟测试。 冒烟测试必须在30分钟内运行完毕。 没有不确定性的测试。 总体测试覆盖率应该不小于40%。 所有重要的功能都应该被集成测试验证到。 对每一个重要的缺陷修复都要增加一个测试用例与之对应。 积极使用可用的代码分析工具。 总体测试覆盖率不低于60%。 小型测试的代码覆盖率应该不小于40%？ Owner X秋鹏 测试成 熟度评 估等级 二星 持续 集成 三星 SDV测 试覆盖 新增用 例自动 化率 转SIT 成功率 流出缺 陷 三星 二星 五星 二星 X宏飞 一星 三星 三星 三星 一星 一星 X波 一星 一星 二星 二星 一星 二星 X志杰 二星 三星 三星 三星 五星 二星 X世岩 三星 三星 三星 三星 五星 三星
  • 30.测试管理的挑战 • 过程资产管理 测试方案 xFT前 xFT后 变化点说明 测试方案模板 按阶段给出定制的测试方案模板： 测试方案包含SDV、SIT各阶段的测试内容；特性测试方案模板：只包含特性级的测试设计； 测试模板的维护由SIT的测试设计团队负责。SIT的测试方案模板：SIT场景和SIT专项内容； 测试模板的维护由SIT的测试设计团队负责。 责任主体无变化， 测试方案模板依 据不同阶段的测 试范围进行划分。 测试方案 SIT的测试设计团队、测试设计人员负责版 xFT团队负责所有SDV测试方案输出； 本SDV、SIT测试方案的输出。 SIT团队负责SIT测试方案的输出。 责任主体发生变 化，内容和质量 要求无变化。 测试用例 SIT的测试执行团队负责SDV、SIT的测试用 xFT团队负责所有SDV测试用例输出; 例输出。 SIT团队负责SIT测试用例的输出。 责任主体发生变 化，内容和质量 要求无变化。 自动化脚本 SIT的测试执行团队负责测试用例的自动化 脚本开发和入自动化工厂。 xSS建FIITTT。团 的团队 自队负 动负责 化责S团SIDT队测V，测试负试用责用例S例的D的自V和自动S动化IT化的脚脚自本本动开开化发发测和和试上上框工工架厂厂搭；；责化要任，求主内无体容变发和化生质。变量
  • 31.• 可测试性 1、可观察 2、可控制 3、可度量 测试管理的挑战 一个迭代中系统功能的自动化用例占回归测试的比重
  • 32.测试管理的挑战 • 质量管理 质量的衡量标准不是 – 发现了多少个bug； – 解决了多少个Bug; 质量的衡量标准是 – 从哪些角度设计了测试用例 – 用例有多少，通过了多少 – 未通过的用例影响是什么 – 用例自动化了多少 • 缺陷管理 xFT团队内，bug是否需要跟踪 xFT和测试团队，对下游过来的bug单，谁来回归 转测试之后的bug单，能否在每日构建的版本回归
  • 33.测试管理的挑战 • 计划管理 出入口准则 范围与优先级 效率与风险的平衡 工作量估算，资源、进度安排 • 风险管理 人员能力 范围 场景 • 环境管理 基础设施（硬件、网络、支撑软件、SUT）：标准化、管理的自动化 数据
  • 34.测试管理的挑战 • 测试右移 模拟测试 镜像测试 测试用例规模 部署验证测试 编码 build release Deploy 在线测试 A/B测试、灰度发布 真实环境下的测试 仿真场景 抽象场景 单个测试场景规模 验收/体验场景 E2E测试 --整个系统的行为，而不是具体的实现细节 --系统中不能被细粒度测试保障的质量评估 --每个重要的use case，都要对应的E2E测试 --要花1/4以上的精力去确保E2E测试的充分 --方便E2E测试的问题定位，需要在日志方面的可测试性提升 在线场景
  • 35.测试管理的挑战 • 测试右移：Persona 对用户的目标、行为、观点进行抽象 测试时的共情
  • 36.测试管理的挑战 策划:访谈问题 用户描述维度 访谈用户列表 局点档案模板 1_初 始准 备 访谈用户 2_收 收集局点信息 集用 采用测试设计 工程方法设计 用例 6_测 试设 计 户信 息 与时俱进， 持续刷新 3_用 户信 息建 模 用户信息亲和图 刷新用户描述维度 以用户的目标 为出发点，讲 述用户故事 分析测试策略 5_分 析用 户测 试场 景 4_创 建 perso na 有层次的抽象： 角色自然属性、 使用产品的行 为特性
  • 37.总结 • 全团队对测试与质量负责，XFT团队设立Test Owner • 具备敏捷测试思维，决策去中心化，释放员工的激情 • 工匠精神：100%回归测试自动化、ET • 加强基础设施建设，和持续构建、部署、在线监控等无缝集 成 • 持续向研发团队提供质量反馈、获得用户反馈 • 必须有经济视角，限制WIP，减少批处理量，持续优化测试， 缩短测试周期 • 测试右移，代表客户验证，而不是验证需求本身
  • 38.Q&A 请备注：姓名 公司 欢迎交流软件测试， 跑步的话题 部门的微信公众号 软件质量报道：朱少民老师的公众号 软件质量、软件测试有深入的理解 38