再谈开发人员和测试人员的关系
开发人员和测试人员的主要矛盾就集中在对bug的定义上。
测试人员辛辛苦苦发现软件中有问题,报了一个bug。这时就会出现两种状况。第一种,开发人员工作很忙,压力很大,外加心情不好,就会说出如下四类话:
a.你会不会用软件呀?
b.你使用了最bt的方法发现了用户永远也不可能发现的问题
c.由于我使用了XXX技术,YYY方法和受到了ZZZ的约束,所以只能出现这样的问题,所以就不是bug
d.上次都说过了,是你们测试的问题,先保证测试用例的正确性再来测试
而如果开发人员比较闲,也许会仔细斟酌一下,做出下列答复:
e.这确实是个问题。但是是由于我的一个小小的疏忽所致,也不至于报的这么严重吧?
f.老兄,老板们急着要release,我看我们就。。。
也许大家还会碰到别的情况,但是我们测试人员和开发人员总在和这些bug打转,相互打口水丈,所以关系就一直很紧张。
大家也许要问如何解决紧张的关系,我想到了几个方面,也欢迎大家补充。
首先我要为测试人员说说好话,因为我们通常被认为是最不重要的一群人。1)开发人员通常把软件看成是程序,他们的这种认识上的误区会排斥程序以外的其它因素,例如相关的文档。2)开发人员通常把软件的质量等同于软件功能性方面的质量。ISO/IEC9126标准中定义了6大质量特性,我们做测试的人员不应该让开发人员钻其它五项的空子。3)测试人员通常关注的软件的行为,也就是外在表现,是对外部质量的评价。而开发人员通常是关注软件的实现细节,也就是内部构成,即内部质量。外部质量和内部质量是不等价的,也就是说开发人员犯的错误会引入缺陷,而缺陷在特定的使用下才会产生失效。所以我们应该统一和测试人员关于bug的理解和认识,避免分歧的不断涌现。
为测试人员说了好话,也要说说不好的地方。1)急于提交bug,体现自己工作的成果,而忽视了对bug的描述。对测试的步骤,测试平台的配置,产生的现象,造成的影响等都应该尽可能详细。详细而准确的描述不但能让开发人员快速而准确的定位问题,而且便于问题的重现。2)不考虑质量评价的优先级和测试的目的。只是一味的发现bug,使用自己都觉得很bt的方法发现了bug,但是这对于对产品质量的评价和决策能产生任何影响吗?3)大家都是搞技术的,都不愿意接受别人的批评。如果受到了一些言语上的抨击,开发人员更愿意将问题一直拖下去,而不承认自己的过失。所以人际关系的培养和交流技巧的训练对测试人员也是很重要的。