对于软件开发中开发人员与测试人员关系的理解
原文:http://www.cnblogs.com/yulinfeng/p/7367957.html
在软件开发中都会有开发人员(以下简称开发)和测试人员(以下简称测试),在一些小型公司可能并没有测试,仅仅是开发兼任测试。在这里我仅针对于有专业的测试和专业的开发的项目。
每个公司应该都有考核机制,对于开发和测试的考核实际上很难量化,通常来讲大的方向就是开发所负责模块的bug数,对于测试来讲就是测出来的bug数,但这真的有效吗?这也许对开发有约束力,理论上开发是能够自己控制bug数的,如果从产生的bug数来评判开发的绩效还算有效,这样开发自然就会把代码写得更加认真。但如果根据测试测出来的bug数来评判测试的绩效,就假设测试为了自己的绩效瞎测怎么预防?
单纯地根据bug数来评判开发和测试的绩效,我认为显然不合适。这会导致开发写代码时小心翼翼没问题,但测试就可能会不可避免的测一些莫名其妙的bug,bug多了测试的绩效高了,同时开发的绩效不就低了么?当然实际当中显然也不会根据这一个维度来评判绩效。
很多时候开发和测试的关系仅是零和博弈。
开发和测试存在目的是什么?开发是为了实现客户的需求,测试是为了保证软件的质量。两者应该是合作共赢的关系,不是零和博弈,不是此消彼长,不是你胜我败。开发和测试实际上是很矛盾的,两者既对立又统一。
毫无疑问开发和测试应该是对立的,如果因为开发过多干涉测试的工作,那这个工作根本无法开展,软件质量根本无法保障,测试岗位的设立毫无意义。两者不存在上下级关系,开发应不惧怕测试测出来的bug,同时测试应“多”测出bug,这个“多”并不是数量上的多,而是质量上的多。开发的代码有质量之说,我想说的是bug的质量也是一个测试水平的体现。开发不能把测试当做大爷一样来对待,测试更不能把自己摆在大爷的位置。
开发和测试的关系同样也是统一的。我认为测试的职责或者测试的成就感不是来自于测出bug,而是能协助开发找出问题并且定位问题。这里的协助并无主次的关系,对于出现bug地方的代码实现测试也许不懂,开发也许也懒得听测试的意见,这个时候并不是测试要和开发一起去寻找代码实现上的问题,而是和开发一起梳理功能的逻辑有无问题,测试以测试的经验和专业技能协助开发。两者统一关系的体现在这个软件是共同的结晶,并不是开发一方的成果,目的都是为了软件能更快更好的发布。
我想在计算机类的专业里,开发和测试两个方向就类似高中时期的理科和文科。很大部分在高中数学不行或者成绩不行就选择文科认为简单,计算机类的专业里稍微有点“志气”的学生也会选择做开发而不会选择做测试,测试的标签就是简单 ,当然这个现象和类比也许并不准确。
测试人员在测试的时候应有一定的专业素养,测试不能毫无逻辑,毫无规划的一通乱测,这有个好听的名字——探索性测试。举个例子:
测试:“出问题啦!某某某快来看啊!”
开发:“怎么操作的?”
测试:“我就点了哪儿就出现这个了啊。”
开发:“那等等,我看下后台日志,你再操作一下。”
测试:“怎么不能复现了啊,刚刚我就是这么点的啊。”
开发:“……”
这个场景常见,如果这个bug本身就是偶现的bug那还说得过去。如果问测试怎么操作的,测试一脸懵逼的说:“我不知道,我忘了。但是你这个有问题就是bug。”这得多花多少开发的时间去排查这个问题啊,不是不让你测,是让你有套路有思路的测,这是对于测试自身素养问题。
同样对于开发人员也是一样的,自测是一个很好的习惯,抛开开发的代码能力,这是对于开发人员最基本的素养。举个例子:
开发内心:“终于做完这个功能了,不测了,反正有测试,让他们去测,测出问题再改。”
很大部分的bug是因为开发自身没有做好自测,单元测试并不是在每个公司每个项目每个模块都有,甚至很多开发人员几年工作经验也不知道怎么编写单元测试。认为自己的工作就是写代码,检验功能是否完善是否有bug的工作应该交给测试去做。
对于开发和测试素养的问题我想这是在理想状态下,或者只存在理论上。实际上开发测试鱼龙混杂、参差不齐、滥竽充数都有可能。但对于开发和测试关系万万不可将开发和测试放在对立面,同样应考虑他们是统一的,矛与盾缺一不可,合作共赢而不是零和博弈。如何维系两者的关系也是一个很值得研究的问题。