灌水 一个测试工程师的 2015 总结和 2016 年 小展望。

刘晓光 · 2016年01月03日 · 最后由 solomon 回复于 2019年06月04日 · 1098 次阅读
本帖已被设为精华帖!

本来十分懒得码字了,但看了思寒的帖子突然想写一下,我也来灌水了。

生活:

波澜不惊,用一个矫情的词叫做 “岁月静好”。但爱人的舅妈被车祸夺去生命和我的大舅罹患癌症(所幸在早期,手术很成功,基本上痊愈)让我更加意识到生命的脆弱和人生的无常,更珍惜安宁的生活。希望所有亲人朋友都永远平安。

去年工作太忙导致疏于活动身体不大健康,于是从今年年初开始跟着热爱运动的同事刻意锻炼。谢谢在航信一直拉着我我跑步的前辈和在雪球加入的 “不跑步就发红包” 群,今年跑了 300 多公里,做了 1000 多分钟的 keep。身体状态好了太多。随着年龄的加大,对身体是革命的本钱这句话越来越认同了,16 年一定要继续坚持锻炼。

正在为创造新生命努力中,希望一切顺利。

工作:

15 年 7 月份离开了自己服务近 8 年的老东家 “中国航信”,来到了一个很棒的创业型公司 “雪球”。

离开的原因主要还是职业路线发展。对于一眼就看到未来 5 年的样子的恐惧在 14 年发酵了一整年后终于爆发了。经过和家人的深入沟通和要好几个兄弟的多次恳谈,终于下定决心迈出了跳槽这一步,放弃了很多人 “羡慕的稳定工作”,来到了互联网公司。当然,收入回报也是一个很大的考量点。男人毕竟要养家。虽然在航信的薪水据说还可以了(走的时候人力说我是我们那一届两百人里钱最多的之一),但是在北京生活的压力只有生活在这里的非土著同学懂。

工作交接十分快,因为我提前半年做了布局,把手里的活儿全部分给了原来队伍里的小伙伴,并确认了他们可以自组织的搞定一切。因此交接只用了一天。辞职有些不顺,大领导不愿意放我走,结果拖了大约 3 周,还是部门领导给我求情他才放了我。

对于航信,我更多的是感谢和不舍。感谢部门领导一直以来对我的信任和提携,也感谢身边的每一个同事一直以来给我的家的感觉。离开算是一个自私的决定。

去雪球颇具戏剧性,4 月份面试了三个紧随 BAT 的大公司,并拿到了 2 个 offer(一个拒了我)。因为一直觉得有一个项目没做完,有责任放不下,迟迟没有辞职(其实也是自己不够满意)。6 月份的一天,一个航信最要好的哥们跟我说:“我要撤了,找你吃饭。第一个告诉你,别跟别人说”。我心里第一句话就是 “我操!怎么是你!”。跟他聊后,我心里那股劲头已经无法遏制了。晚上就翻开招聘网站准备继续投简历。这时候正跟老婆聊天,她问我一只股票如何,我说 “你上雪球去看呗(我是雪球铁杆用户)。”。老婆很不乐意的回了我一句:” 你整天看雪球,你去雪球上班得了!“。我一个激灵,原来可以这样!搜索一下,果然有雪球的招聘,然后就直接投了。后来就约了面试,雪球的面试在我这几次面试的感觉是最好的,面试我的几个人都体现出了对技术的热情和十分深厚的底蕴,气氛也特别轻松,我觉得这里是个有朝气的团队。

面试过后,CTO 很快给我打了一个电话,说还算满意。但是我没有任何移动测试的背景是个硬伤,所以需要二面。于是约了 3 天后再次面移动。回家后赶紧我找了几个做移动测试的哥们要了相关的资料,用了 3 天的时间撸完了两本书,三百多页 ppt,最终通过了面试。这里要十分感谢 芈珺,Monkey 和邢大棒,感谢你们的资料和支招。

在雪球的工作其实很繁忙,头绪也很多。但是逐步招聘上来的小伙伴都十分给力,他们在移动方面的知识也弥补了我移动测试的短板,给了我补课的时间。我们经常是一起讨论改进、解决方案然后快速实施,每一天都会一小点进步。思寒同学的加入更是让 team 有了很大的提升,他对技术的极度热爱和对测试的深刻理解让他在 team 里更多的承担了技术带头人的作用,而我则有很大一部分精力放在了所谓的” 杂事 “上。虽然作为技术控的我有一点不甘心,但理性告诉我,对于团队来说,这样的配置是更合理的。

经过四个月的缓慢爬坡,也经历了不少挫折,雪球的测试算是初步做起来了(虽然还有很多不尽人意的地方)。这点我还是很欣慰。值得说的是,这绝对是 teamwork 的结果,得给 team 内每一个小伙伴点赞。

在雪球,我也慢慢的适应了” 互联网节奏 “,和很多更年轻的小伙伴一起协作(大多是八五后九零后),他们的能力,冲劲,热情和青春无敌让我只能用” 羡慕嫉妒恨 “来形容自己的心情。作为一个老人,得继续保持学习和工作的热情,才能长期与之共舞。

年底接到了年初拒绝我的公司的又一次邀约,虽然职位和薪酬很有吸引力,但雪球让我有家的感觉,于是婉拒了。找内部的哥们打听了一下,再一次联系我是因为我以前的行业背景同招聘公司现在上马的项目很吻合,而且有人从内部推荐了一下我。这个例子告诉我,找工作还是偶然性很大的,有的时候能力不决定一切,有太多不相关因素(企业是否正缺人,HR 看你是否对眼等)。所以,找工作碰壁的时候不用太妄自菲薄。

读书:

作为一个书虫,今年是这几年读书最少的一年。读的书屈指可数,一来工作越来越忙感觉读技术外的书变成了一种奢侈,花一晚上读本小说或者传记就会有强烈的负罪感;二来好的技术书籍太少了,翻十来页页就有想扔掉的冲动,具体技术现在越来越多的是在读官方文档。盘点一下今年读的书。

非技术类:

  • 《The Martian》
  • 《三体英文版第一部》
  • 《亚特兰蒂斯 - 基因战争》
  • 《湮灭 - 南境之国》
  • 《从 0 到 1》
  • 《耶路撒冷三千年》
  • 《人类灭绝》
  • 《Google 重新定义公司》
  • 《Beyond Blame》
  • 6 期《新知杂志》
  • 12 期《哈佛商业评论》
  • 12 期《环球科学》

技术类:

  • 《More Agile Testing》
  • 《驯服烂代码》
  • 《快学 Scala》
  • 《重构》(重读)
  • 《Spring in Action 4th edition》
  • 《Docker Cookbook》
  • 《Learn Git in a Month》
  • 《Restful web apis》
  • 《Java.Performance.The.Definitive.Guide》
  • 《Web Development with node and Express》
  • 《iOS 测试指南》
  • 《移动 App 测试实践》

其它:

  • 完成了北航研究生的一门课程的授课。花费了 10 周的周末。虽然讲过一轮了,但过程依然很痛苦,每一次讲课都会把上一轮的课件改的面目全非,每一次讲完都觉得自己有太多东西不懂了,需要继续努力。讲课也是一个认识自己局限的好方法。
  • 作为 GITC2015 的演讲嘉宾做了一个关于测试的演讲。是大几十个讲师里唯一一个讲测试的。现场反馈还不错,有一点儿欣慰。
  • 给国内某大银行做了一次” 敏捷测试 “的培训。发现传统行业的很多工作理念还是很有很大上升空间的,希望我的课程能有一定帮助。
  • 给几个企业提供了数次免费的咨询(都是朋友找的),提供帮助的同时,也了解了很多企业现在对于测试和质量的现状,其实都并不乐观。
  • 获得了 Coursera 的数据科学的一门课的认证证书(还有九门没有修完)。数据分析重新激起了我的兴趣,也许未来工作会向那方面靠拢,做一些技能储备。

关于质量:

好像已经说过太多,没什么可说的了,但还是抽象的唠叨几句。

多年的工作让我越来越清晰的认识到:质量绝对不是一个环节,一个工种可以搞定的 。从对语言的误用,到对第三方组件的误用;从需求根源就有问题,到需求传递过程中出现的误差;从设计代码基本逻辑设计不合理,代码架构设计不合理;从一些参数配置错误到上线的版本弄混;从架构师不良的设计,到运维人员不规范的操作,质量问题可以产生于任何一个环节。随着系统越来越复杂,单点的问题会累计成片的问题,面的问题,最后产生灾难性事故。这些例子见得太多太多了因此,搞定质量是系统性工程,是绝对的 teamwork,人、流程、技术、标准都是不可或缺的。如果只尝试从单一角度解决质量问题, 即使采用再牛逼的技术,下再多的力气,定再多的流程,也可能只会事倍功半。但是我发现,很多团队解决问题总是极度偏向一个维度的。有的组织定义一大堆流程,并严格执行,最后演变成了抠文字的游戏和邮件大战,而对采用落后的技术给生产力、质量带来的极大拖累视而不见;有的团队极度追求技术,什么新用什么,最新的架构、框架全都用上,却发现开发人员一行单测也不写,连类型转换,不捕获异常,少写个等号这样的基础代码级别的 bug 都要等系统测试阶段再发现;有的团队开发人员极为强悍,从代码工程角度来看架构、设计、代码、单元测试、评审都无懈可击,但是需求竟然是邮件来回沟通,到最后还是为其所累;还有的团队似乎每一个点都照顾到了,还过了 CMMI5,貌似一切都很好,但是发现,改一个按钮的需求要搞一个半月才能上线,要知道,开发效率也是质量的一环啊。 这些都是我见过的真实的例子。

如何搞定质量呢?答案是” 综合治理 “这几个字。至于如何做,其实不同的团队实现起来会大不一样。因为团队结构不一样,产品类型不一样,公司文化不一样,怎么会有万灵药呢?在大多数情况下,质量的长足改进都是对基础的重视和无数次磨练团队成员打造出来的,对于老的团队更需要拿出伤筋动骨的勇气和从一行代码搞起的决心。可惜国内大部分团队的质量体系只停留在一个初级阶段(我做过上百人的访谈,还是有一点发言权的)。我们国内大部分 it 团队离成熟、高效仍然有很远的举例,需要我辈一起努力。

那么问题来了,在这种前提下,测试人员如何开展工作呢?

我的观点如下:

  • 测试工程师的传统工作边界会越来越模糊甚至会被打破。不再固守” 系统测试 “这片疆土,而把工作前移是一个必然趋势,而前移需要开发技能和开发人员的半成品对接,这是个残酷的现实;测试后移也是趋势,利用生产数据、行为做测试也将是测试人员需要掌握的技能,这里就需要测试人员掌握一些运维知识和数据分析知识,这些也和开发技能难以分开;而随着系统越来越复杂,各种非功能性测试也会越来越重要,而大部分非功能测试同样需要开发技能(如性能测试,安全测试)。没有这部分技能是无法做好测试的。测试对开发技能既要求广,又要求深,其实挺过分的(这从一个点印证了做测试工程师是一个投入产出比很低的选择,这也是我一直坚持的观点)。

  • 人的认知和学习能力有极限,作为一个群体,又会是正态分布的样子。因此不可能所有人都是大神级人物(企业也招不来养不起不愿意养),测试会是以 teamwork 的形式 cover 各个质量环节的一部分,并形成一张质量网。在纵切面上会有一些人钻得很深,如安全测试工程师,性能测试工程师,做框架的测试开发工程师,系统测试分析师,这样才有可能把精力集中在一点,搞定技术的难点,把事情做下去;又例如有些业务极为复杂的企业,需要很多 BA 来搞定业务复杂性,有一些 BA 是偏向测试的;如果组织很大,你就会发现无数流程上的低效率,反模式,这时候其实需要有一些人专注过程,一些测试人员会承担起这些责任。这些都会造成测试人员内部的分工,也会造成测试人员之间的薪酬差异逐步拉开。我觉得测试做测试的同学应该找准自己的努力方向,要学的太多,精力总是有限的,得自己有个人发展路线图。再次强调,测试工作是一个投入产出比不如其他 it 岗位的工作。

  • 不要把自己局限于” 我是测试工程师 “,这样你的职业路线才会逐渐开拓,你对组织的贡献才会逐渐加大。这个不展开说了,工作久了并有一定灵性的同学都会懂。第三次强调,测试工作时一个投入产出比不如其他 it 岗位的工作。

  • 如果你真的喜欢测试,坚持下去。不然真的可以换换岗。

关于 2016 年的测试工作:

只想说几句话:我们已经隐约看到了珠穆朗玛峰的峰顶(虽然它在不断长高),但是我们仍然走在山脚下。看到和爬到是两码事儿,仍然有太多的路需要一步一步的走。希望 2016 年我们的每一步都是踏实的,有成效的。

关于个人的 2016:

  • 低头看路,抬头看天继续努力前行吧。把自己手头的工作做漂亮,给团队提供良好的服务。

  • 保持锻炼和作息规律,有一个健康的身体。这才是一切的根本。

  • 多回几趟家,多给老人打打电话。

  • 和家人愉快的出去旅游一次。

  • keep learning & keep sharing

  • 先写这么多不设定硬性指标,list 没准会加长。

好像发现了一个 markdown 编辑器的 issue

  • 加粗后面如果不加一个空行短横线代表的段落序号就不会被翻译。@lihuazhang
共收到 47 条回复 时间 点赞

@skytraveler 应该是空格的问题。

高屋建瓴 难得如此长文 写的很中肯

—— 来自 TesterHome 官方 安卓客户端

关于质量的部分学到很多

学到很多东西,现在项目中沟通方式完全是邮件,坐在座位对面都是邮件,其目的就是便于追踪查找历史记录。

赞晓光

你做老师的?

15 年毕业生,正式工作了 5 个月,面临离职,心里有些迷茫。离职是必须的,可是接下来的后路却没有找好,心里很忐忑。

#8 楼 @su_qianai 外边很多机会的,不用太忐忑,慢慢增强自己的实力,一两年以后就会非常抢手啦。

#6 楼 @mads 曾经全职, 现在工作之余做。

受益很多

晓光老师写的很中肯,受益良多啊

赞晓光老师

受益匪浅

看完晓光老师的这一份总结,心里也在默数自己种种做得不够的好的地方。2016 向心中的目标前行。

太受益了

能不能分享一下雪球具体的测试流程啊

老司机,开车!!!测试卡,嘀嘀嘀!!!

收益非浅,作为一个上了而立之年,整天抱怨技术多难学的人来说,很有启发和感触,这碗心灵鸡汤,干了!感谢老司机

想知道看了哪三本书和 PPT 呢

#18 楼 @waitnoww 其实还在比较初级的阶段呢。团队磨合中,没有什么太拿得出手的。后续整利索了争取放出来吧。

作为一个刚毕业没一年的测试小兵,给了我不满于现状的动力。
一直在做功能测试,但我认为这样效率太低,有很多技术需要去学习,有很多提高工作效率的方法。
但是 leader 并不是一个接受或者积极顺应新技术的人,面试时候人事说的技术培训也从没见过。只能自己默默学习,探索新技术,提高自己能力,为以后做打算

资历很深了 = =

很中肯……

没有对比就没有伤害,确实要 keep learning

27楼 已删除

非常赞同关于测试工程师的那段,测试工作是一个投入产出比不如其他 it 岗位的工作。要学的太多,太杂,如果没有一个方向深入的话,很难做出一定的成绩。话说如果是偏技术的话,其实就是偏开发的活了,如果是偏业务的话,就是又和 PM 交叉了,或许就像晓光老师说的,测试就是团队里面的「胶水」吧。

#27 楼 @hua666777
别脱离了实际需求做我觉得会不错。

"测试工作是一个投入产出比不如其他 it 岗位的工作" 很多测试不愿面对又不得不面对是现实,没有哪个 it 岗如此纠结路在何方。

#30 楼 @liuxiaosea 开发,运维,产品,或者所有干活的人可能都是这么想的。。。也许我说这句话的时候是 这山看着那山高。

写的真棒,新年开工第一天,也要好好给自己定个目标,keep learning & keep sharing 希望自己也能一直坚持下去。测试工作 4 年了,一直有危机感,如果不好好学习,面试会被鄙视,即便面试通过,工资也没法强势沟通。。。学习不光是为自己,也为团队。。。keep sharing

感触良多!

文中提到的很多问题都是我们团队现在面临的,技术架构设计有问题、邮件漫天飞、制定大量的流程... 看了很有感触 ,但作为小组员虽知有问题却不知道该如何做,很无奈。

新年第一天开工就能看到这篇文章,实在感谢您的分享,也希望您的作品能越来越多~ 作为一个测试菜鸟,一直只停留在系统测试,每天工作都有危机感,一年下来感觉啥都没做,没有给公司创造任何价值,只是开发的附属品,"测试工作是一个投入产出比不如其他 it 岗位的工作"这句话我非常认同,也不知道是方法不对还是不够专注,从大神的世界里我觉得测试人员可以做得更多或能直接为公司创造利益,但是我又不知道从何做起,我们公司的测试流程不够规范没有培训,希望大神们能够支招,提供一些帮助给我,让我的测试道路能够走得更远一些。“低头看路,抬头看天继续努力前行吧。” 已收录为心情,继续加油!

2016 了,多写写代码。

太有缘了,在博客园看到一个名为 “关于测试人员的职业发展” 的帖子,感觉非常好,然后看了一下博主的主页,就发现很熟悉的这篇文章,想了想在 testerHome 也看过,很想认识一下博主,希望能通过即时聊天工具交流一下。(博主愿意的话我再留联系方式吧_

#4 楼 @rocker 发完邮件也可以进行面对面交流,两种行为并不互斥呀。

#34 楼 @sunflower 1.你能发现问题,其实就是非常好的事情。2.从你的角度上来看,测试无法力挽狂澜,改变各种不合理。这很正常,很多是我我也有很多看着觉得不好的地方无力改变,但总还有能做的事儿。3.不爽就是机会,怎么抓住它不是一句两句能讲清楚,因为 team 形态差距很大的,但一定有办法。4.你们有负责流程改进的同学么?可以多找他聊聊,看看他的想法是如何的,另外,有不少相关的书和文章可以看看的,会有帮助。你理解一个问题越深,越有可能为解决它出更多的力。5.team 中如果有一部分不合理的流程和工作方式,但是产出进度、质量还可以。那就说明主要矛盾不是太深,大伙儿已经磨合到一个相互适应的状态了,再想动其实不容易,如果没有太扯淡的地方,也许你可以先睁一只眼闭一只眼,把自己手头的工作做得更好。6.你觉得 team 太 low 了,你有 idea,就只说出来吧。7.你觉得 team 太 low 了,无法忍受,又改不了,这样是对自己的消磨,问问自己内心,看看能做啥吧。 good luck

#35 楼 @a754354300 “作为一个测试菜鸟,一直只停留在系统测试,每天工作都有危机感,一年下来感觉啥都没做,没有给公司创造任何价值,只是开发的附属品”---
系统测试也是大有可为的啊。问一个问题:单从系统测试层面,你觉得你们你们能够有效发现潜在的问题么?自评能打多少分:)
觉得你身边缺一个好老师带你,刚入行其实有人带很重要的,我入行的时候基本上没人带,其实走了两三年弯路。
现在挺好的一件事儿是,网络资源丰富,好老师不见得非在身边。
good luck 兄弟。

#37 楼 @linkenzhou 论坛留贴吧,咱们慢慢熟悉:)

这篇总结太赞了。我自己比较关注的关键词有 “业务”“技术”“胶水”,业务和技术,我通过论坛帖的学习大概找到了一些短时间内的学习方向。但是胶水这个,就是团队协作与融合,希望老师能够再多指点一些。我工作三年,三月份加入到一个新的互联网项目中,团队里的成员能力参差不齐,开发不注重代码质量,在工期较短的情况下开发进度又一再延期,导致我们测试很痛苦。于是我们倡导增加了一些质量活动,比如:开发和测试人员的需求反交底,功能开发完成后的自测与 show time,但是开发并不愿好好配合。我们每天晨会时将开发计划进度表打印出来给他们看,他们也还是该延期的延期,该质量低的质量低。请问 skytraveler 在这种情况下,测试人员应该怎么合理高效的解决呢?

#42 楼 @silent_8 这个问题好大。。。首先说一句话 “质量不是测出来的。” 测试不是质量的守护神,测试只能搞定一部分事情。所以,单从测试环节和测试人员入手很难从根本解决问题。从你的描述来看目前开发从技术和项目管理上都有短板。不知道你对过程改进有没有了解,如果有,可以先推这一块儿,因为这一块儿见效最快。关于测试团队,把自己工作范围内的事儿做利索,这样对其他人指手画脚才会有比较好的效果,这就是一个大话题了,建议先从能够把测试团队的工作变得有条理开始,比如,能够合理的预估你的测试时间,并告知项目经理及其它干系人,每轮测试完成后有良好的信息(产品完成度如何,有何风险,bug list 等)清晰的汇报给干系人;保证你的测试是有效的,能够 cover 风险,如果时间和资源上搞不定,能够让所有人知道等。

推荐一本必读的书:
http://item.jd.com/10131514.html

#43 楼 @skytraveler 嗯,我目前也正在学习做过程改进的事情,有些是碰壁的,有些是能够执行的。从现在起,我会着手将测试团队的工作变得有条理,晨会时报告产品完成度,buglist,风险。另外庆幸《软件测试竟然与教训》这本书我有,读了一少部分,谢谢@skytraveler的点拨,让我知道了做什么是有效的。再次感谢,一周后我会再来回帖报告执行结果或者请教新问题的。/玫瑰

收益了

感谢大佬分享,好赞

挺有用的,启发我进行点系统的思考。大神,事隔几年,有写新的相关的总结吗?

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