敏捷开发最佳实践:质量维度实践案例之接口级自动化测试

本次分享我们将继续给大家带来全新的质量维度实践案例:接口级自动化测试。

本实践节选自《2022中国企业敏捷实践白皮书》,分享者为查俊,是来自腾讯的高级研发项目经理。

问题:

版本持续迭代,关键路径上的场景持续增加,导致回归测试时长无法收敛,产品质量难以控制,挤压迭代交付容量。

问题成因:

手工测试占比太高,测试不够高效;过度追求交付速率,对技术架构治理投入不足;过度依赖测试阶段控制质量,上游研发缺乏早期看护。

敏捷实践:

自动化测试体系搭建:减少功能测试人力,置换原人数30%的专职人员进行自动化测试建设,并增加产研自测流程,按迭代T+1实现自动化覆盖。

  1. 适配范围:因当前项目轻前端重后台,场景化接口测试为主,单元测试为辅;

  2. 工具选型:使用公司内成熟用例编写框架,后期快速接入DevOps做为质量门禁和卡点;

  3. 编写规范:考虑测试资源和数据的独立性,便于后期可以快速在多环境执行,真正做到一套自动用例到处运行;

  4. 用例维护:用例持续运行数据可视化,底层异常信息标准化错误聚类,大幅减少分析维护成本。

区分特性团队和技术域团队:特性团队面向交付,技术域面向技术架构,提供公共服务、看护架构质量。

  1. 人才培养:每个技术域设置专门的值守人(兼职),日常参与迭代交付,纵深看护领域内技术架构;

  2. 公共服务:迭代技术方案横向Review,抽象公共服务解决方案,监督研发遵循执行&技术债消除;

  3. 稳定性建设:从性能排查、研发规范、灰度策略、监控告警、资损对账等维度,持续搭建质量稳定体系。

实践结果:

通过自动化测试建设,测试人力降低为原来30%左右,结合技术债的消除和对技术域的值守保证了稳定的产品质量;自动化能力的提升,使得冲刺周期中回归测试的时间从3天缩减为1天,提升了需求和价值的实际交付量。

总结

质量管理是高速持续迭代的基石,通过测试自动化技术体系的搭建,才能规模化提效;测试不应该是质量管理的“保护伞”,质量应该前移到架构规范、服务标准化,从源头就开始治理。

本案例体现了敏捷第七条和第九条原则:“可工作的软件是进度的首要度量标准。”、“坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。”

专家观点:主动消除技术欠债,在源头处保证质量

林伟丹

旭势教练深圳合伙人 敏捷变革专家

敏捷倡导迭代开发和增量交付,以便更多、更快地支撑产品和服务的尝试性实验,及早获得来自于用户和数据上的反馈,帮助企业在高度不确定的BANI时代和激烈竞争的市场环境中获得成功。

在这种短周期交付的节奏中,测试和验证的周期相当有限,如何保证研发质量和安全、又好又快地交付,面临着巨大的挑战。

解决这个挑战的秘方例如:基于更小的需求粒度进行跨职能协作,拉动需求流动减少阻碍和停滞,提升代码签入后部署价值流的自动化程度,促进敏捷团队内部的技能备份和基于瓶颈的互相补位协作,等等。

在这些方面,在腾讯查俊经理带领的团队案例中,有着良好的实践和成果。

内建质量(Build-in Quality)是当下企业中重要的质量理念,也称为在源头处保证质量(Quality at the Source),与丰田精益五原则中的尽善尽美(Perfection)也有很强关联。

对于软件开发来说,这种理念与以往以“阶段-门径”为特征的软件工程过程有显著不同,对于产品的质量,不再寄望于一个或多个单独的、长周期的后置测试阶段来保证质量,而是更积极的将质量前置(Shift Left),力图在代码写好的那一刻(或在几分钟或几小时之后),就能符合上线的质量标准,达到潜在可交付的程度。DevOps与持续交付相关的各种工程技术实践应运而生,在近些年越来越多地普及开来。

主动消除技术欠债也是持续保证系统质量的另一个重要视角。

技术欠债通过日常非最优的技术选择(迫于项目压力或工程师的能力、惰性因素)而形成,属于看不见而又产生消极影响的一类东西,需要在平时的工作过程中持续“还债”,最好通过有意识的“产能分配”,给技术类的改进留出一定百分比的研发资源;否则会逐步拖累、拖慢研发的步伐,并且对系统质量产生更大的压力。

在查俊的案例中,对于每个技术域的专人值守、对于技术方案的横向review,也都有助于减少欠债、提升效能。

推荐阅读:

Scrum 开发指南: Scrum 框架详解  |  Scrum 四个会议及正确召开方式 |  正确的计划和执行Sprint的方式 |  做好迭代计划的4大关键点 |  做好这4点让每日站会更适配敏捷团队  |  开好迭代评审会的3个关键步骤  |  为什么要召开迭代回顾会  | Scrum 3大角色及其岗位的具体职责  |  Scrum三大工件在敏捷开发中的作用  |  2022年14个最佳 Scrum 敏捷项目管理软件  |  更多 

Kanban 敏捷指南: 使用看板(Kanban)管理方法的5大好处  |  看板 VS Scrum:如何选择? |  看板和 Scrum 的混合模式适合在哪些场景使用  |  更多 

规模化敏捷: 规模化敏捷的价值及五大规模化敏捷框架  |  规模化敏捷之 Spotify 模型  |  规模化敏捷框架之LeSS框架  |  SAFe 规模化敏捷框架  |  Scrum@Scale 模型  |  敏捷项目组合管理  |  OKR与敏捷开发  | 更多 

产品管理: 如何构建合格的产品路线图  |  如何成为一个优秀的产品经理  |  敏捷路线图的重要性以及构建  |  如何构建简单有效的产品需求文档  |  利用 NPS 确定功能优先级  |  每个产品经理都需要了解的产品分析技能  |  更多 

  • 13
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值