运维

我当测试总监的那几年

题图: from Zoommy

最近一直在忙GTLC与GIAC两个大会的事,所以公众号更新晚了几天,还请各位读者担待。

今天来跟大家聊下我当年做测试的一些经历。

每次问我有关职业发展的问题时,我都会反问两个问题。一是你当下最喜欢做的工作是什么,二是你当下最擅长做的工作是什么。

面对这两个问题,大部分人的回答都很相似。先是一愣,然后含含糊糊的说三个字 “不知道…” 或  “没想过…”。

的确,吃喝玩乐,娶妻生子,才是大多数人的基本诉求,什么理想与目标,似乎都不是你蹦一下就能够得到的,这种感觉像极了一头拉磨的驴子,只能蒙着眼睛不停的向前跑,否则就会挨鞭子。

我常说,哪有什么人生规划,都是历史机缘的巧合罢了。

就像我的简历,凡是看过的人都会问:“你做过测试?为什么会选择去做测试呢?”

选择?对和多人来说,职业生涯的发展真的是选出来的吗?一切都是被迫的,一切都是莫名其妙的。

在 #我是技术男,也曾创业过,也拿过风投……# 的篇尾,我说自己带着两年的创业史,身背近五十万的债务,来到了大智慧办理入职手续,开始了新的人生。

这段台词非常耳熟,像极了小时候看到的童话小说,王子和公主从此过上了幸福快乐的生活,恩爱一生。

很可惜,人生毕竟不是小说,把一个人写死了,还可以用某个场景让他复活。

相信大部分的人都有过走投无路的经历,在残酷的现实面前,什么理想,什么目标,都变得毫无价值,能活下去,才是当务之急。

2011年底,那场创业悲剧,让我和我的家人几乎陷入了万劫不复的地步。

在公司开始清盘的第二周,有位朋友给我介绍工作,说是大智慧在招聘架构师,对口研发中心的HRBP正好是他女朋友,问我有没有兴趣。

这真是天无绝人之路,来早不如来得巧,关系那么铁,我自认为八九不离十。

“太感谢了,没想到就我这点破事,你还挂在心上了。”

“先别忙着谢,有个事情要先说下,这个正在招聘的岗位归属测试团队,也就是说,如果你过去,职位最多是测试架构师……”,电话那头的声音显得有些无奈。

“不知道你是否在意?听说这个岗位他们招了半年,一直不理想,我觉得你肯定能够胜任。”

对当时的我来说,与岗位和职务相比,收入与稳定性对我的吸引力更大。

“无所谓,帮我安排面试吧,”,这种爽快程度,连我自己都不敢相信。

“你下午就过去吧,我女朋友那边已经给你安排好了。”

以前的我从来都不信什么牛鬼蛇神,也不信小说上那种纯情的完美结局,但此时此刻,我似乎感觉面对未来以后充满了希望,但又无法面对。

面试进行了2个小时,面试官是当时的测试总监,近四十的年纪,说话很稳重。

在谈话中,我们交流了有关阻抗测试的各种问题,并探讨了一些传统测试转型的方法。

这方面的记忆力是我的强项,至今我任然记得一些:

1、只能发现问题,无法解决问题

测试环节,常常在代码编写之后,就算测试小伙伴的能力再强,通过九牛二虎之力测试了致命性问题,但为时已晚,要想重新折回头处理其中的问题是要花费一些时间和精力的,降低了交付效率,如果不打回修复,则无法保证质量。

2、有能力的不愿意做测试

从事测试工作的小伙伴,一般都没有研发能力,有研发能力的一般也不会来做测试,毕竟无论从地位,还是收入,开发都要比测试高一些。

这就形成了马太效应,好的越好,差的越差。

3、业务测试与业务验证,傻傻分不清

通常情况下,讨论需求的时候,业务方都会叫上开发,毕竟需要开发去实现,但绝不会叫测试。

这里会形成一种尴尬,因为测试员不可能理解所有的代码,而且没有参加需求环节,所以漏掉一些重要的测试是很有可能的。但业务方不会遗漏,毕竟这是他们的工作核心。

因为,我们经常会碰到,测试没测出的问题,却在业务验证时发现了。

然后有趣的场景出现了,业务怪开发,开发怪测试,测试直喊冤枉。

4、测试环境是世界级难题

测试环境,是每家公司最头痛的问题。比如测试通过,生产报错,再比如测试人员编写的测试是依赖的文档或其他东西,而不是代码,配置和数据存在任何不一致的地方的时候,就会造成问题。

另外,如果测试不是自动进行的,那么极有可能不会被频繁、经常性地进行,这大大降低了发现环境问题的可能性。

在敏捷尚未盛行,职能分工当道的时代,这些似乎都是测试团队的死穴。

而在他们眼里,只要能找到一位具有丰富架构经验的 ‘冤大头’,并组建一个测试架构部,这些问题应该都会迎刃而解。

就这样,我稀里糊涂的成为了那个 ‘冤大头’。

之前也曾与朋友聊起过这段经历,有朋友说,这些问题用敏捷和DevOps就能解决,用不起来是企业文化的问题,找谁来都只能填坑,起不了什么作用。

一切脱离时代背景的评价,都是耍流氓。

在当时,知道敏捷的人不少,了解DevOps的人也挺多,但真正能体系化将这两样东西落地的企业却很少。理论大家都懂,但如何在现有基础上逐步实践落地,并取得想要的成果,没一个人能说的明白。

而且,伴随着交付压力的增大,研发与测试之间的交流越来越少,所以想通过一些方法,打通交流的障碍。

第一阶段:应用与基础的测试分离

在入职后的半年里,我的主要工作是参与各测试团队的工作,一来混熟人头,二来熟悉业务与现有工作模式。

半年后,我开始与测试总监一起,针对一系列问题进行改进。

先来说说组织结构。

大智慧的系统是建立在C/S架构之上的,所以研发被天然的分割成 “前端” 与 “后端”,又因公司业务分为 “股票实时行情” 与 “金融数据服务” 两个板块,把 “后端” 分为行情服务端与数据服务端。

当时的组织架构采取的是职能式组织模式,既然研发被分成为三个团队,测试也只能紧随其后。

与客户端、行情服务端相比,数据服务端的问题就显得非常多。

以上交所Level-2行情为例,业务场景固化,无论接入协议,还是数据加密,都是非常公开且成熟的技术,而且需求变更少,改动不频繁,只要没有新市场接入,一年到头几乎没几个需求。

反观数据服务端,连续几年公司都重金投入,不仅先后并购了几家数据供应服务商,还对外喊出了 “天天发版” 的口号,气势一浪高过一浪。

这下可苦了研发与测试的小伙伴们,由于并购的公司技术栈各有不同,这家用SQLServer,那家就用MySQL,这家用Java,那家就用C++,环境与集成类的问题层出不穷,为了赶进度,只能胡子眉毛一把抓,管他什么应用还是框架,拼凑拼凑,跑通了就上,报错?拉下来改改,接续上。

一般说,遇到这种紧耦合的情况,就只剩 “拆” 这一条路。

为了不对现有业务的迭代速度造成影响,与研发团队设立了两条拆分原则:

  • 原有业务:如有需求调整,强制迁移至新架构,并将基础与应用进行分离。
  • 新增业务:基于新架构,并将基础与应用进行分离。

经过半年的折腾,无论老业务还是新业务,大部分核心部分基本都已迁移至新架构上。

随即,数据服务测试团队也被拆分成 “基础测试” 与 “应用测试”,一个保障基建,一个保障业务。

就因这一波操作,经公司领导决定,将 “基础测试” 与 “应用测试” 划归我的名下。

我就这样,莫名其妙的睡了一觉,醒来的时候变成了测试经理。

第二阶段:尝试集成测试驱动开发

工作与生活差不多,烦心事总是一波接着一波。

某天午后,领导找我谈话,说开发、测试与运维之间相互推诿的情况日趋严重,想听听我有没有好建议。

咱是读过孙子兵法的人,一听就明白了。立即搬出一番DevOps的方案,领导听了连连摆手,说:“这种大而全的东西少拿来忽悠,来点实际的吧。”

我一愣,想了想说:“要不拿我的两个团队来试点,再不改变现有流程的情况,尝试测试驱动开发怎么样?”

领导笑了,点了点头,说:“嗯,你很主动,大胆的去干吧,我支持你!”

尼玛,我感觉这根本不是谈话,分明是挖了个坑让我自己跳。

什么叫测试驱动开发?

对敏捷比较熟悉的同学,相信一定听说过TDD(Test-Driven Development)。

大致是说在明确要开发某个功能后,在开发功能代码之前,先编写测试代码,然后编写功能代码并用测试代码进行验证,如此循环直到完成全部功能的开发。

在技术圈,很多人都讨厌这种看似完美的理论,因为与现实中的情况距离太远。因为还以黑盒测试为主要手段的我们,就单单 “编写测试代码” 这一项,就会把我们挡在门外。

所以,我们只能寻找一些适合我们当前技术实力的出路。

与其他公司一样,我发现大部分的测试爆发点都集中在集成测试阶段,举个例子证实下。

案例:业务系统新上一个A功能,同时涉及客户端、基础与应用的修改与新增,结果如何呢?

从这张表中可以明显看到以下几点:

  • 各开发都说自己做过了单元测试,并顺利通过,所以我没问题。
  • 各测试都说自己跑过回归测试,并顺利通过,所以我没问题。
  • 每次提交,客户端测试都在群里喊,请大家注意配置项的提交,没人说话。

想起当时有小伙伴调侃过,说每个环节都说自己没问题,但只要放在一起就出各种问题,难道是机房风水有问题?

显然不是,那问题究竟出在哪里呢?

又经过半年的折腾,对环境、配置与组织进行了一系列的调整:

我相信一句话,这世界上从来就没有什么救世主,你强了,你坚信了,困难就变弱了。

到2012年底,我们基本达成 “集成测试团队驱动开发” 的效果,协助开发进行问题排查,并且取代了项目管理的工作。

又因这一波操作,经公司领导决定,将集成测试团队也划归我的名下。

就这样,我似乎又睡了一觉,醒来的时候变成了测试副总监。

第三阶段:试图统一流程与工作方式

三国演义开篇说,天下大事,分久必合,合久必分。

随着棘手问题的逐渐得到缓解,大家开始把注意力放在了流程与规范上。

当时,各测试团队虽然名义上都归属于测试部,但基本都各自为战,你有你的流程,我有我的套路。

比如上级想得到BUG修复率或提测效率这样的报告,基本是不可能的。

另外,像测试流程不规范,测试文档不健全、测试文档也没有控制和管理等问题也非常突出。

2013年初,经公司领导决定,将剩余的客户端、行情服务端这两个测试团队合并至我的团队,成立新测试部门。

我的职务也从测试副总监,升为测试总监。

目标是在年底之前,完成新测试部门的岗位职能、测试流程、测试文档规范、日常项目工作、部门考评机制以及测试部门人员技能与业务的培训等多方面的规划,为公司明年的产品战略提供更高的质量保障。

回想当时的我,满脑子装的都是 “如何帮助研发团队释放潜力” 的激进词汇。一拍脑袋,要求测试所有团队将工作工具从 “Excel+脚本” 切换到Atlassian下。

或许是这一步迈得太大,而且在整个推进的过程中,我也非常强势。

就这样,惹恼了测试团队中的一些老人,为此还吵过几次,气氛开始变得不愉快起来。

细心的朋友可能已经发现,不仅每个阶段的涉及范围都很广,而且都牵涉到了组织结构的调整,那为什么我还会推动的如此之快呢?

强势与强压,是我惯用的两个手段。

在我心里一直坚信,既然高层把这项艰巨的任务交给我,我就要不惜一切代价搞定。

现在回想起来,我像极了商鞅,改革是成功了,人也得罪光了,有人罩着你的时候,或许一切都显得顺风顺水,一旦那个罩你的人不在了,你的死期也就到了。

2013年7月,大智慧已连续亏损几年,业务低迷,人心惶惶,内部进行了一次结构调整,我受到牵连,被调到了一个新成立的部门,负责新技术的探索。

说白了,就是被踹了,被撸了。

2013年9月,我提交了离职申请,离开了大智慧。

一转眼,六年过去了。

每次谈起这段经历,我都说,如果上天再给我一次机会重来,我应该会更圆滑一些,至少能让 “审判日” 来的更晚一些。

人生没有如果,只有后果和经历,而经历却可以转化为财富,为将来的职业生涯做好铺垫。

有的人说,我身上的故事真多,感觉总写不完。

有的人说,我可以去当编剧,故事编的很溜。

我只想说,我是个搞技术的,不会编故事,只不过天生臭脾气,遇到的坎坷自然会多一些。

另外,我愿意将这些事情记在心里,再写出来与大家分享。

如果你也愿意,相信会比我更加精彩。

我还没有学会写个人说明!

白话中台战略:中台是个什么鬼?

上一篇

PostgreSQL DBA(31) - Backup&Recovery#4(搭建流复制)

下一篇

你也可能喜欢

我当测试总监的那几年

长按储存图像,分享给朋友

ITPUB 每周精要将以邮件的形式发放至您的邮箱


微信扫一扫

微信扫一扫