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

生活:

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

去年工作太忙导致疏于活动身体不大健康,于是从今年年初开始跟着热爱运动的同事刻意锻炼。谢谢在航信一直拉着我我跑步的前辈和在雪球加入的 “不跑步就发红包” 群,今年跑了 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 看你是否对眼等)。所以,找工作碰壁的时候不用太妄自菲薄。

读书:

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

非技术类:

技术类:

其它:

关于质量:

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

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

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

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

我的观点如下:

关于 2016 年的测试工作:

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

关于个人的 2016:

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


↙↙↙阅读原文可查看相关链接,并与作者交流