中小团队里的测试开发工程师理解

测试开发工程师，一开始接触这个职位的时候觉得这个称呼有点奇怪，怎么又做测试又做开发呢，在质量管理中，是不提倡自己测试自己开发的内容的。
后来才知道该职位里的开发，是指针对测试团队里的需求，而非业务需求。是因为随着行业节奏的加快以及测试团队发展，仅仅依靠手工测试人员或自动化测试人员，整体效率已经无法满足业务或团队了，需要开发更专业的工具、平台、自动化过程等才能满足当下的效率。
在中小团队中，测试开发工程师的输出一般都是以工具或平台的形势呈现。今天主要想聊聊这个职位如何创造价值、与测试人员之间的关系、怎么做好测试开发。（仅限中小型的团队）

1、该职位如何创造价值

在中小团队中，这个职位往往只有1个人，甚至还是一个兼岗，还需要同时兼顾业务测试。其实这并不矛盾，无论是测试、QA、自动化测试、测试开发，本质上都是在为团队提供质量保障，只是方向不大相同；测试开发的主要方向就是效能，当然是保证了质量前提下的效能，所以这个职位的价值就是在帮助团队提高测试效能，提高的方法包括但不限于开发工具、平台等。

2、与测试、QA人员之间的关系

早年其实大家也都知道，测试的门槛很低，而这10年又是互联网的黄金10年，职位多，人少，大约在2015年，我记得有个统计，说测试人员的缺口大约有20万，而且还有不断扩大的趋势，导致测试门槛非常的低，转行过来，只需要培训几个月就可以找到工作。所以测试这个职位在研发体系中，也是鄙视链的最底端，无论是其他岗位或测试人员自己都是这么觉得的。而测试开发岗位出来，明显要求高了很多，所以很多测试开发似乎就觉得我是高了测试或QA岗位一等的，所以我提供给你的工具或平台，难用、不好用、效率不高，不是我的问题，是你不会用，是你没有技术，不是我测试开发的问题。我们的测试人员又非常的好学和谦虚，也非常认可这个观点。最后的结局就是测试开发输出了很多东西，测试人员也都用上了，但最后测试的效率并没有发生变化，部分团队甚至还出现效率更低的情况。这个现象其实不奇怪，是行业问题，只是我们还没有意识到，其实测试开发应该是服务测试人员的，甚至是乙方和甲方的关系，测试人员才应该高测试开发一等，工具、平台难用、没用，应该提出来，甚至直接摒弃掉才是。测试开发也应该多收集测试人员的意见，以满足测试人员、提高效能为目标，而不是自我陶醉在所谓的高大上的架构、技术、工具上。

3、怎么做好测试开发

一

应该搞清楚自己的定位，测试开发和测试人员是一个战壕里的战友，甚至测试开发自己本身也是测试人员，所以应该是双方共同努力，达到提高测试的效能和质量的这个目标。

二

是学会洞察团队的研发过程，测试是贯穿研发全生命周期的，每个研发过程都有可能影响输出的质量和效率，可以通过开发的手段，不断的改进研发过程，例如可能可以观察到测试人员的用例输出比较慢，而且用例评审会经常第一次评审不通过，但测试人员本事并没有问题；根因分析后发现是需求封板后在细节上还是会有一些调整，由于需求细节同步不到位，导致的测试用例疏漏，最后到评审会才发现，而且评审会由于是每个测试人员都用自己的xmind写的用例，每个人都来讲解用例，耗时较长，又没有一个用例协调工具，经常出现测试人员之间用例冗余。那如果这是一个长期存在的问题，不仅可以从过程制度上进行改进，也可以研究相关的协调工具或平台，去解决这样的问题。

三

是切勿觉得大厂那些高大上的技术，就一定有用。人都有水土不服的情况，何况是技术，引进技术一定要根据项目的实际情况来，而且就算有可行性，也要先做试点，不能直接大规模强制的推广，一个好的技术或工具，我们只需要做好落地适配，讲解清楚，积极响应业务测试团队，如果它真的是能解决测试团队的问题，那么自然会有人愿意使用它，如果没有，就需要再思考技术本身是否适合，以及落地适配和测试人员是否真的理解这个技术的作用。

四

是一定要多听取业务测试人员的意见，并自己深入到团队中，和业务测试人员实实在在的一起进行测试，去挖掘潜在的还可以提升的地方。不要闭门造车，即使这个车真的很快，团队的人员也不一定愿意去接受，适合自己的车，才是好车，不然为什么有测试开发这个岗位的存在，那直接使用市面上最先进的过程、工具、平台不就好了吗，测试开发人员的价值就是在他能够根据团队的变化，去调整自己提供的能力，使整个过程达到最佳的状态。

五

是随时做好重构的准备，时代是一直在变化的，再先进的技术，在成熟的过程，随着时代的变迁，时间的推移，团队的壮大等，都有可能变得不合适了，不仅需要不断的迭代已有的平台和能力，还需要做好重构的准备，就像一张滤网，即使一直清理上面的灰尘，滤网也有寿命达到，需要更换的那一天。
此致，这是一个快速变化的时代，我们不应该畏惧变化，一成不变才是最可怕的。拥抱变化，持续进步，一起加油吧！