【测试感悟】如何处理有争议的缺陷报告

如何处理有争议的缺陷报告？

李守亮 2008-9-9

 

工作中，测试人员有时会遇到类似的问题：提交了一份软件缺陷报告，可由于某种原因，无论是开发人员还是开发经理就是不愿修改程序。应如何处理这类问题呢？我认为，当对报告出现分歧意见后，测试工程师应首先做如下第一、二步分析：

 

一、问题确认与评估

再次论证该问题确实是程序缺陷，并评估该缺陷的重要程度并对其分类。比如可存在以下分类：

1、设计文档范围内的功能性缺陷

2、影响到程序的安全性和稳定性缺陷

3、界面缺陷

4、一般性错误（如未考虑边界检查等）

5、边缘死角，规律不明显，不太容易重现的错误

6、兼容性错误（例如旧机型、CPU\MEM，旧标准等等）

7、安全性或易用性等的修改建议

……（可扩展）

 

二、明确Dev不修改该缺陷的确切原因

比如可存在以下原因：

1、规律不明显，不好重现

2、dev认为是不影响主要功能的一般性bug，因时间处于版本的稳定期，担心牵一发动全身引起更多错误

3、调用了第三方组件或库函，是第三方程序存在的缺陷

4、存在技术难点

5、设计本身存在问题，程序逻辑是正确的，但实现结果并非用户所需（换言之，dev说这是设计问题，不是程序问题）

6、Dev的个人主观意见：

  ·该瑕疵可以容忍，没必要修改

  ·修改该瑕疵会引起更大的问题

 

7、Tester和dev对错误的理解有分歧：

  ·tester理解错误，该问题并不是bug

  ·tester没有说服dev这是个bug

……（可扩展）

 

三、具体问题具体分析

分析完第一、二步之后，也就基本上明确了问题的争议焦点，然后具体问题具体分析。

1、如果dev认为不好重现，则tester有责任和义务找到更简洁有效的重现规律。

2、如果tester没有说服dev认识到这是个缺陷，则需要拿出强有力的证据（测试用例、设计文档、错误现象等）来证明。

3、对于第三方库函bug，或技术难点导致的bug，则坚持原则——宁缺勿滥，必要时宁可封掉该功能。

4、针对错误的设计、不能说服的dev主观理解、改动隐患，以及稳定期等特殊情况，则可通过TM进行多方沟通。

 

四、发挥TM与PM的沟通职责

强调沟通。

TM和PM有团队沟通的职责。在bug分类、指派和反馈过程中出现有争议的问题时，TM和PM有责任和义务进行干预。根据问题的重要程度和轻重缓急，采取不同的方式进行沟通。如出现“三”中3、4类较大争议的问题，可通过会议研讨等形式召集多方进行论证，并达成一致的解决意见，解决方法形成备忘录。

     对因各种原因继续保留在发布版本中的bug，尤其可能影响功能的，应予以说明，提醒用户绕过。