7年测试经验分享 —— 我在 Z 厂的6个月工作总结，送给迷茫中的你

▌背景

不知不觉去 Z 厂已经半年了,恰逢前几天成转正述职,趁着这个机会,做个阶段性总结。

▌工作职能变化

Z 厂前: 在一家 K12 教育公司 (简称 S 厂),定位是测试开发岗位,主要负责效能工具研发、自动化、服务端压测、测试环境治理,带 5 人小团队.S 厂的测试和测开分发的,测开不负责业务,所以到最后会感觉到脱离业务比较多,S 厂离职后面试很吃亏,比如: 美团、阿里、便利峰,技术能力没啥问题,主要是简历中无法体现所负责的业务价值。

Z 厂: 目前负责某个业务线,10 人团队左右。Z 厂目前没有专职工具测开,只有业务测开和外包测试。

主要工作内容: 业务线质量把控、过程改进、提效自动化、横向工具建设、团队管理。

Z 厂的测试质量保障体系是专业的,测试左移和测试右移都做很好。业务线的 QA 能力都很强,包括业务能力和工具开发能力。很多平台都是基于业务痛点研发出来,扩散到整个质量保障团队。

▌认知的改变

在 S 厂没有一套完整的测试质量保障体系、沉淀的也少。包括我自己做的东西也是比较散点的、不成体系。

比如: 自动化框架研发,是否能帮助团队提高效率。平台化建设,是否能解决 QA 的痛点。从来没思考过一个好的"测试质量保障体系"应该具备什么? 我们所过的工具价值是什么?

Z 厂,对于业务线测试负责人,需要能梳理并制定当前负责业务线的"测试质量保障体系"。考察分析现状能力、排队问题能力、拆节问题能力。"测试质量保障体系"绝对不是所有都可以用自动化或者平台化解决的,很多还是需要靠人来保障,包括: 沟通、协作、沉淀。

▌能力提升

介绍下从不同方面的"能力提升"

1.发现问题能力

上面这张图,入职半个月基于痛点梳, 可以参考: wiki 文档、线上事故、用户反馈.只有发现痛点,方可制定有效的方案。

2.解决问题能力

• 提出问题: 在工作经常见过,吐槽内部某个工具或者自动化框架不好用,但是往往就无下文,缺乏可优化的方案,并改进问题

• 找到适合的人: 提出问题需要找到问题的接口人或者 on call 群,切勿把问题抛到大群

• 方案落地: 找到对应的人,并且诉说痛点.解决问题不一定是自己,让系统接口人帮忙解决,也是一种可落地的方案

• 问题闭环: 提出问题后,一定让对接定一个 DDL 完成时间放到备忘录中,定时 check 结果

3.业务能力

1. 产品规划

一般业务团队,从业务线负责人规划全年 OKR,然后拆解到每季度 OKR.产品是研发和测试的上游,提前知道产品规划,可以更好根据业务特性制定保障手段和人员储备。

2. 产品指标

产品规划,一般是基于数据指标为导向,比如 XX 提升多少日活、XX 提高多少订单转化。

3. 产品架构

在了解业务一段时间后,梳理一份产品架构图.好处是了解产品逻辑、业务边界。

技术方面,了解端到端的架构设计。

4.技术能力

客户端稳定性建设

客户端专项能力

代码能力

业务线后端 go 语言偏多,也简单学了下 golang,代码逻辑能看懂并且代码在本地搭建完成,研发提交代码后,基本上也会看下 code diff。

QA 自己写的后端服务是 java + springboot 这一套,以前是走 python + flask 这一套的。不过 QA 写的平台都没啥太难的业务逻辑,接口增删改查比较多,数据库交互 mysql、redis 到头了。

vue 这块,用组件比较多,包括数据监听、数据计算、路由跳转,promise 的一些使用。毕竟不是专业的前端,写页面够用就行。

5.管理能力

分三个子方向,交给合适的同学,关键节点结果。

明确考核指标,过程指标: bug 规范、项目状态流转,结果指标: 线上事故、漏侧率。

6.leader 能力

Z 厂的文化,是喜欢从业务团队内部孵化一套流程和工具,内部先落地并能扩大影响力到其他团队。

这里就是涉及和其他团队的共建或者协作,如果想主 owner 这个项目,必须要体现 leadership。在这个项目中,你来定方案和计划,让其他参与人向你回报进度,并且最后能拿到结果。

7.文档能力

• 业务文档: 对业务上的逻辑理解,梳理出来落到 wiki 上.工具的使用教程,写到公共目录,会极大提高自己包括组员的工作效率和认知

• 技术文档: 数据分析、解决背景、方案调研、方案设计、落地预期

• 阶段总结: 项目总结、项目复盘、OKR 总结

8.沟通能力

• 业务沟通: 日常和产品、研发的沟通,拉会必须有参会背景和会议结论

• 团队内沟通: 日常 ONE ONE,基于某个问题沟通.沟通是否有 feedback,对方是否明确了指令

• 跨团队沟通: 简单阐述问题背景,对方需要怎么配合、业务边界划分

9.复盘总结能力

复盘不是一种形式,而是更好的避免问题再次发生

• 问题阶段: 注入时间、发生时间、止损时间

• 改进措施: 明确到人和 DDL 时间

很多复盘都是催生出 QA 的后续保障措施,比如服务端接口返回某个字段为空,导致客户端崩溃。

QA 可以进行线上监控巡检、客户端可以做接口健壮性测试。

另外就是项目异常复盘,比如项目 delay、需要变更多、提测质量差,可能不会影响结果,但是需要得出改进措施,才能让项目有更好的质量保障。

▌小结

从 S 厂的全职测开到 Z 厂的业务测开的变化,无论从岗位、方向、能力都有很多变化和提升,越发认为测试人员往后发展,综合能力必须要强,才能有更好的发展。

---

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走

这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助…….