简易缺陷处理流程

前言

缺陷的处理是测试人员最重要的工作，测试人员最终的价值可以说都是通过缺陷来体现的。在项目中如果没提一个bug，那么对于项目的质量实际上没起作用。虽然辛辛苦苦做测试分析、写测试用例、执行测试，忙活了一个多月，测试报告写得很漂亮，项目的质量也很好，但只是让相关人员对项目的质量充满信心而已，基本上没产生实际的价值。

既然bug对测试人员来说如此重要，所以首先要知道bug在一个公司的是如何流转。今天我们就来说一下缺陷的处理流程。此篇为什么说缺陷处理简易流程呢？因为这个是涉及相关角色最少、流程最简单的缺陷处理流程。流程虽然简易，但却是最高效的处理流程。我在证通工作的时候用的就是这个流程，缺陷处理非常高效，测试提了缺陷立刻就到了对应开发手上，中间没有任何多余的环节，测试和开发之间也很少有因为缺陷而产生的冲突。这个流程的前提是公司不以缺陷的数量来衡量大家的工作，大家的目的都是努力把项目质量做好。

缺陷处理流程图

 

流程说明

1. 测试人员发现缺陷后，在缺陷系统中记录一个缺陷，并按要求填好缺陷的各要素（缺陷的基本要素我们在下一篇说明）
2. 测试人员了解缺陷对应开发人员后，将缺陷状态改成打开，然后指派给对应的开发人员。
3. 开发人员收到缺陷后，判断缺陷是否为有效缺陷。
4. 开发人员判断缺陷为无效缺陷后，将缺陷拒绝，流程结束。在拒绝的时候需要跟对应的测试人员沟通，确认确实是无效缺陷。
5. 开发人员判断缺陷是有效缺陷，则对缺陷进行修改，修改完成并自测通过，提交新的测试版本后，将缺陷状态修改为已修改。此时一般会要求填写修改后的版本号、记录缺陷产生的原因和修改的可能影响。
6. 测试人员对修改的缺陷进行验证，验证通过后关闭缺陷，缺陷处理流程结束。如果验证失败，则将缺陷重新打开，缺陷重新流转到开发人员手上，再次进行修改。
7. 项目经理会在项目快结束时组织对本次不修改的缺陷进行评审，评审要求相关的测试、开发都参与。由于时间有限，不修改也没什么影响，或者修改会导致产生其他的大的影响，则本次不做修改，在后续版本中修改，此时就将缺陷状态改成延迟，在后续版本中再进行修改。

特殊说明

无效缺陷在测试过程中是不可避免的，但无效缺陷多了会产生非常不好的影响。一方面浪费大家的时间，另外也会影响自己在团队的可信度，给别人以此人提的缺陷十有八九是无效缺陷的印象。如果在开发中产生这样的印象，以后再提缺陷开发第一时间就怀疑你可能又搞错了，不会首先自己去定位，而会要求你复现，然后他们才会投入定位或修改，极大地影响测试的效率。

所以提缺陷时可以做如下动作

1. 跟其他测试人员确认，此现象是否为缺陷，一方面可以在测试团队内先确认是否是缺陷，另外也可以避免提重复的缺陷；
2. 跟对应的开发先确认，确认是有效缺陷后再录入系统。