软件质量保障体系建设
https://www.cnblogs.com/imyalost/p/15116840.html
从事软件测试相关工作七年,做过功能测试、自动化测试、测试开发、性能测试、专项测试,也干过一段时间技术管理。
近几年随着行业成熟度的发展,对软件测试也有了更高的要求,很多测试团队开始转变为质量保障团队。
如何从质量保障的维度去更好的为业务提供支持,是我一直在思考的事情。
整理了自己的很多笔记,结合我在工作中遇到的种种场景,我梳理出了下面这张质量保障体系思维导图,供大家参考。
思维导图
三大体系
组织
愿景
所谓的愿景,就是长期规划,我们要到哪里去的问题。一个组织或者团队,是一定要有愿景的。在软件质量保障领域,所谓的愿景概括来说就四个字:保质提效。
保质,就是在日常交付中保障软件质量,并且在长期发展过程中,不断提高软件的质量。如何评估质量是否是稳定且不断提升的,就需要引入评估体系,用事实、结果、背后的分析逻辑和数据来证明。
提效,很好理解,提高效率。怎么提高效率呢?引入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是至关重要的一环,别忘记自动化的初衷。
- 提效&反馈&参与:自动化最终还是要解决的是效率问题,如上文提到的效率管理,需要持续不断的获得反馈,然后改进优化。说到参与,很多公司是自动化和功能测试工程师做了区分,实际上如果为了团队的整体成长,需要全员参与进来,有参与感,员工才能有收获和满足感。否则大部分人只靠工作本身的内容,是很难做到主动提升自己的。
防资损体系
什么叫资损?造成公司&客户资产损失的都算。比如公司发优惠券,多发且被用户使用了,造成公司成本支出。
比如用户的优惠券满足场景但无法在支付中使用,用户有了资损,实际上还是公司买单。还有部分舆情方面的东西,比如某个外部消息导致公司上了热搜,外部对公司的评价变差,对企业品牌造成不良影响。
我们之前的做法是线上监控及时告警,专人专群处理。还有线上涉及资损的场景进行针对性校验,尽可能降低资损的成本以及造成的影响。
质量大盘体系
这里的质量大盘,大家理解为一个可视化的监控即可。即把上面我们提到的各项规则和措施,通过数据量化的方式管控起来,便于做决策。
性能测试体系
性能测试体系,由于之前的文章已经详细介绍过,这里不过多赘述,大家可以参考之前的文章。
文章链接:性能测试体系建设演进之路
稳定性治理体系
稳定性是一个很大的范畴,在质量保障体系中,稳定性的建设,主要集中在如下几点:
- 测试过程监控(如自动化通过率&冒烟通过率&性能容量变化趋势等)
- 测试环境稳定性治理(特别是有多套环境多个项目版本交叉使用以及频繁发布)
- 线上服务可用性监控(质量保障不仅只关注测试环境,线上的稳定性也至关重要)