当测试与开发存在分歧时
相信很多测试人员在工作中，都遇到过这样的情况：
1、对需求的理解，开发与测试有分歧；由于沟通不够，导致在测试过程中产生分歧。
2、开发人员和测试人员对bug的定义不一致。
3、由于某种原因，开发人员对bug过于敏感，导致沟通不畅。
当遇到这些情况时，大家是怎么处理的呢？
欢迎大家都来说说自己的想法。
金鑫 2010-08-07
1、对需求的理解存在差异，太正常不过了，不要说测试与开发，就是开发人员之间也不可避免。这种情况下建立良好的沟通机制，比如需求确认、BUG评审之类的活动等
2、缺陷的定义存在理解上的偏差。作为QA人员有责任定义清晰并形成规范化的缺陷定义文档，再经过几方确认评审后，对bug的范畴、处理流程、等级之类的定义无二义性以后，再执行，效果会更好
3、其实和第2点类似，所谓开发对某些bug敏感，原因还是对bug的如何界定与理解，与测试人员理解不一致造成的
李超 2010-08-08
1.需求评审。2.找BSD。3.还是找BSD
刘俊 2010-08-09
1. 需求存在分歧，需要通过沟通来达成一致。如果是需求描述存在歧义，可以直接找PM。
2. 由于出发点不同，所以看待bug的角度自然是不同的，但是我们需要把我们的角度解释给开发听，这个比较考验沟通能力了，万一遇到比较执拗的开发，会比较麻烦。
3. 开发对bug过敏主要看心态，不过公司往往会对开发和测试双方施加压力，比如开发bug很多要扣钱，测试没有发现低级bug要扣钱等等，这样往往会导致大家针锋相对。最理想的状态是开发和测试共同努力把事情做到perfect，但是大家心里往往是这样想的：赚到钱是公司的，做的好不好关我屁事。 so。。。。
雷雨 2010-08-09
还好我们这边BUG顶多会影响绩效的分数 奖金会有浮动~ 开发态度还算OK~
吴丽华 2010-08-09
金鑫: 1、对需求的理解存在差异，太正常不过了，不要说测试与开发，就是开发人员之间也不可避免。这种情况下建立良好的沟通机制，比如需求确认、BUG评审之类的活动等
2、缺陷的
嗯，很有道理~2、缺陷的
谢谢~
吴丽华 2010-08-09
李超: 1.需求评审。2.找BSD。3.还是找BSD
我们这边的需求评审，暂时还没有细化到设计~ 而且，我觉得，即使细化到具体的设计了，到测试阶段，还是有可能存在一些小细节的分歧的。不知你们的需求评审，是以什么形式开展的？
吴丽华 2010-08-09
刘俊: 1. 需求存在分歧，需要通过沟通来达成一致。如果是需求描述存在歧义，可以直接找PM。
2. 由于出发点不同，所以看待bug的角度自然是不同的，但是我们需要把我们的角度解释
嗯，同意你的意见~在工作中，难免会遇到比较麻烦的开发~
2. 由于出发点不同，所以看待bug的角度自然是不同的，但是我们需要把我们的角度解释
李超 2010-08-09
吴丽华: 我们这边的需求评审，暂时还没有细化到设计~ 而且，我觉得，即使细化到具体的设计了，到测试阶段，还是有可能存在一些小细节的分歧的。
不知你们的需求评审，是以什么形式开
第一轮，PM给开发和测试讲大概的需求，第二轮，DM给开发讲具体需求与实现，第三轮，DM给测试讲需求点，第四轮，测试给DM及其它测试人员讲需求与用例评审！！！差不多就这样！！！
不知你们的需求评审，是以什么形式开
吴丽华 2010-08-10
李超: 第一轮，PM给开发和测试讲大概的需求，第二轮，DM给开发讲具体需求与实现，第三轮，DM给测试讲需求点，第四轮，测试给DM及其它测试人员讲需求与用例评审！！！差不多就这样！！！
这四轮，都属于需求评审？还是已经包括开发的UC评审、测试的TC评审呢？第四轮，开发不需要参与，是吗？如果是这样的话，能保证开发与测试对需求的理解是一致的吗？
李超 2010-08-10
吴丽华: 这四轮，都属于需求评审？还是已经包括开发的UC评审、测试的TC评审呢？
第四轮，开发不需要参与，是吗？如果是这样的话，能保证开发与测试对需求的理解是一致的吗？
第四轮只能说有一半算是需求评审，只不过与用例评审一起进行而已，开发的话也会参加的，不过只有DM，每轮评审都会提出若干问题并记录，如果DM能解答就当时解答，如果不能就由DM与开发讨论后通过邮件方式回复。第四轮，开发不需要参与，是吗？如果是这样的话，能保证开发与测试对需求的理解是一致的吗？
每一次评审我们都会预测该阶段我们应该发现多少问题，定立一个目标值，而真正评审的时候会试着去实现这个目标，而这个目标的定立也依赖于历史数据，有时CMMI还是有点用处...
吴丽华 2010-08-11
李超: 第四轮只能说有一半算是需求评审，只不过与用例评审一起进行而已，开发的话也会参加的，不过只有DM，每轮评审都会提出若干问题并记录，如果DM能解答就当时解答，如果不能就由
嗯，谢谢~
请 登录 后发表评论
