0


软件质量保障体系建设

前言

从事软件测试相关工作七年,做过功能测试、自动化测试、测试开发、性能测试、专项测试,也干过一段时间技术管理。

近几年随着行业成熟度的发展,对软件测试也有了更高的要求,很多测试团队开始转变为质量保障团队。

如何从质量保障的维度去更好的为业务提供支持,是我一直在思考的事情。

整理了自己的很多笔记,结合我在工作中遇到的种种场景,我梳理出了下面这张质量保障体系思维导图,供大家参考。

思维导图

三大体系

组织

愿景

所谓的愿景,就是长期规划,我们要到哪里去的问题。一个组织或者团队,是一定要有愿景的。在软件质量保障领域,所谓的愿景概括来说就四个字:保质提效。

保质,就是在日常交付中保障软件质量,并且在长期发展过程中,不断提高软件的质量。如何评估质量是否是稳定且不断提升的,就需要引入评估体系,用事实、结果、背后的分析逻辑和数据来证明。

提效,很好理解,提高效率。怎么提高效率呢?引入ROI体系,从交付时间、耗用资源、团队成长方面着手。

目标

有了愿景,还要将其拆分为不同的目标。行业在变,组织架构在变,因此目标也要跟随整体的变化而调整。

不同的企业在不同阶段有不同的侧重点和诉求。你不能要求一个初创企业要啥啥都有,也不能要求BAT啥都凑合。这是一个平衡和抉择的过程,可以参考CMMI模型来思考这一点。

规则

这里的规则不是强制要求大家一定要做什么,而是为了避免某些方式对团队和企业带来不好的影响。常见的规则比如:周报、信息同步机制、反馈机制

文化

谈到文化这一块,一直是很务虚的东西,很多同学对之嗤之以鼻,2020年之前我也是这么想的。

20年读了一本书:《重新定义公司:Google是如何运营的》。里面对企业文化这一部分做了很经典的解释:企业文化就是指导员工面临艰难选择时,做正确的选择。

管理

团队管理方面,我将其分为了下面四个体系,每个体系都包含不同的内容。

相关内容,可参考我之前的文章:从技术专家到技术管理,我对管理的思考

业务体系

如果团队规模较小,业务也不复杂,可以暂时不用拆分。但是当人数超过10人&业务开始划分不同团队时候,就要考虑做业务拆分了。

这里的业务拆分指的是根据组织架构将测试同学分为不同的组,每个组有一个小组长或team leader,提高管理效率,做好信息同步和反馈机制。

避免自己成为团队的瓶颈,从繁杂的管理中抽身出来,去思考并解决更高维度的问题。

资源体系

在团队管理中,无论是人力、设备还是时间,都可以纳入资源管理体系中。我将其分为了如下三个部分:

1、人力模型

  • 新人目标:新人入职如何落地?如何快速适应业务迭代节奏?如何设定合理的目标来达成预期结果?
  • 转正述职:招聘、新人培养都需要成本投入,设定合理明确的转正评估机制,结合上述的新人目标,可以帮助新人更好的落地。

2、能力模型

  • 成长模型:工作一方面为了金钱物质回报,另一方面也是希望能够借助平台获得自我成长。设定成长目标和模型,可以帮助员工在不同的阶段知道自己该向什么方向努力,达成不同阶段的不同目标,这是没一个管理者都需要考虑的事情。
  • 胜任力模型:一个团队的组织结构,从初级的倒T型,经过金字塔模型,最终演变成纺锥型。在不同阶段,随着组织结构的演变,处在不同阶段和层级的员工,需要设定不同的级别和胜任评估体系,助力团队跟随公司不断发展,适应组织结构的变化。一般来说,可以从工作经验、技术、业务熟悉度、项目推动能力、沟通协同方面来设定评估指标。

3、资产管理

  • 云端资产:现在大多数互联网公司,都采用了云服务。对于质量保障团队来说,测试环境及内部自建技术平台涉及的云端资产,都需要通过一定的手段管理起来。当然一般这种事在运维团队,有CMDB体系来进行管理,可进行参考。
  • 硬件资产:这里的硬件资产包括移动端测试机&pad等设备,当然可能也包括用来做兼容测试而采购的相关服务等设施。还有一点,员工办公所使用的包含电脑显示器等设备,一般会有IT部门来专门登记管理。如果没有,建议做好统计,便于员工入离职交接等。

知识体系

这里的知识体系,主要指的是团队内部的能力建设和沉淀,主要包含如下几个方面:

1、技术博客

无论是工作职场中还是和同行交流中,我一向是比较鼓励大家写技术博客的。

这样无论是对个人知识的梳理总结,还是团队的技术能力沉淀都是有很大帮助的。长期以往坚持下来,还能形成品牌向外宣传,这也是吸引优秀候选人的一个方式。

2、业务串讲:前面提到随着企业的发展,业务规模越来越大也越来越复杂,业务串讲就显得很有必要。优点如下:

  • 帮助不同team的同学了解不同的业务,便于日常工作理解;
  • 遇到不同团队协同工作时,更明确交接的业务边界,提供沟通效率;
  • 沉淀成业务知识库,可以让其他团队的同学&新入职的同学快速了解,离入职交接也更方便;

3、内部分享:这里的内部分享,指的是技术部门内部,上述的技术博客和业务串讲&知识库,都可以作为分享的素材来宣讲。

一方面可以让更多的同学了解到不同的知识,另一方面加深团队的影响力,这样有助于日常工作的开展。也能在一定程度上培养团队同学的沟通和表达能力。

4、外部培训:这个主要指下面几方面:

  • 联合开源社区,合作举办技术沙龙、座谈会等类似的活动;
  • 重量级的技术大会上做主题分享,主要目的是价值宣导和品牌影响力建设;

评估体系

如何理解这里的评估体系?围绕上文提到的保质提效相关的点,来分类进行评估。

1、问题管理

  • 测试过程中遇到的BUG,分门别类,阶段性的总结梳理,输出质量保障参考手册/SOP;

2、版本管理

  • 版本管理主要涵盖每个版本的服务发版次数、冒烟通过率、bug的reopen率、上线质量等因素。每个版本结束,除了向上做汇报,内部的复盘总结优化,也是很重要的。

3、项目管理

  • 这里的项目管理,可以理解为PMO这个岗位做的一些事情,包括进度、风险、资源、deadline等因素。实际上无论是版本发布、和版本迭代同步进行的跨版本需求以及内部的一些独立项目,都可以采用这种方式来管理,总体上还是为了提高资源利用率以及风险前置。

4、效率管理

  • 效率管理,我们之前的做法,一方面是通过调查问卷的方式,在部门内部开展调查,获取日常工作中影响工作效率的点,归纳汇总进行专项优化。另一方面,随着团队规模的不断扩大,整体的效率问题也会变成团队成长的一大问题,需要时刻重视。

专项

自动化体系

自动化体系的建设,目前来说在绝大多数稍有规模的互联网公司,都有不同的应用。

有UI自动化、APP自动化、接口自动化、单测自动化、埋点自动化以及自动化打包发布校验等方式。

最初的目标都是提高效率,降低手工的成本,让工作的个体突出发挥自己的思考能力,而不是手工的体力劳动。

在自动化体系建设中,主要需要考虑如下几点:

  • 场景&用例&执行:这里需要注意的是场景的覆盖、用例的筛选以及执行效率;
  • 框架&数据&CICD:人多了,需要注意避免团队内部造轮子,撸很多自动化框架。我个人对这点的理解是有成熟开源框架的,别自己造轮子。内部已有的,评估是否需要优化,而不是推到重构。自动化体系中,CICD是至关重要的一环,别忘记自动化的初衷。
  • 提效&反馈&参与:自动化最终还是要解决的是效率问题,如上文提到的效率管理,需要持续不断的获得反馈,然后改进优化。说到参与,很多公司是自动化和功能测试工程师做了区分,实际上如果为了团队的整体成长,需要全员参与进来,有参与感,员工才能有收获和满足感。否则大部分人只靠工作本身的内容,是很难做到主动提升自己的。

防资损体系

什么叫资损?造成公司&客户资产损失的都算。比如公司发优惠券,多发且被用户使用了,造成公司成本支出。

比如用户的优惠券满足场景但无法在支付中使用,用户有了资损,实际上还是公司买单。还有部分舆情方面的东西,比如某个外部消息导致公司上了热搜,外部对公司的评价变差,对企业品牌造成不良影响。

我们之前的做法是线上监控及时告警,专人专群处理。还有线上涉及资损的场景进行针对性校验,尽可能降低资损的成本以及造成的影响。

质量大盘体系

这里的质量大盘,大家理解为一个可视化的监控即可。即把上面我们提到的各项规则和措施,通过数据量化的方式管控起来,便于做决策。

性能测试体系

性能测试体系,由于之前的文章已经详细介绍过,这里不过多赘述,大家可以参考之前的文章。

文章链接:性能测试体系建设演进之路

稳定性治理体系

稳定性是一个很大的范畴,在质量保障体系中,稳定性的建设,主要集中在如下几点:

  • 测试过程监控(如自动化通过率&冒烟通过率&性能容量变化趋势等)
  • 测试环境稳定性治理(特别是有多套环境多个项目版本交叉使用以及频繁发布)
  • 线上服务可用性监控(质量保障不仅只关注测试环境,线上的稳定性也至关重要)

写在最后

总感觉自己写了很多,又好像有很多内容无法一一表达。关于本篇文章中提到的部分内容,如稳定性治理,会在后续的文章中进行详细介绍。

本文仅供参考,请知悉。

如果本文对你有帮助,别忘记给我个3连 ,点赞,转发,评论,

咱们下期见!答案获取方式:已赞 已评 已关~

学习更多JAVA知识与技巧,关注与私信博主(666)


本文转载自: https://blog.csdn.net/javalingyu/article/details/124947940
版权归原作者 java领域 所有, 如有侵权,请联系我们删除。

“软件质量保障体系建设”的评论:

还没有评论