三、开发人员修改缺陷填写规范
1、不论是简单还是复杂的缺陷,开发人员都要在修改了代码并确保代码提交到服务器后,再将缺陷状态由“打开”置为“修复”。
2、对于非常简单明了的缺陷(例如界面上的一个错别字),可以在注释中加简单的注释说明:(如:已修改)但对于复杂的缺陷,必须要注明以下几点:
1)缺陷产生的原因
2)缺陷解决的方法:(该项描述主要是方便以后遇到同类问题的同事,可以查看当时的解决办法,如果该缺陷的修改引发了其他的缺陷产生,则开发人员可以查看一下当 时的修改情况)
3)这个改动引起了哪些变动:(方便测试人员在进行回归测试时,测试的深度和广度的把握)
3、如果缺陷是由于测试人员理解错误导致,或者开发人员认为不需要修改的,开发人员可以将缺陷状态设置为“否决”,但是必须在【注释】栏中填写拒绝修改的原因。
4、如果开发人员认为该缺陷与其他缺陷重复,也需要在【注释】栏中填写与之重复的缺陷ID,例如注释内容可以填写:与缺陷10重复。目的是让开发人员再确认一下这两个缺陷是否真的描述同一个问题。
小提示:在新增注释说明时,可以直接点击页面右下方的(添加注释)按钮,QC可以直接添加你的登录帐号在“注释”中,省去自己填写的麻烦!如图12.请大家在填写时养成加入自己信息的习惯,方便测试人员在回归测试时可以看到是谁回复的,有问题方便直接沟通!
四、项目经理决定延期修改缺陷
1、项目经理决定延迟修改缺陷时,先在注释中写明延迟修改的原因,再将缺陷状态置为“延期”。
2、项目经理需填写如图13中蓝色框圈出的“计划关闭的版本号”和“估计修复时间”两项内容。(计划关闭的版本号可以是正式版本,如Beta_v1.0,也可以是计划在今后的一个候选版本中填写,如Beta_v1.0.RC12)。由于目前版本管理还不完善,该项暂时可以不填写。