我们到底需不需要测试研发？

今天面试了一个测试老兵，颇有一番感慨，写出来分享一下。

---

现在行业内的测试研发岗，我大致分以下几种：

1、为业务测试团队提供技术支持，测试框架工具开发，指导比较难的非功能测试。这种基本上是因为业务测试团队人员代码能力较弱或者很难独立来做非功能测试。一般发生在中小型互联网团队中。

2、服务于整个研发团队，引入工具或者开发工具提高效率和质量，类似于工具组。一般也发生在中小型互联网公司。

3、只做自动化，写脚本，跑回归，这个发生在大型软件项目（一般为外包）。

4、负责业务线所有测试内容，可以定义为全栈测试工程师。一般发生在大型互联网公司技术能力较强的团队中。

5、负责整个测试团队测试体系的建立，测试技术栈的确立。一般发生在初创公司。

从绩效角度来讲，其实4和5是最能出成绩的，但是5的风险会大一点。

从工作舒适度来讲，3是最轻松的，但也是成长最慢的。

现在不少公司是1和2的情况，因为以前的测试门槛较低，这就造成了很多测试人员不能写代码，技术能力薄弱，但是要提高效率和质量怎么办，就出现了1这种测试研发小组。至于2，那是从1演化而来的，因为作为软件工程来讲，持续集成、项目管理、质量分析、代码review、代码检查等等都需要工具，那谁来做，开发不自己做，那只能有个小组来做来推进。

讲讲1和2的利与弊：

利：可以短时间内快速解决测试或者研发流程中的痛点，提升项目效率与质量。对于个人来说，也可以增加代码实践能力，有些也能增加产品思维、工程思维。

弊：由于与业务本身存在一定隔断，当解决了一些最重要的问题后，整个团队的重要性会不断下降，导致团队的绩效后期可能是很难上去的，也会很快面临成员的流失。

其实从我个人的经历来讲，我是不建议有多年经验的人员去做1或2的工作，这样自己的职业发展道路会越走越窄。这也是针对今天面试的人员，我最终给他的建议。

作为现在类型2团队的负责人，我也在思考后续的团队发展，希望能够尽快完成重要并必须的系统开发与推广，后续进行一定的团队方向调整，比如增强给业务测试培训的占比，把系统做出更产品化等。

等到把各业务线有一定比例的人员技术能力提升到全栈水平，那就推进整个测试团队朝类型4发展。而现在这个团队就变成动态变化的，可以由1-2年经验的人员轮流担任1年，直到不需要为止。

至于我自己，我还得想想。