再谈开发人员和测试人员的关系

xiangxiang

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

ppent

写的很实在，顶

tongke

测试和开发是要搞好
关系地...

rickyzhu

楼主总结的很好.
提bug之前最好和开发口头沟通,一来开发有个思想准备,二来也确保你的bug确实是个问题,而不要被开发发现是环境配置问题而被reject,到时候大家都不好看,另外bug的优先级和严重级别,建议让开发自己定.
我以前就是这样跟开发打交道,跟开发的关系非常好. 其实我自己也做过开发.



"也就是说开发人员犯的错误会引入缺陷，而缺陷在特定的使用下才会产生失效" 这句话好熟悉,"软件质量保证"这本书里面的一些观点值得借鉴.

xiangxiang

对于因为配置问题而被踢回来的bug，从技术层面来说，我们测试人员应该根据具体的情况做出报告。因为同样的问题在用户的手上也会出现。出现这样的问题，有两种可能：1.没有明确的说明如何去配置（开发人员口头给我们说了，他们难道也口头给所有用户说吗？）2.用户错误的理解了配置说明，造成系统不能正常工作。对于1，它其实是软件可用性上的问题。对于2，它其实是软件可靠性上的问题。这样的问题，程序员是不愿意接受的，因为他们只看到了他们的“代码”，只看到了他们“代码”完成的“功能”，而这仅仅是软件及其质量的一部分。
我们测试人员应该将这样的问题反映出来，客观的反应软件质量方方面面的现状，而不是冰山一角。所以在公司建立对产品质量的认识还是很重要的。然而，我们需要根据具体情况具体考虑质量特性的不同方面，设置不同的权重加以评价。出现放弃上面的bug的情况其实我们是做了不考虑软件可用性和可靠性假设而做出的决策。
当然光搞技术是搞不出来好产品的，毕竟软件是大家合作的结果。从非技术因素出发，和开发人员搞好关系，做最重要的事情，多拍拍开发人员的马屁也能够增加团队的工作效率，对软件质量的提高也是有好处的。
权衡技术因素和非技术因素也许是更好的途径，瞎说：）

[ 本帖最后由 xiangxiang 于 2007-3-30 17:23 编辑 ]

ia_victory

不错，支持一下，做开发的有时候就是很横

SWeiNi

呵呵,如果公司不用提交的bug数目来衡量测试的价值(确实存在这种情况),发现bug后其实是可以直接和开发人员交流的,和善的语言沟通和确实的bug存在,大部分情况下还是可以让他们接受的

null2

用提交的bug数目来衡量测试的价值
==========
这是本人坚决反对的，可是有些领导就认这个

Coffey111111

测试人员确实是需要开发人员的指导，同时开发人员也离不开测试人员的，沟通与交流是最重要的~~

windyfreeze

原帖由 xiangxiang 于 2007-3-30 17:16 发表
对于因为配置问题而被踢回来的bug，从技术层面来说，我们测试人员应该根据具体的情况做出报告。因为同样的问题在用户的手上也会出现。出现这样的问题，有两种可能：1.没有明确的说明如何去配置（开发人员口头给 ...

拍马屁？？真亏你说的出，不过有时也要做做手段的。sdlkfj1

wuyuzimu

有时候还是要适当给开发人员鼓励的, 这样能保持愉快心情快速修复bug, 这样我们也就能快点close.
虽然他们有时候确实很让我们气氛......

sephiroth

恩。有道理，我看到过一句很有道理的话：最好的测试人员不一定是发现BUG最多的测试人员，而是是开发人员修复BUG最多的测试人员---Cem Kaner

cuteau

不理解的是bug难道不应该首先报到PM那里吗？为什么开发人员会直接和测试人员扯皮？

wujp_652

再谈开发人员和测试人员的关系


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

sanwong823

我负责的系统有个开发人员对我的态度不是那么好，发邮件很少回，打电话没几次接，发现的需求bug也要把业务推出要跟他争吵一翻之后，他才肯修改程序。
  上周忍不住开门见山地问他是不是对我们的测试很不认同，并把我们发现的缺陷对他们的好处说了一翻之后，现在他似乎对我的态度有所好转了，蛮高兴的~