那个从不加班的同事，晋升却比我快，我偷学了他的工作流
我盯着季度晋升名单看了整整五分钟，直到屏幕自动息屏，映出自己那张写满困惑的脸。林越，那个每天六点准时拎包走人的家伙，名字赫然出现在高级测试工程师的晋升栏里。而我，一个在自动化脚本和回归测试里摸爬滚打了两年的“劳模”，每天最早到岗、最晚离开，工位上的加班餐券攒了厚厚一沓，换来的却只是领导一句“辛苦了，继续努力”。
那种感觉很难形容。不是愤怒，更像是一种认知崩塌。我一直相信的道理——只要足够努力、投入足够多的时间，就一定能被看见、被认可——在林越身上彻底失效了。他从不参与晚上的用例评审马拉松，周末的紧急发版也从来找不到他人，可偏偏是他，拿着比我高出整整两个职级的晋升通知。
我决定弄清楚这背后的逻辑。不是出于嫉妒，而是出于一个测试工程师的本能——当一个系统输出的结果与预期不符时，一定是我的理解模型出了问题。
接下来的两个月，我开始有意识地观察林越的工作方式。这件事做起来并不难，因为他就坐在我斜对面，隔着一排显示器的距离。真正难的是放下自己那点可怜的自尊心，承认一个“看起来没我努力”的人，可能比我更懂得如何工作。
第一个让我感到冲击的发现，是关于测试用例的设计方式。
我们组每个人手里都维护着几百条用例，每次版本迭代，大家的第一反应是把用例库全量跑一遍，生怕漏掉什么。我也不例外，甚至更夸张——我会把关联模块的用例也拉进来跑，美其名曰“覆盖更全面”。结果就是，每次回归测试都像一场马拉松，从早跑到晚，跑到眼睛发酸、脑子发木，最后交上去的报告厚得像一本手册。
林越不这么干。他做回归测试之前，会先花二十分钟看代码提交记录。不是随便扫一眼，而是逐条看开发改了哪些文件、动了哪些接口、涉及哪些数据表。看完之后，他在用例管理系统里勾选的范围精准得让人不舒服——只跑变更影响的链路，只验证核心业务逻辑，其余的一律跳过。我一开始觉得他这是在偷懒，直到有一次，一个支付模块的边界值异常被他用不到三分之一的用例数量就揪了出来，而我全量跑了两天，反而因为疲劳漏掉了同一个缺陷。
这件事让我意识到一个残酷的事实：测试的价值从来不是以用例执行数量来衡量的。跑一百条无关紧要的用例，不如跑十条命中风险点的用例。林越把时间花在测试策略的制定上，而我花在了测试执行的体力消耗上。前者是脑力劳动，后者正在被自动化替代。
第二个让我重新审视自己的，是他对自动化的态度。
我们组的自动化覆盖率一直是个敏感话题。领导每次开会都要提，大家就拼命写脚本，恨不得把每个手工用例都转成自动化。我也是这股浪潮里的积极分子，经常加班到深夜，就为了多封装几个关键字、多调通几条脚本。可问题是，很多脚本跑一次要花四十分钟，维护成本极高，界面一改就要跟着改，最后算下来，写脚本加维护的时间，比手工执行还长。
林越的自动化策略完全不同。他只对三类场景写脚本：高频重复的核心业务流程、数据驱动的参数化校验、以及手工很难模拟的并发或异常场景。其他的，他宁愿保留手工测试的灵活性，也不强行自动化。有一次我在茶水间碰到他，忍不住问了一句。他想了想，说了一句让我记到现在的话：“自动化不是为了取代人，是为了把人从重复劳动里解放出来，去做机器做不了的事。如果一个脚本的维护成本高于它节省的时间，那它就不是资产，是负债。”
这句话像一盆冷水浇在我头上。我回头翻看自己写的那些脚本，至少有四成属于“为了自动化而自动化”的产物，跑起来的稳定性堪忧，维护起来更是噩梦。我把时间花在了堆砌数字上，而他把时间花在了让数字产生真正的效能上。
第三个改变我认知的，是他处理缺陷的方式。
我习惯的做法是，发现bug就提bug，描述清楚步骤、预期和实际结果，然后丢给开发，等修完了再验证。这个流程本身没错，但问题在于，我很少去追问bug的根因。是需求理解偏差？是接口文档未更新？是代码逻辑缺陷还是环境配置问题？这些我很少深究，因为“提完bug我的任务就完成了”。
林越提的bug单，每一张都像一份微型分析报告。他会附上日志片段、抓包数据，甚至会在bug描述里写清楚自己推测的可能原因，以及建议的修复方向。开发拿到他提的bug，几乎不需要反复沟通就能直接定位。更关键的是，他会把同类型的缺陷归类整理，定期在组内分享，告诉大家哪些模块容易出问题、哪种编码习惯容易引入缺陷。他做的不是单点的缺陷发现，而是系统性的质量预防。
三个月后，我做了一个决定——不再靠加班时长来证明自己的价值，而是试着把林越的工作流拆解成可复用的方法，融入自己的日常。
我开始在每次回归前做变更影响分析，不再盲目全量执行。我开始审视自动化脚本的投资回报率，果断废弃了那些维护成本过高的脚本，把精力集中在真正有价值的场景上。我开始在提bug时多花十分钟分析根因，把每一次缺陷当成一次学习的机会，而不是一个需要赶紧甩出去的任务。
改变的过程并不轻松。减少用例执行数量让我一度感到不安，总觉得自己“做得不够多”。放弃那些花了很多心血写出来的自动化脚本，也让我心疼了好一阵。但数据不会骗人——两个月后，我负责的模块线上漏测率下降了，自动化脚本的稳定性提升了，和开发的协作摩擦也明显减少了。更重要的是，我六点半就能走出办公楼，天还亮着，那种感觉陌生又奢侈。
回过头来看，林越教会我的不是某种具体的技巧，而是一种底层的工作哲学。在软件测试这个领域，我们太容易陷入“忙碌等于价值”的陷阱。手工用例一条条跑、自动化脚本一个个写、bug一张张提，这些动作本身会制造一种充实的幻觉，让人觉得自己在产出。但如果这些动作没有经过策略层面的思考，没有指向真正的质量目标，那就只是在用战术上的勤奋掩盖战略上的懒惰。
测试工程师的核心竞争力，从来不是谁能熬更久的夜、谁能执行更多的用例。而是谁能在有限的测试时间里，找到最可能出问题的环节，用最小的成本获取最关键的质量信息。这是一种判断力，一种对系统风险的本能嗅觉，它需要时间思考、需要经验沉淀、需要从重复劳动中抽离出来才能培养。
如今我也成了别人眼中那个“不怎么加班但产出很高”的人。偶尔有新同事问我诀窍，我会把林越当初教给我的东西告诉他们：把时间花在测试策略上，而不是测试执行上；让自动化服务于效率，而不是服务于报表；把每一个缺陷当成理解系统的窗口，而不是需要赶紧关闭的任务单。
测试这条路很长，加班永远加不完。但真正能让你走远的，不是你能熬多少夜，而是你是否想清楚了，每一个小时的工作，究竟在为质量贡献什么。