缺陷拒绝引起的矛盾

likejuntesting

我有一个问题想请教一下各位.希望大家能给我点建议
最近我遇到一个问题,和开发人员产生了一点矛盾,事情是这样:
现场需求人员提了一个新增需求(个人认为这个需求的功能点比较简单,就是新增一个字段,但是如果设计测试用例,也会有很多个验证点),花了半天时间验完后,发现了不少bug,然后我就将缺陷拒绝,开发人员对我这种方式有意见,觉得我不应该拒绝,而是应该另提缺陷,因为他觉得需求描述不清楚,个人感觉是他觉得缺陷应该把要验的功能点都一个一个写清楚,他才知道要改什么,因为这件事情大家弄得都不高兴,我觉得他是为了逃避考核,老是变着方法来让我不拒绝他的缺陷,因为他们一个月不能超过5条缺陷被拒绝,超过就会扣当月绩效,个人认为这种考核恨不人性,但是如果我不拒绝,我这边的工作量也没有办法体现(我们老大是按照每个人验了多少条缺陷来算工作量),现在他们经常让我发现bug就给他们另提缺陷,感觉这是对大家最好的方法,大家利益都不会受损.但是我觉得这样做,是在为开发人员逃避考核,而且对公司规范化也不利(虽然我拒绝的公司的这种考核很不合理,因为他们一个月至少要修改四五十条缺陷,拒绝五条以上是肯定的),作为一个测试人员我觉得不够合格

想了很久,都不知道怎么办,想听听各位同仁的意见.小弟先谢过了

luming

缺陷拒绝是什么意思啊，和另提缺陷有什么差别，开发人员为什么希望不能拒绝，可以另提呢。
还有测试人员验缺陷是什么。
为什么觉得lz提的概念都比较诡异呢。

[ 本帖最后由 luming 于 2009-8-6 12:10 编辑 ]

likejuntesting

缺陷拒绝是表示缺陷描述的功能或bug现象没有解决所以要拒绝,
至于和另提缺陷的差别,缺陷拒绝是说明开发人员修改的缺陷还存在问题,如果拒绝多次,说明开发人员的代码质量很有问题,也是对开发人员的一个提醒,可以让他们在提交缺陷之前可以多自测一下;如果另提缺陷是说上一缺陷描述的功能没有完全实现,或是bug现象没有解决还存在一些问题,此时开发人员希望可以通过新提一个缺陷来解决上一缺陷未解决的问题(因为如果开发人员提交的缺陷被多次拒绝,就会进行绩效考核),觉得这样做是让开发逃避考核,不利于公司规范化管理,对开发人员能力的提高也不利,因为这样他们就可以修改缺陷后就可以马上提交,不自测,这样就会加重测试的工资量

luming

说实在话，你的原帖我看的实在不明白，我按照自己的理解来解释一下，lz看是否正确。

原帖引用：
最近我遇到一个问题,和开发人员产生了一点矛盾,事情是这样:
现场需求人员提了一个新增需求(个人认为这个需求的功能点比较简单,就是新增一个字段,但是如果设计测试用例,也会有很多个验证点),花了半天时间验完后（这里的验完，是说按照原有测试用例验证完毕吗？）,发现了不少bug,然后我就将缺陷拒绝（从回复看，缺陷拒绝应该是说缺陷的重复出现或再次出现，这里是新bug吧，应该算另提的啊。）,开发人员对我这种方式有意见,觉得我不应该拒绝,而是应该另提缺陷,因为他觉得需求描述不清楚,个人感觉是他觉得缺陷应该把要验的功能点都一个一个写清楚（这里不是很明白你说的什么，缺陷只是对针对软件有问题的地方，和要验（你说的验是否是测试的意思）的功能点有什么关系？）,他才知道要改什么（开发人员，只针对你提交的缺陷进行修改就可以了吧，为什么他不知道要改什么呢？你的缺陷提交的不明确吗？一个缺陷应该仅仅对应一个具体发现的问题而已啊）,因为这件事情大家弄得都不高兴,我觉得他是为了逃避考核,老是变着方法来让我不拒绝他的缺陷,因为他们一个月不能超过5条缺陷被拒绝,超过就会扣当月绩效,个人认为这种考核恨不人性,但是如果我不拒绝,我这边的工作量也没有办法体现(我们老大是按照每个人验了多少条缺陷来算工作量（这里也很奇怪，为什么用验缺陷来算工作量，一般顶多按照提交的缺陷吧，没有见过验缺陷当工作量的，或者你的意思是验证测试用例而不是验缺陷？）),现在他们经常让我发现bug就给他们另提缺陷（发现新缺陷就提交好了，你的意思应该就是另提，而不是拒绝吧）,感觉这是对大家最好的方法,大家利益都不会受损.但是我觉得这样做,是在为开发人员逃避考核,而且对公司规范化也不利(虽然我拒绝的公司的这种考核很不合理,因为他们一个月至少要修改四五十条缺陷,拒绝五条以上是肯定的),作为一个测试人员我觉得不够合格（为什么不合格，制度不合理，可以和上面的人说，其实最好按比例来，而不是按数量来，这样才能达到公司的本意）

luming

提交缺陷，需要简单、清晰、明了，有的时候，也可以同时提出自己的修改建议，程序员大部分都很懒，你不推是不走的。
还有，一些小问题，我不会和程序员争执，比如拒绝和另提，如果我处理，会大部分的时候按照程序员的要求来，和谐社会要和谐，你好，我好，大家好。  

[ 本帖最后由 luming 于 2009-8-6 13:59 编辑 ]

月上百合

大致上是明白杂回事了，呵呵，不过我觉得你另提bug挺好啊，因为是解决一个老bug而引起的新bug，就算没有逃避考核，也没必要烦脑吧？其实也是，你提的bug他改了，引出的新bug，不能算你描述不清，因为你事称也不知道，所以我觉得应该提出新bug

月上百合

再说一下，我们同事在上线前都光想让我多找到bug呢。说总比上了线发现问题强，到时候又不好看，又费事儿。

likejuntesting

非常感谢luming和月上百合你们的意见,看了你们的回复,我知道该怎么办了,再次感谢

月上百合

呵呵相互学习

yiding_he

原帖由 likejuntesting 于 2009-8-6 11:25 发表
我有一个问题想请教一下各位.希望大家能给我点建议
最近我遇到一个问题,和开发人员产生了一点矛盾,事情是这样:
现场需求人员提了一个新增需求(个人认为这个需求的功能点比较简单,就是新增一个字段,但是如果设计测试 ...

这个考核方式实在太囧了。解决一个问题需要开发人员和测试人员的配合。一旦考核将双方对立起来，效率就会变得极其低下。

按照缺陷的条数来算工作量？根本就是笑话。工作量跟缺陷条数毫无关系，比较合适的方式是用测试用例的数量来算测试工作量。当然，测试疏漏造成产品出现问题，是要惩罚的，我想楼主还是能够接受。