我当测试总监的那几年

题图: 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月,我提交了离职申请,离开了大智慧。

一转眼,六年过去了。

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

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

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

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

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

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

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

Image placeholder
串猪神
未设置
  40人点赞

没有讨论,发表一下自己的看法吧

推荐文章
技术总监到底要不要写代码?

这是一个非常敏感的话题,每次谈论到技术总监要不要写代码的时候,总会引起一片争论。有的程序员说技术总监如果不写代码怎么能领导好技术团队;有的说技术总监还需要写代码?如果技术总监都需要写代码的话,那技术团

研发总监谈:异地研发中心的建设的若干要点(上)

和楼主说好要写一点技术管理方向的文章,从开始说到正式接受主题为《异地研发中心建设模式》的约稿有数月之久,原计划1~2周内写完,结果光思考“应该要写什么”就花了一个月。一方面是拖延癌的原因,另一方面也是

对话OceanBase资深总监韩鸿源:数据库是技术能力,云是使用方式,两者不应是竞争关系

5月10日,在第十届中国数据库技术大会(DTCC2019)上,蚂蚁金服的金融级分布式关系数据库OceanBase2.0,在经过200名数据库领域三年以上的从业者投票和专业评委的评选下,高分荣获了“年度

“我是技术总监,你干嘛总问我技术细节?”

题图:fromZoommy每个周末的午后,把儿子送进EF读书,随后找个环境幽静的咖啡馆坐一会,这便是我一周中最放松的时光。在咖啡厅的气氛和环境这两点上,我似乎有强迫症,比如装修主色调的运用,地上装饰是

2020年PHP面试总结

1.redis输出redis的数据结构?说出redis底层数据结构的实现说出redis的常用场景redis实现分布式锁。2.mysqlMySQL的最左匹配原则MySQL的索引MySQL的常用存储引擎M

Github一天标星1k+,程序员需要知道的那些定理和法则

大数据文摘出品编译:蒋宝尚、曹培信摩尔定律知道么?帕金森定律讲的又是啥?作为一名合格的开发人员,除了本身码力超强外,或多或少要知道几条“”潜规则”,例如依赖倒置原则、鲁棒性原则……关于开发人员必须要知

当中小企业决定上云,真的像你们说的那么简单吗?

题图:fromZoommy四季度历来是一年中最忙碌的时期,辛苦了一年,各项工作都在收官,千头万绪、环环相扣,再加上绩效考核的开展,不但烧脑,而且还烧心。同时,最后一个季度又肩负着为来年开局而打基础的艰

程序员的入门门槛真的那么低吗?

最近朋友说起身边的老同学,好多都转型程序员了,连高中考试都要夹带小抄的**同学都去了,哈哈哈,我就实在是好奇了,程序员的入门门槛真的那么低么?很多人工资低干不下去,想转程序员;还有很多没学历的想改变生

AI+安防 聊一聊云从科技与华为的那些事儿

“尺有所短,寸有所长,物有所不足,智有所不明,数有所不逮,神有所不通。”任何的人或事物都有其长处和短处,如何做到取长补短,是每一个企业都应该关注的问题。  如今,人工智能再次爆发。这一次,不仅在技术上

零基础学测试 2 - 进一步理解 Laravel 的测试与 PHP Unit 的关系

细心的读者可以发现,上一讲中创建的用例继承的是PHPUnit的测试基类。

Testin用iTestin开启下一代测试,测试行业为什么要“重新来过”?

测试,其实并不是一个新话题。从有软件开发开始,就有测试,最早的测试就是找Bug。后来,自动化测试、云测试、众包测试的模式开始成为流行趋势,今天又迎来以智能化为核心的下一代测试。但是,“测试”从简单的软

巧用自动化测试组合拳保证产品质量

一、背景 我们的测试工作经历了以下四个阶段。第一阶段,产品需求评审完成,开发团队实现功能开发,然后草草提测,不写单元测试。测试人员进行人工测试,没有工具或系统做辅助,测试用例编写是在excel或脑图中

我们做了大量工作,可自动化 UI 测试依旧实现不了

对开发者而言,测试的重要性不言而喻。在发布新功能前,开发者需要确保已有功能有效,这就需要将每个发布版本给到QA团队执行人工回归测试。然后,测试人员或QA团队花费数天时间执行脚本以寻找Bug。本文是S

Python 教程-代码测试

测试你的代码是非常重要的。 习惯于同时写测试用例和运行代码,现在被视为一个好的习惯。如果使用得当,这种方式将帮助你更加明确自己代码的功能,以及拥有更加可解耦的结构。 测试的通用规则: 测试单元应该集

GoWeb教程_11.0. 错误处理,调试和测试

我们经常会看到很多程序员大部分的"编程"时间都花费在检查bug和修复bug上。无论你是在编写修改代码还是重构系统,几乎都是花费大量的时间在进行故障排除和测试,外界都觉得我们程序员是设计师,能够把一个系

GoWeb教程_11.3. Go 怎么写测试用例

开发程序其中很重要的一点是测试,我们如何保证代码的质量,如何保证每个函数是可运行,运行结果是正确的,又如何保证写出来的代码性能是好的,我们知道单元测试的重点在于发现程序设计或实现的逻辑错误,使问题及早

并发测试

并发 这是我们的计划:同事已经写了一个CheckWebsites的函数检查URL列表的状态。 packageconcurrency typeWebsiteCheckerfunc(string)boo

如何通过测试驱动开发构建 Laravel REST API

这是TDD和敏捷开发方法学的先驱之一 JamesGrenning的名言 如果您不进行测试驱动的开发,那么您将进行后期调试-JamesGrenning 今天我们将进行测试驱动的Laravel之旅。我们

零基础学测试 1 - 在 Laravel 中使用 PHPUnit

创建Laravel应用$laravelnewmind-geek-laravel-test-demo进入项目$cdmind-geek-laravel-test-demo运行自带的测试用例$vendor/

2019年 度中国测试行业问卷调研来啦! (有奖问卷)

2019年度中国测试行业问卷调研(有奖问卷)开始TesterHome在2018年的时候,发起了一次全中国的软件测试行业的问卷调查,当时反响很不错,收集到了2000多的用户数据,通过这些数据我们看到了其

在 [slim] 中伪造 Request 来进行你的 HTTP 测试吧

代码需要做HTTP测试,Laravel中有自带这方面的功能。现在使用slim就得自己动手丰衣足食。 网上找了许多例子,关于这方便的比较少。然后就想到了查看Laravel的源码 看了一下,发现其实是自己

TPC-C解析系列03_TPC-C基准测试之SQL优化

TPC-C是一个非常严苛的基准测试模型,考验的是一个完备的关系数据库系统全链路的能力。这也是为什么在TPC-C的榜单前列,出现的永远只是大家熟知的那几家在业界有着几十年积累、从关系数据库理论开始发展就

TPC-C解析系列05_TPC-C基准测试之存储优化

TPC-C规范要求被测数据库的性能(tpmC)与数据量成正比。TPC-C的基本数据单元是仓库(warehouse),每个仓库的数据量通常在70MB左右(与具体实现有关)。TPC-C规定每个仓库所获得的

TPC-C解析系列01_TPC-C benchmark测试介绍

作者:阳振坤2019.10导语:自从蚂蚁金服自研数据库OceanBase获得TPC-C测试第一名后,引起了行业内外大量关注,我们衷心的感谢大家对OceanBase的支持与厚爱,也虚心听取外界的意见和建

专业人士必备的10个渗透测试工具

渗透测试,也被称为穿透测试或道德黑客攻击,就像电影《Sneakers》中那样,黑客顾问在攻击者之前侵入你的公司网络,找出弱点。这是一个模拟的网络攻击,pentester使用恶意黑客可用的工具和技术。在