今天来跟大家聊下我当年做测试总监的一些经历。
每次问我有关职业发展的问题时，我都会反问两个问题。一是你当下最喜欢做的工作是什么，二是你当下最擅长做的工作是什么。
面对这两个问题，大部分人的回答都很相似。先是一愣，然后含含糊糊的说三个字 “不知道...” 或 “没想过...”。
的确，吃喝玩乐，娶妻生子，才是大多数人的基本诉求，什么理想与目标，似乎都不是你蹦一下就能够得到的，这种感觉像极了一头拉磨的驴子，只能蒙着眼睛不停的向前跑，否则就会挨鞭子。
我常说，哪有什么人生规划，都是历史机缘的巧合罢了。
就像我的简历，凡是看过的人都会问：“你做过测试？为什么会选择去做测试呢？”
选择？对很多人来说，职业生涯的发展真的是选出来的吗？一切都是被迫的，一切都是莫名其妙的。
以前我曾说过自己带着两年的创业史，身背近五十万的债务，来到了大智慧办理入职手续，开始了新的人生。
这段台词非常耳熟，像极了小时候看到的童话小说，王子和公主从此过上了幸福快乐的生活，恩爱一生。
很可惜，人生毕竟不是小说，把一个人写死了，还可以用某个场景让他复活。
1
相信大部分的人都有过走投无路的经历，在残酷的现实面前，什么理想，什么目标，都变得毫无价值，能活下去，才是当务之急。
2011年底，那场创业悲剧，让我和我的家人几乎陷入了万劫不复的地步。
在公司开始清盘的第二周，有位朋友给我介绍工作，说是大智慧在招聘架构师，对口研发中心的HRBP正好是他女朋友，问我有没有兴趣。
这真是天无绝人之路，来早不如来得巧，关系那么铁，我自认为八九不离十。
“太感谢了，没想到就我这点破事，你还挂在心上了。”
“先别忙着谢，有个事情要先说下，这个正在招聘的岗位归属测试团队，也就是说，如果你过去，职位最多是测试架构师……”，电话那头的声音显得有些无奈。
“不知道你是否在意？听说这个岗位他们招了半年，一直不理想，我觉得你肯定能够胜任。”
对当时的我来说，与岗位和职务相比，收入与稳定性对我的吸引力更大。
“无所谓，帮我安排面试吧，”这种爽快程度，连我自己都不敢相信。
“你下午就过去吧，我女朋友那边已经给你安排好了。”
以前的我从来都不信什么牛鬼蛇神，也不信小说上那种纯情的完美结局，但此时此刻，我似乎感觉面对未来以后充满了希望，但又无法面对。
2
面试进行了2个小时，面试官是当时的测试总监，近四十的年纪，说话很稳重。
在谈话中，我们交流了有关阻抗测试的各种问题，并探讨了一些传统测试转型的方法。
这方面的记忆力是我的强项，至今我任然记得一些：
1、只能发现问题，无法解决问题
测试环节，常常在代码编写之后，就算测试小伙伴的能力再强，通过九牛二虎之力测试了致命性问题，但为时已晚，要想重新折回头处理其中的问题是要花费一些时间和精力的，降低了交付效率，如果不打回修复，则无法保证质量。
2、有能力的不愿意做测试
从事测试工作的小伙伴，一般都没有研发能力，有研发能力的一般也不会来做测试，毕竟无论从地位，还是收入，开发都要比测试高一些。
这就形成了马太效应，好的越好，差的越差。
3、业务测试与业务验证，傻傻分不清
通常情况下，讨论需求的时候，业务方都会叫上开发，毕竟需要开发去实现，但绝不会叫测试。
这里会形成一种尴尬，因为测试员不可能理解所有的代码，而且没有参加需求环节，所以漏掉一些重要的测试是很有可能的。但业务方不会遗漏，毕竟这是他们的工作核心。
因为，我们经常会碰到，测试没测出的问题，却在业务验证时发现了。
然后有趣的场景出现了，业务怪开发，开发怪测试，测试直喊冤枉。
4、测试环境是世界级难题
测试环境，是每家公司最头痛的问题。比如测试通过，生产报错，再比如测试人员编写的测试是依赖的文档或其他东西，而不是代码，配置和数据存在任何不一致的地方的时候，就会造成问题。
另外，如果测试不是自动进行的，那么极有可能不会被频繁、经常性地进行，这大大降低了发现环境问题的可能性。
在敏捷尚未盛行，职能分工当道的时代，这些似乎都是测试团队的死穴。
而在他们眼里，只要能找到一位具有丰富架构经验的 ‘冤大头’，并组建一个测试架构部，这些问题应该都会迎刃而解。
就这样，我稀里糊涂的成为了那个 ‘冤大头’。
3
之前也曾与朋友聊起过这段经历，有朋友说，这些问题用敏捷和DevOps就能解决，用不起来是企业文化的问题，找谁来都只能填坑，起不了什么作用。
一切脱离时代背景的评价，都是耍流氓。
在当时，知道敏捷的人不少，了解DevOps的人也挺多，但真正能体系化将这两样东西落地的企业却很少。理论大家都懂，但如何在现有基础上逐步实践落地，并取得想要的成果，没一个人能说得明白。
而且，伴随着交付压力的增大，研发与测试之间的交流越来越少，所以想通过一些方法，打通交流的障碍。
第一阶段：应用与基础的测试分离
在入职后的半年里，我的主要工作是参与各测试团队的工作，一来混熟人头，二来熟悉业务与现有工作模式。
半年后，我开始与测试总监一起，针对一系列问题进行改进。
先来说说组织结构。
大智慧的系统是建立在C/S架构之上的，所以研发被天然的分割成 “前端” 与 “后端”，又因公司业务分为 “股票实时行情” 与 “金融数据服务” 两个板块，把 “后端” 分为行情服务端与数据服务端。
当时的组织架构采取的是职能式组织模式，既然研发被分成为三个团队，测试也只能紧随其后。