聊聊测试开发工程师的职责定位问题
网上有人会把测开定位成为 测试工具开发，主要是开发自动化测试工具或平台，用以帮助手动验收的同学提升效率。存在即合理，确实有一些团队或组织是这样建设的。但作为行业从业者，我们也应该认识到，这样是不全面的，有误导之嫌。
现实中的绝大部分测开还是定位在 保障业务迭代质量 上，因为这才是业务最需要的部分，也是最能直接产生价值的部分。而工具开发，属于 提效 范畴，当然也需要，但其紧迫性以及价值会因企业而不同，也会与企业所属的发展阶段息息相关。所以很多时候，工具具体能提效多少，都需要工具开发者能够想清楚，甚至要能显式证明。
也许大家会觉得，保障业务质量招聘测试就可以了啊，为啥要招聘测开呢？其实这是把质量保障这件事想 Low 了，从 最终服务于客户的质量 出发，要想做好质量保障真没那么容易。很多质量领域的事情，都不是单纯的测试能搞定的，但又是客户必须的，比如速度，可靠性等。测试仅仅只是质量保障的手段之一，还有很多其他的手段也仍然有效。就拿架构评审，代码 Review，发布审核等事项来说，要想参与无疑都需要质量同学对技术有更深的认知。笔者最近也在尝试通过发布审核来把控全局质量，所以也非常想看到有更多的质量同学往这方面发展，大家能彼此探讨。
不过，毕竟时代局限性仍在，从事质量领域的同学还是以测试为主。所以，此时如果企业想招聘一位技术比较好的测试同学，她一般 JD 都会选择叫 "测试开发工程师"，因为这样能更好的匹配预期。要说明的是，在企业内部其实叫什么真的不重要，也没太有人关心，企业看中的始终是价值产出。私下里，我其实更喜欢 QA(Quality Assurance)这个称呼.因为我会觉得QA 包含 Ownership 意味，寓意我在负责某件事。而"测开"的叫法感觉跟"开发"一样，字面上更像个执行者，总是欠缺了那么一点主观能动性。
另外，当团队里所有的 QA 同学都有不错的开发水平时，你会发现，很多常见的"测开工具" "测开平台"需求就会显得不是那么刚需，甚至可能没必要。比如，相比通过 Web 或者 Excel 管理用例，直接用代码+Github 管理对经常写代码的同学来说可能更自然；执行用例也是，通过命令行，或者 Jenkins/Prow，也很方便；另外，Postman 可能会用的很少，因为对于经常与服务器打交道的同学，使用 curl 会更方便，其也基本够用；甚或者想搞个简单的压测，用系统自带的 AB 工具(Apache benchmarking tool)随手就完成了。凡此种种，笔笔皆是。
说到这里，有同学可能会问: 测开同学除了测试任务，就没有提效的要求吗？会不会大材小用？当然不是，在这种情况下，一些提效需求反而可能更具挑战性。因为这时候的提效目标就不是单指 QA 了，而是要面向全体工程师，甚至后者优先级更高，毕竟群体规模越大，投入产出比越高。另外就是需求越往上，需求的边界与传统的测试会越模糊，与业务越直接。比如发布灰度、质量运营、监测打点等等，这些系统都与质量有关，测开同学有能力的话当然也可以上。
总结来讲，对于测试开发的职责定位，我始终认为应该聚焦在 保障业务迭代质量，提升迭代效率 上，这点不应该变。而更具体的做法我会倾向于宣导：
- 做业务的质检者, 关注检出率、漏出率，把控全局质量，为企业把好生产交付关。
- 做工程研发专家, 保障业务迭代规范，加速迭代效率，关注软件工程技术的研发角色。
好像看起来挺难的，但不难的话又如何进步？