bug数量问题研究

最近感觉很扯蛋的事情就是测试人员提bug的问题.先说下前提,公司测试会以提bug数量来做为一部分员工绩效的成份.再说一下公司从需求到开发

到测试,先是需求出一个文档,开发根据文档做功能的开发,然后测试看文档做黑合测试,文档里面没有用例,所以测试对文档用自己的理解来测试.

----------------割了公司老总的JJ---------------

下面就是我要吐槽的东西了,需求说做一个A,开发做了个A',A与A'有一点偏差,然后测试理解的是A'',A与A''也有偏差.我去,我不是想说这个偏差

的问题 ,我是想说bug数量的问题,就这两个小小的偏差导致bug数量偏差大约1.5倍.

先看一下需求与开发之间的情况如图一, 需求的想法是黑圈里的,开发是做的红,圈里的东西,两个相差一点.理论开发只是a与c部分出了差错,分别

按1个单位计算,也就是测试应该提开发2个单位的bug.

再看下图二,就是把测试加入进来,测试是蓝色的圈里的.测试首先会提 d,a1,b,c这几个地方的bug.因为这几个地方是她们认开发与自己看到的文

档里不同的东西.也就是提了2个单位的bug了.后面通过测试与需求的沟通,她们的理解会向需求方向靠近,最后重合,所以她们再提a,c1,a是之前开

发没有做到的,c1,是开发和测试都理解错了的,所以也要做调整.所以最后是6个部分的bug.也就是bug数量比以前多了1.5倍.(按bug提成的小伙伴真

欢乐)

这种方法牛b吧.也相当于给按bug数量提成的小伙伴们一点经验吧.我勒个去.

所以难得糊涂,湖涂有时也是有好处的.