当开始写这篇文章时候，才感受到人生如白驹过隙，4 年时间飞逝，自己也从一个初入职场小白到能肩负项目核心事务的测试开发。在这里，总结 4 年来的心智成长之路，也是借机互相交流，并无对错之争，欢迎有见解的讨论，共同进步。
经历
在两个大厂分别做了两年的测试开发工作，暂且成为 N 厂和 A 厂吧。负责过游戏自动化框架开发、专项测试工具开发、版本质量保障、Devops 平台开发，也带过小团队。每个厂，每份工作都力求突破，过程辛苦，自然结果都是很满意的，都拿到了不错的绩效。
测开的岗位定位
虽然在经历过的项目中，测开的定位大部分都是 “测试”，在 N 厂里面架构会比较特别，将测试开发与业务测试彻底分开。测试开发更多是做 测试平台和效能提升相关工作；业务相对单纯，整个团队会一起 面向功能测试痛点、研发痛点从质量检查角度出发做工具与平台，解决研发过程和测试过程的痛点。
这份经历回想起来，还是很有意义：做事非常专一，技术也获得了不少成长。唯一不足的是，这些工具、平台也好，是否真正让业务产生了更实质上的提升，很难去精准量化。后期也做了很多量化工作的事情，建设量化的数据模型；所以切入 Devops 赛道，学习了很多 Devops 理念，造了一些轮子。当然一个人的精力是有限的，在一个成本中心里面，想去做 Devops 是很容易上手，但是做完善一整套 Devops 落地，几乎不可能的。
后来的工作，就开始跟业务了，能非常明显感觉到，业务带队水平的提升，沟通能力的提升，更多从一个质量保障的角度去做质量输入和输出，也算是亲身体会到了 QA 这个职业的 “不容易”：人在工位坐，锅从空中来，深有体会。
两段不同的经历碰撞，对测试开发这个岗位有了更纵深的思考，包括岗位价值、核心竞争力、行业发展有了一些思考。
测开核心价值
测开的定位既然也是测试，那么它的核心价值其实一句话可以总结：为质量买单，为产品保值，为过程降本。
测开本质上归属于测试序列，哪怕再厉害的测试技术、测试平台、测试工具，不要被这些所谓的 “高大上” 的技术名词掩盖了真相。做这些自动化、平台工具最终都是为了更短的时间、更低的成本输出质量，然后（这里是重点）根据输出的质量去买单。这里说的直白一点，做的这些事情当然有意义，但是跳出本位思维，站在老板，站在项目经理的角色去看待，想要的只是质量结果和谁为这些结果买单。
总有人需要为结果买单，为过程买单，核心价值也就出来了。作为测试序列的一员，最重要的存在即为质量买单。也就催生出了，为什么测试要负责过程管理、左移右移，很少见到开发提到右移到测试。测试岗位的内容自然就杂而不精了：不是一个很合格的项目管理、却又要参与项目管理环节；不是一名单纯的技术，却又要在业务测试中兼顾工具开发。甚至个别项目或者公司要求测试也要负责需求的质量把控。
因此，在一个买单岗位他的存在大部分除了输出质量之外，本身不产生直接的商业价值，成为了一个背负成本的节能减排部门。也就是上面提到的为质量买单，为产品保值，为过程降本。
测开的职业瓶颈
在参与了很多项目之后，越来越能体会到，对话维度不同的平台，更能体现测试岗位的无力感，也是焦虑感。当你明白了核心价值后，那么谈发展时候，谈行业纵深时候，就会发现很现实的问题：
- 部分项目核心的前后端业务逻辑和代码是保密的，或者只开放冰山一角，很难真正全貌去做业务纵深，不利于个人的长线成长；
- 测试序列作为一个成本保值部门，自然要肩负很多杂活脏活，零碎的时间和权限壁垒很难像做一款产品一样，去完整形成价值链，没有价值链谈什么个人价值呢；
- 技术路线的测开会发现，纯测试开发技术大部分都服务于 QA 或者小部分人群，这些系统都未经标准化的开发管理，也没有外网的海量验证，技术的深度和广度在上游开发看来，不值一提。
自我升级
跳出局限的打杂思维，去打破边界尝试做更专业的事。
如果善于沟通，利用测试已经具备的全局质量管理意识，可以往项目管理层面靠拢，去做一个真正的项目管理岗位，有质量思维做项目管理至少初级是超越了大部分非科班的项目管理了。
喜欢做技术，或者转做更上游的开发岗位或者具备领域门槛的研发岗位，专一纯粹去做技术思考和规划，把核心技术深入理解并向架构等方向纵深。
不要止步于下游赛道，虽然说每一个赛道有它的前景，但是也要知道，除了努力，也要看历史的进程。
最后
还是想补充说道，四年来最大的感悟也不止工作上，在思考维度上更全局和本质去看待一个事物发展的规律。今天的测试赛道固然舒适，固然简单，但是这都是锦上添花，可是这些都很虚。业界大厂测试真正落地、沉淀了多少具备输出价值的东西？不得而知。不妨思考，测开岗位究竟带来了什么？这个赛道究竟是为了什么而存在？