缺陷管理之说—“预处理日期”属性是否应该填写

   测试人员在缺陷管理工具新增缺陷报告后，开发人员修复缺陷时会被要求填写一个属性字段“预处理版本”，这个字段的含义是告诉测试人员缺陷即将被修复的软件版本，便于测试人员在相应的版本提交后验证缺陷是否修复。但有的开发人员提出疑问：此字段是否必须填写？版本提交前将缺陷状态标为fixed后，测试人员只需过滤出状态=fixed的缺陷就可以做验证了。这个不是没有道理，但从测试管理的角度来说，填写预处理版本是规范化的体现，这样做的必要性在于：

1、测试人员在缺陷管理工具里对状态标记为fixed的缺陷进行回归测试时，开发人员同时处理状态标记为oepn的缺陷，一旦完成修复的也会标记为fixed。但测试人员在现行版本不可能对开发人员刚刚标记为fixed状的缺陷进行回归测试。那这两类状态一样的缺陷如何区分开？只有通过预处理版本号来区分，后一类fixed状的缺陷会在后续版本提交。如果不做区分，测试人员去核对那些还未提交修复的缺陷，发现未修复就会将状态标记反复，打回给开发人员，如此误会太令人啼笑皆非。

2、利用缺陷管理工具进行度量时可充当过滤条件。比如统计某个版本有多少个缺陷不是一次性修复的，即缺陷反复率时，就可以设置过滤条件为：预先处理版本=XX & 实际修复版本<>XX，将过滤出的缺陷数/处理缺陷的总数就等于缺陷反复率。

但现实中会有一些开发团队采用较为特殊的缺陷处理方式，比如测试人员在缺陷管理工具提交了缺陷报告，而后项目经理标记出需要处理的缺陷，开发人员修复后提交新版本程序，并在提交说明文档里把需要验证的缺陷一一列举出来。此提交说明文档里更多的是用户反馈缺陷（来自用户反馈表），测试人员按此文档标明的BUG ID号和用户反馈缺陷来进行回归测试，而非在缺陷管理工具中先过滤出所有状态=fixed的缺陷再验证。

追溯导致这种做法的原因，就是软件在发布到用户现场之前遗漏了大量的缺陷未被发现或是未修改，所以用户在使用后会反馈大量意见，而如果把这些缺陷也输入到缺陷管理工具中是极其耗时的事（开发团队未设专门的实施人员，由开发人员身兼二职），一般用户反馈BUG会记在另外定制的表格里。提交修复时与缺陷管理工具里登记的一起写入提交说明文档。

而这样说法导致的现象又有哪些呢？经一段时间实践发现：
1、开发人员与测试人员无法在缺陷管理工具中实现交互。缺陷验证后开发人员只在提交说明文档里看验证结果，等于说这个提交说明文档已替代了缺陷管理工具成为交互平台。开发人员撰写提交说明文档会耗费更多时间，因为他们要把缺陷管理工具里的BUG ID号记录下来。
2、极有可能发生漏验。开发人员在撰写提交说明文档时有可能会漏写已修复的BUG，而由于测试人员只会验证文档里提到BUG，所以没写上但实际又修复的BUG是不会得到验证。

这样的缺陷管理流程在很大程度上脱离了工具，是一种耗时且不利于做缺陷度量统计的做法，同时也是软件在发布前未得到充分测试所导致的后果。