开发人员和测试人员的主要矛盾集中在对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)大家都是搞技术的，都不愿意接受别人的批评。如果受到了一些言语上的抨击，开发人员更愿意将问题一直拖下去，而不承认自己的过失。所以人际关系的培养和交流技巧的训练对测试人员也是很重要的。