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