关于缺陷管理的几个状态

上一篇 / 下一篇 2007-10-18 16:47:35 / 个人分类：技术交流

个人觉得，采用TD管理缺陷，确实为不错的方法。但是TD中缺陷的状态还是不够，若增加FIXING和RENEW两个状态，那就不错了。

NEW ：被首次发现的缺陷；

RENEW ：对于被拒绝的缺陷或者已修复的缺陷进行验证后确定仍然为缺陷的缺陷；

OPEN ：对于NEW状态的缺陷，分析后发布并已安排等待修复的缺陷；

REOPEN : 对于RENEW状态的缺陷，分析后发布并已安排等待修复的缺陷；

REJECTED ：经分析后拒绝的缺陷；

FIXING ：正在修复中的缺陷；

FIXED ：已修复等待验证的缺陷；

CLOSED ：已被关闭，该缺陷验证已修复的缺陷或者经识别后同意否决的缺陷。

状态流转如下：

修复软件缺陷的成本 (51testing, 2007-9-06)
解决IE关闭页面时连续弹出新窗口的bug (51testing, 2007-9-11)
BUG 参考标准 (51testing, 2007-9-12)
软件缺陷跟踪管理 (51testing, 2007-9-21)
缺陷报告管理系统 (51testing, 2007-9-25)
(一)软件错误跟踪系统模型研究 (51testing, 2007-9-27)
(二)软件错误跟踪系统模型研究 (51testing, 2007-9-27)
BUG，规范，断言和调试 (51testing, 2007-9-28)
bug在quality center中的生命周期 (51testing, 2007-10-09)
微软的代码调试准则 (51testing, 2007-10-11)

引用删除 qiguojie / 2007-10-19 16:16:04: 个人认为使用TD等类似的缺陷管理跟踪工具时，具体的状态主要是代表这个缺陷是该由谁来操作，一般在实际进行操作的过程中，不管是什么角色，都是要看缺陷的处理历史记录和相关注释，呵呵。

还有，国内的大部分公司的缺陷跟踪和处理都是简化了很多的，较为规范的相对较少，汗~

引用删除 typhoon / 2007-10-19 15:17:10: qiguojie 发布于2007-10-19 11:34:27
个人认为RENEW状态完全可以去掉，可能跟不同的流程简化有不同的做法，但是个人认为这个过程只是增加流程的烦琐度，而实际意义比较小。
另外，你这个状态中缺少滞留状态的缺陷状态，例如要遗留到下一个版本解决的bug怎么走状态呢？

答复：
renew状态的增加，使得管理更加严谨。
试想，对应缺陷的管理可分三个角色“分析员”、“修复员”、“验证员”。如果没有“renew”，那么验证员验证缺陷后认为再为缺陷时，直接为“reopen”是不对的，应该经过分析员再次分析后才能判定是否继续发布缺陷。这种情况管理测试缺陷时比较少，但是管理“评审”或者“确认”发现的缺陷时就比较多。这样规范缺陷状态，就是为了统一管理项目的缺陷

对于滞留到下个版本解决的缺陷，我们是增加“计划解决的版本”字段，这样就不需要增加这个滞留状态了。

引用删除 qiguojie / 2007-10-19 11:34:27: 个人认为RENEW状态完全可以去掉，可能跟不同的流程简化有不同的做法，但是个人认为这个过程只是增加流程的烦琐度，而实际意义比较小。

另外，你这个状态中缺少滞留状态的缺陷状态，例如要遗留到下一个版本解决的bug怎么走状态呢？