最近各种原因换了个工作,回想起来校招(实习)就进百度了,一晃 5 年多了。最近又宣传“十四五”,也想着自己确实得好好总结下这五年,而且市面上做 QA 的比较少,希望能对新同学有些帮助。
原文链接: https://iyaozhen.com/work-first-5years.html
做程序员这一块,可能都会遇到第一个瓶颈,工作前 2 两年成长很快(特别是 QA,都是现学),但后面就慢了,感觉重复着之前的工作。这里以“捕鼠器案例”为引子,重新捋一下 QA 的工作:
刚工作接到的任务一般比较简单、直接,比如导师可能叫你去放一下捕鼠器。这个时候你一般看看文档,多观察下,就知道捕鼠器是用来捕老鼠的,你只要不给它挂在墙上就行。甚至前人已经放过捕鼠器了,你只要依样画葫芦隔一段距离放一下就行了。
这个时候你就要稍微总结下了,放捕鼠器为什么有时没捕到老鼠,你可以会观察录像,看别人的捕鼠器怎么做的,这个时候稍作改进就会效果明显。具体的到 QA 的工作,你现在已经非常熟悉这块的业务,每次小功能的测试都游刃有余,而且通过学习你还会了 API/UI 自动化测试,效率也变高了。
由于表现还不错,你已经晋升为 T4 了。这个时候你会发现只放好老鼠夹子效果还是不好,具体到工作可能会发现线上还是有很多问题。你一想,捕鼠器是干啥,消灭老鼠,但消灭老鼠,不仅仅只有捕鼠器一种方法,或者说一种方法不够。
当一个人从完成任务到解决问题,能够再问一步,这个问题关联的问题是什么,进而去提出新的问题,这就是关键的突破点。
你可能会发现老鼠药更管用。类比测试工作上来说,你引入了更多的测试方法:diff 测试、性能测试、稳定性测试、兼容性测试、安全测试、ET 测试等,工作开始变的顺风顺水。
这个时候你测试环节已经做的很不错了,能负责一个系统或者业务方向的测试了,一般的话也晋升为 T5 (高级测试工程师)之列了。但这个时候就开始重复之前的工作了,项目不停迭代、新功能测也测不完。而且随着需求积累,回归测试也很多了,因此对于 QA 来说这种重复的感觉比 RD 、FE 更强烈。
这个时候还得回到原点来,捕老鼠是为了什么?为了保护粮食。那 QA 找 Bug 是为了什么?是为了“质量”。这个时候引入一个非常重要的概念:全流程质量保障。作为 QA ( Quality Assurance,质量保障),自己把自己定位成测试是不行的。
可能每个公司的项目流程都不一样,但都会包含以下几部分,当你跳出“测试”来看,就会发现能做的事情还有很多。
有些同学觉得需求不都是 PM 、RD 的事情嘛,QA 能干啥。往小了说,参与需求评审能了解需求的来龙去脉,方便我们设计测试 case 。往大了说,有时候 Bug 多、上线 delay,是需求不靠谱,PM 可能只考虑自己这块的功能,实现起来需要复杂的周边改造配合,不必要的提高了整体复杂度,这时可以建议 PM,换个思路来满足用户的需求。
大量工程经验告诉我们,Bug 发现的越早,修复成本越低。我们不光要督促 RD 做好单测,还得深入参与方案设计评审、code review,提供完善的自测 case 帮助 RD 自测,总的来说就是尽早的发现问题。
此时才到具体的测试,除了做好测试本身外。我们更多的可以关注到 CI (持续集成)来,比如我们的自动化 case,可以在 RD change 代码阶段就运行一些核心 case,拦截低级问题,合入后运行完整的测试 case 。并不断的提高测试覆盖率( case 运行完后覆盖了 RD 代码多少分支)。还可以性能测试例行化,发现版本间性能变化。最终能做到只要流水线通过,就能有底气让 RD 直接上线。
发布肯定也不只是 RD 、OP 的事情,别的不说,上线后的验证 case,就需要 QA 提供完善。发布流程上也有很多提升质量的方式,比如灰度、A/B 测试、众测、单节点 /单机房小流量等,还有完善的回滚机制。这样问题即使出现也能控制影响范围。
前面都做的很好,但线上问题(可能不是直接的 Bug )多,这更直接影响用户体验,更体现质量差,所以线上稳定性 QA 也需要重点关注。
发现问题要快,相关业务拨测、日志监控是否完善?一般公司都有相关平台,没有的话需要推进建设。 定位问题要快,比如相关日志 logid 是否能够串接起来,日志信息打印是否规范?不求找出确切问题,但需要知道大体原因,方便执行下一步策略。 兜底策略时候完善,线上问题往往来势汹涌,还来不及查问题就已经挂了。这个时候如果近期有代码变更,回滚策略是否完善(线上问题止损第一位)。上下游重试 /熔断机制是否合理?机房切流是否有预案?
研发质量、效率,产品效果有时候比较主观,虽然不支持唯分数( KPI )论,但基本的数据分析和度量还是要有的。比如功能埋点数据如何上报,如何保障用户隐私,如何测试埋点数据能满足 PM 的需求。研发质量如何度量?比如可以分析发现 Bug 的类型,是否可以针对性改进,发现 Bug 的阶段是否靠后导致 RD 修复风险大,提测打回率,漏测率等等。线上运行情况如何,比如可以建立 SLA 体系,及时或者定时报告质量情况。还可以结合日志平台,收集各个模块调用数据,能全盘看见整个微服务的情况。方方面面还有很多,更广的就涉及到了 BI ( Business Intelligence )、EE ( Efficiency Engineering )的范畴了。
这部分没有强调某个技术具体怎么做的,比如百度 QA 自动化测试怎么做的,因为 QA 发展了那么多年,特别是在 BAT 这种大厂,自动化测试各类的技术已不是高阶 QA 主要能力瓶颈和测试技术短板。更看重产品的全生命周期的质量保障,从尽早发现问题,到缺陷预防,到减少发布后遗漏问题的影响都是 QA 投入的重点,也是在百度(或者公司)不可或缺的核心价值。整个流程粗略一看能提升质量的地方就很多,干好其中几项自然就升到 T6 了。这里一定要注意不要为了晋升而做事情,晋升应该是水到渠成的。
到了这时,其实我们可以再想想一开始的问题,保障质量最终又是为了什么呢?
所以说再往上,你可以跟更高的目标去对齐,你的能力,你发挥的作用也会更大。首先需要了解目标是什么,评估方法是什么,怎样去改进,走成一个正循环。
当前互联网环境还是偏浮躁,很多新同学会问,机遇和努力哪个更重要呢?答案肯定是机遇更重要,但机遇是可遇而不可求的,因此我们只能更加努力。保持一颗平常心,吃饭时好好吃饭,睡觉时好好睡觉(毕竟现在想着年前为什么不把基金卖了也没啥用),先把当前的事情做好,仰望星空,脚踏实地,有助于我们克服“内卷”的焦虑。
见原文链接
广告分割线(大家友善讨论,主要还是想分享点个人感悟)
虽然说机遇不可求,但我们还是可以选择的,我现在所在的团队(字节跳动-飞书),大量招测试开发工程师,各个级别都需要(含实习生),leader 也需要,全国大城市可选。[email protected]
PS:最近换 logo 和造车的小米公司就是用的飞书哦。
1
godbasin 2021-04-02 14:39:13 +08:00
我也毕业 6 年多,跟楼主不同,换了好多个公司呢~
我觉得自己一直都在进步,每次在觉得在某个地方呆着没法再拓展自己的时候,我都会选择往前走。当然,这也需要放弃一些东西,比如升职加薪等等。 这么多年来,我觉得很庆幸当初自己选择了向前,而不是停留。而经历了很多的团队和工作之后,其实生活和工作的平衡也很重要,所以现在在一个自己还挺满意的状态,同时保留着持续学习和往前的心态。 我也打个广告吧,腾讯文档招人噢,前端开发、后台开发、客户端开发,地点包括深圳、北京、武汉,各个级别都需要(含实习生),leader 也需要。简历可投递 [email protected] 再打个广告,我的博客: https://github.com/godbasin/godbasin.github.io |
2
godbasin 2021-04-02 14:43:36 +08:00
竟然抢了前排有点不好意思,所以也算是帮楼主顶一下~
在线协作文档算是前端领域中比较复杂的业务了,所以有机会接触可以学到特别多的东西~ 如果希望有所了解,之前写了一篇文章《在线 Excel 项目到底有多刺激》大家可以参考下: https://godbasin.github.io/front-end-playground/front-end-basic/deep-learning/why-spreadsheet-app-excited.html |
4
hxndg 2021-04-02 14:59:09 +08:00 3
我才工作三年,现在初步养成了做事情和看事情的方法,这个方法不单纯针对工作,普适性比较强。
然后最近准备跳了,接了 mt 的 OFFER 。 但是 我最近结合面试字节 /百度等公司的经历,感觉就是互联网的浮躁 面试官很喜欢提新鲜的名词,三句话不离场景,不问具体的解决方案,方法的好处弊端,反而像是背题吹牛逼。 虽然我承认场景很重要,但忽视了基础架构的通用性和灵活性,不像是考工程能力,像是考做题家。 工程师不重视工程和思维能力,重视面试能力就挺扯的。 |
5
iyaozhen OP @hxndg 这个方法不单纯针对工作,普适性比较强。+1
面试的问题我尝试解答下,首先面试有很大偶然性,你要想面试官也是一般的同学(特别是一面),被面者 可能工作还比面试官丰富。 你说的问题一般是出现在流水线面试中,如果简历来源一般,没有对口内推的话,我们采用“结构化”面试的方式,就是很偏八股文,但这也是没有办法。理论上 2 面和 3 面偏向会看你之前的项目,对此发问 |
6
yuruizhe 2021-04-02 16:19:29 +08:00
说破大天,还是去总部了
|
10
asanelder 2021-04-02 18:11:16 +08:00
感谢楼主, 作为一个 RD, 感觉很在理啊.
不过俺有一个疑问. 您说的"全流程质量保障", 是需要 QA 介入需求和开发阶段的, 但这毕竟不是 QA 的职责, QA 顶多是一个建议者, 比如说 1. 需求阶段可以提需求的不合理 2. 开发阶段可以要求 RD 写自测 但这里面有一个话语权的问题, 如果 QA 话语权不大, RD, PM 可能都当成耳旁风, 而当成耳旁风的话, 其实这个"全流程质量保障"就不好执行下去. 这个全流程质量保障要想做的好, 俺的理解是 RD, PM, QA 通力合作的. 而您之前的团队(或现面的团队)是如何促成这种合作的? |
11
iyaozhen OP @asanelder 哦 文中忘了提了。这种模式只能在大厂才行。
「这毕竟不是 QA 的职责」其实在百度或者字节 没这个说法,并不会给某个岗位限制范围。所以 QA 职业上下限很大 比如在百度,话语权是靠自己争取的,不是谁定的。百度的话 技术氛围比较浓厚,比如 code review 阶段,你指出的问题很一针见血,提的 Bug 很明确,有详细错误日志,甚至给了 3 个修复方案,RD 就会服你。这个就会反推需求,比如 PM 说有个需求怎么样,RD 说不好做,你说可以需求改下 这样这样就好做了。PM 甚至会先你问你这个需求能不能实现,防止 RD 糊弄他。 至于让 RD 自测或者单测,一般 RD 还是有意愿自测的,你只要把自测 case 给他。还有可能就是上面的压力了,比如打回次数,bug 率作为他们的 KPI 当然中小公司也可以往这个方面走,但需要循序渐进。也要看人员能力,适合的才是最好的 |
12
wuxingli 2021-04-02 18:23:42 +08:00
额,我也是个 QA,看了些感触很深,自己带的公司都是小公司,基本上都是一两个测试,而且都是手工测试,想往自动化方向发展,但是自己毫无头绪,不知道从那里下手,身边的测试基本上都跟我差不多
|
13
d873139022 2021-04-02 18:48:40 +08:00
感觉大小厂在测试这边差距是真的太大了,诶,一言难尽
|
14
asanelder 2021-04-02 19:14:40 +08:00
@iyaozhen #11 感谢回复, 俺觉得这种靠自己争取, 以实力服人的方式, 很好! 也了解到百度这方面的情况, 再次感谢!
|
16
gBurnX 2021-04-02 19:29:12 +08:00
当你接触过稀烂的软件质量时,才知道有 QA 的宝贵。
|
17
iyaozhen OP @wuxingli
@d873139022 @asanelder 原文有补充 https://iyaozhen.com/work-first-5years.html#%E5%85%B6%E5%AE%83 可以看出,不管是风险左移,还是保障右移,都需要 QA 自生有不弱于 RD 的能力,不是做不了开发才来做测试,仅仅是社会主义分工不同。还有就是经济基础决定上层建筑,就像一个国家搞原子弹、搞航母一样,并不是一朝一夕能行的,也不是每个国家都需要航空母舰(外蒙古就不需要)。所以还需要因地制宜,适合自己项目组的才是最好的。但你有想造航母的目标,那么可能还是得去大公司,才能实现 QA 的价值。 |
20
liaoberlin 2021-04-02 22:05:54 +08:00
感觉说得挺在理的 大佬去字节起飞啊
|
21
revalue 2021-04-02 22:13:41 +08:00 via Android
小厂 觉得和 大厂差不多,思想方法论也差不多,但是大厂更规范。大厂工作流程基本具备,qa 可以更加专注于工作和目标,没有那么苦逼
|
22
revalue 2021-04-02 22:15:34 +08:00 via Android
大厂只要想做,基本上都能开绿灯,最多就是求人求领导,只不过是时间的问题。小厂想做一点长远的东西极其缺乏资源,就要求天求地了
|
24
hugo54 2021-04-03 00:36:40 +08:00
目前百度校招 QA 第一年,从入职一开始团队就强调全流程质量保障,看到楼主的文章很共鸣的。
楼主提到的每一个阶段对于 QA 来说都大有可为, 只是身在业务部门,日常测试工作繁忙,时常感到有心无力。 |
25
clip 2021-04-03 11:25:07 +08:00 via iPhone
同组 be 帮顶
|
26
iyaozhen OP @hugo54 你这第一年不急,总是要先做好事情,建立信任,让导师、组内高工看见你有能力和意愿干一些大事。
说个不恰当的,“一将成名万骨枯”,现在百度 QA 几乎没有做平台的组了,都下放到业务了,必然大部分人还是得抗业务压力,QA 做个什么高大上的东西,但最终的价值也要体现在对业务的贡献。 |
29
d873139022 2021-04-06 16:10:24 +08:00
QA 真的要有同级的开发水平嘛,感觉小公司的话,这不直接转到开发序列了嘛
|
30
iyaozhen OP @d873139022 这个稍微夸张了一点,但至少 QA 负责人是和同级别 RD 差不多的。我内部转过 RD,对方特别欢迎,都面试和双方 HR 通过了,但最后没去
薪资 QA 可能略微比 RD 低一点,但工作内容上各有各的好,就像前面说的社会主义建设分工不一样。这个就看个人了。 当前这一切都是在 TOP N 的大厂前提下 |