不知不觉去 Z 厂已经半年了,恰逢前几天成转正述职,趁着这个机会,做个阶段性总结.
Z 厂前: 在一家 K12 教育公司 (简称 S 厂),定位是测试开发岗位,主要负责效能工具研发、自动化、服务端压测、测试环境治理,带 5 人小团队.S 厂的测试和测开分发的,测开不负责业务,所以到最后会感觉到脱离业务比较多,S 厂离职后面试很吃亏,比如: 美团、阿里、便利峰,技术能力没啥问题,主要是简历中无法体现所负责的业务价值.
Z 厂: 目前负责某个业务线,10 人团队左右.Z 厂目前没有专职工具测开,只有业务测开和外包测试.
主要工作内容: 业务线质量把控、过程改进、提效自动化、横向工具建设、团队管理.
Z 厂的测试质量保障体系是专业的,测试左移和测试右移都做很好.业务线的 QA 能力都很强,包括业务能力和工具开发能力.很多平台都是基于业务痛点研发出来,扩散到整个质量保障团队.
在 S 厂没有一套完整的测试质量保障体系、沉淀的也少.包括我自己做的东西也是比较散点的、不成体系.
比如: 自动化框架研发,是否能帮助团队提高效率.平台化建设,是否能解决 QA 的痛点.
从来没思考过一个好的"测试质量保障体系"应该具备什么? 我们所过的工具价值是什么?
Z 厂,对于业务线测试负责人,需要能梳理并制定当前负责业务线的"测试质量保障体系".考察分析现状能力、排队问题能力、拆节问题能力."测试质量保障体系"绝对不是所有都可以用自动化或者平台化解决的,很多还是需要靠人来保障,包括: 沟通、协作、沉淀.
介绍下从不同方面的"能力提升"
上面这张图,入职半个月基于痛点梳, 可以参考: wiki 文档、线上事故、用户反馈.只有发现痛点,方可制定有效的方案.
一般业务团队,从业务线负责人规划全年 OKR,然后拆解到每季度 OKR.产品是研发和测试的上游,提前知道产品规划,可以更好根据业务特性制定保障手段和人员储备.
产品规划,一般是基于数据指标为导向,比如 XX 提升多少日活、XX 提高多少订单转化.
在了解业务一段时间后,梳理一份产品架构图.好处是了解产品逻辑、业务边界.
技术方面,了解端到端的架构设计.
业务线后端 go 语言偏多,也简单学了下 golang,代码逻辑能看懂并且代码在本地搭建完成,研发提交代码后,基本上也会看下 code diff.
QA 自己写的后端服务是 java + springboot 这一套,以前是走 python + flask 这一套的.不过 QA 写的平台都没啥太难的业务逻辑,接口增删改查比较多,数据库交互 mysql、redis 到头了.
vue 这块,用组件比较多,包括数据监听、数据计算、路由跳转,promise 的一些使用.毕竟不是专业的前端,写页面够用就行.
分三个子方向,交给合适的同学,关键节点结果.
明确考核指标,过程指标: bug 规范、项目状态流转,结果指标: 线上事故、漏侧率.
Z 厂的文化,是喜欢从业务团队内部孵化一套流程和工具,内部先落地并能扩大影响力到其他团队.
这里就是涉及和其他团队的共建或者协作,如果想主 owner 这个项目,必须要体现 leadership.在这个项目中,你来定方案和计划,让其他参与人向你回报进度,并且最后能拿到结果.
复盘不是一种形式,而是更好的避免问题再次发生.
很多复盘都是催生出 QA 的后续保障措施,比如服务端接口返回某个字段为空,导致客户端崩溃.
QA 可以进行线上监控巡检、客户端可以做接口健壮性测试.
另外就是项目异常复盘,比如项目 delay、需要变更多、提测质量差,可能不会影响结果,但是需要得出改进措施,才能让项目有更好的质量保障.
从 S 厂的全职测开到 Z 厂的业务测开的变化,无论从岗位、方向、能力都有很多变化和提升,越发认为测试人员往后发展,综合能力必须要强,才能有更好的发展.