职业经验 我在 Z 厂的半年工作总结

xinxi · 2022年04月04日 · 最后由 Adolph 回复于 2022年12月08日 · 46466 次阅读
本帖已被设为精华帖!

背景

不知不觉去 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 规范、项目状态流转,结果指标: 线上事故、漏侧率.

leader 能力

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

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

文档能力

  • 业务文档: 对业务上的逻辑理解,梳理出来落到 wiki 上.工具的使用教程,写到公共目录,会极大提高自己包括组员的工作效率和认知.
  • 技术文档: 数据分析、解决背景、方案调研、方案设计、落地预期.
  • 阶段总结: 项目总结、项目复盘、OKR 总结

沟通能力

  • 业务沟通: 日常和产品、研发的沟通,拉会必须有参会背景和会议结论.
  • 团队内沟通: 日常 ONE ONE,基于某个问题沟通.沟通是否有 feedback,对方是否明确了指令.
  • 跨团队沟通: 简单阐述问题背景,对方需要怎么配合、业务边界划分.

复盘总结能力

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

  • 问题阶段: 注入时间、发生时间、止损时间.
  • 改进措施: 明确到人和 DDL 时间.

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

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

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

小结

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

共收到 20 条回复 时间 点赞

很赞的思考总结,加个精让更多人可以关注到

陈恒捷 将本帖设为了精华贴 04月04日 08:40

面试时,质量保障体系经常被问到,但是作为一个普通公司普通测试,真的很难回答,根本没有什么体系可言。楼主总结的很好,让我这种不成体系的学习一波。

4楼 已删除

客户端稳定性有没有好的方案可以分享一下😀

好的测开,确实还是得从业务中走出来,对业务痛点有亲身摸爬滚打经历,再慢慢走到中台化服务化

测试管理的一些思考写得挺好的,学习了!

也想看看楼主的客户端稳定性和专项建设

不管是偏业务测开还是偏工具测试真的如同楼主所说的需要料理这么多方向的事情?

这没有 100 个达不溜 招不进来

测试开发不将只是测下功能,要从交付的角度去反推研发过程的改进,从而整体提高版本的质量和效率。就需要不断升级和复盘测试技术,提升个人的能力,同在大厂多年,对楼主的分享非常认同!

讲的很好,从点到面,开阔了眼界。有的时候自己也是缺少总结,学习了

新人表示 赞!

hu 回复

吹牛皮的前提是你确实做过或者懂部分,也比完全不懂的强多了。

汇荔君 回复

还要看公司高层对测试的认知,有些公司认为测试就是质量检测,后期保障!

学习了~

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

这个问题很有感触,发现了问题,在正式会议上提出了问题 (比如说设计,交互的,一致性问题),很多都不被重视,美誉落地到人,然后不了了之,正常来说和测试应该没有直接关系,到后面就会进化或者关联成了一个紧急问题,然后就需要紧急测试,然后质量就难以控制了,到最后还是自己吞下了苦果 😭

看完真的感觉有收获,让自己思考有一些方向,现在没有一个系统的质量体系,谢谢楼主分享

沟通能力很重要,特别是拉通系统的时候

说的很全面

很厉害👍 ,学习了

团队建设、业务框架梳理、资源梳理以及复盘,这几点醍醐灌顶,学到了,谢谢大佬

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册