开发转测试没人要_测试开发如何转型

本公众号是打算讲软件工程，一个软件开发周期内的方方面面的内容。

然而有个很核心的问题：实际上，现代软件开发，严格说互联网软件开发和传统软件开发流程，包括团队设置的核心差异恰好就是看有没有专职测试人员(外包QA不算)，你看敏捷开发，scrum开发里面哪里有test lead这个概念，只有scrum master, pm, dev lead等等。而现代开发流程中最核心的两点：code review和unit test，其中unit test就是个首先要解决的问题：谁来写？在过去是测试开发来写，而现在则是feature owner，谁负责功能开发谁写。

而google更推荐80%的测试都是单元测试，更进一步将测试开发的传统工作削减到次要得不能再次要的角色，实际上也是为什么google的测试开发团队后来干脆改名叫做Tools&Infrastructure team了。

微软则为了转型，干掉CEO之后才做到了全面敏捷化----什么意思？测试开发SDET全部干掉(QA倒是在这之前就去掉了)，全部分到产品团队去，然后才有了今天的股价翻几乎10倍。

传统的测试开发就是高端QA，必须转型。但在国内很难转，国内的测试圈子根深蒂固，其来源主要是以前外企的测试部门(其实就是外包到国内的QA，为了好听称之为研发部门啥的)利用前几年外企在国内互联网圈所获得的地位，翻来覆去强调“对质量的重视，对测试的重视”云云(特别是微软)，问题是国外对测试的重视是叫开发人员要自己负责测试，不是在核心部门专门建个测试团队来“专职测试”。。。

但是实际上这个问题随着国内互联网企业日益成熟，对软件工业化的理解越来越深刻，也得益于越来越多硅谷工程师的回国带来真正国际一线互联网公司的实践经验和团队结构，国内的互联网企业也开始了对过去QA及测试开发的人员优化(当然，也就是一些互联网头部公司才有专门测试部门这些设置，中小公司哪里能有这么奢侈的待遇，业务开发能够不关心自己代码能否work就提交上去，抛给QA检测。。。)

因此，在这个转型和人员优化(大家懂)的过程中，测试开发如何定位自己？如何顺应时代大潮改变自己，提升自己，改变工作习惯，则是这次要讨论的问题。

这次我们分几个部分来讨论，中间可能私货较多，如有不同，请自己思考

• 中美测试开发转型的差异

• 测试开发自身的局限与苦恼

• 平台开发的方式

• 测试开发如何转向平台开发

---

其实测试开发本身转业务/产品开发很简单，直接分拆到产品团队，成为产品团队的一员，这对PM来说是好事，开发人员更多了，可以提更多feature需求了。。。

至于测试开发如何适应，无非就是选择适合的内容去写代码呗。这个问题对于亲历过微软转型全过程的资深工程师来说，是一个很直接明了的事情，下面是某位微软朋友聊到这事情时的反应：

但是这有个前提：测试部门解散，合并入业务产品部门，工作由业务产品部门来分配，从此测试成为过去式。这个改变相当激烈(微软CEO下台后才能真正实施)。而且微软当年的SDET在技术背景和开发能力上如果说距离google/facebook的正式开发有差距，但起码也在业内其它二线公司的正式产品开发水平之上，要转型也不是啥太难的事情。

但在国内的各大公司，据多方了解，并非如此(要知道微软可以是在巨大压力下干掉了CEO，才能做得这么坚决)。各种质量部门/测试部门山头林立，人员臃肿，自动化测试更是个幌子，真正做的还是大量的人工手动测试，对这些人的转型是个非常艰巨复杂的工作。同时在产品开发侧，国内的业务产品开发也不像Google/MSFT的开发人员那样乐于写单元测试，乐于对自己的代码质量有ownership，加上大部分产品代码架构非常糟糕，从来没有考虑过真正的模块化，谈不上testability，要对代码写单元测试本来也是难于登天。因此国内公司无论是测试自己还是开发人员都具有很大的能力缺陷，无法像微软那样主要是政治斗争，上层摆平后一声令下就可以转型。。。

上面那位微软的朋友提到可以由infra的开发来带sdet转型，这又涉及到一个差异：国内其实并没有真正的infra团队，某个角度来说国内这几年炒作的“中台“是带有一些infra的意思，但实际上在基础架构和业务服务之间，对国内绝大部分公司来说是很混乱的，所以才造出“中台“概念。而Devops本身是infra的一个分支，又跟CI/持续测试紧密结合，因此国内测试开发转型的同时，通常还不是转往相对容易融入的产品开发，而是往最具难度最具挑战的基础架构infra方向转变(因为以前没人专门去做)。。。

从这些因素来看，国内的测试开发转型是一个较长期的过程，实际上是希望让测试开发和其它人员一起去搭建一个工业化生产流水线平台，而这恰恰是最难的。要谈个人如何在技能上转型(如果你不想跳槽或者换团队)，就要自己摸索如何去转变自己的技能树和工作习惯。要做到这点，首先要了解测试开发自身的局限和问题所在。

测试开发的局限与苦恼

上周我们谈过为什么Devops系统并不适合由测试开发来主导，其中提到了测试开发的一个很严重的问题：一直是面向QA需求，而不是面向真正产品需求。

我们也可以说，测试开发的朋友们写了很多helper class, helper method, util function，然而，他们基本上没有去负责过一个完整产品从头到尾的研发过程。在过去微软的一些SDE岗位招聘中，喜欢要求具有full product lifecycle(完整产品生命周期)的经验，其实意思就是你需要知道一个产品从概念到市场需求调查，到设计方案到初版开发到最终上线，经历过紧急bug修复和无数需求改变的折磨，能预料到代码实现了基本功能后远不是结束，还有无数的坑等着你------明白了这些并能在产品开发过程中为这些坑提前做好铺垫准备(时间上、数据上、代码结构上、单元测试上、以及和其它相关开发的沟通上)，这才算是进入了一个算得上有产品开发经验的境界。而测试开发因为没有这样的环境，始终停留在工具开发这个环节，而且还是小工具那种(哪家的测试自动化工具有超过1w个用户还是咋的？)，所以其技能始终停留在一个较狭窄的范围里。

好了，不喷sdet了，还是直接点：如何改变？如何进化转型？

先整理一个图表，把重点画出来：

我们这里不谈比如游戏/社交/电商这些具体to C产品的开发工作，就拿Paas化的研发工具平台来跟测试工具做比较。

首先要面对一个现实：研发平台，尤其是作为Paas的研发平台，在国内非常少见。不少公司内部虽然有，但是其使用体验也是难以言喻，基本没法和国外的相提并论。因此在这里我们只能用国外的一些研发平台来做比较。