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

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

1、该职位如何创造价值

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

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

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

3、怎么做好测试开发

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

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

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

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

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

你可能感兴趣的:(测试开发,软件测试,自动化测试,测试工程师,开发语言)