关于bug生命周期和发布管理的建议

时间:2010-04-21 01:14:37

标签: release-management

我们小组目前正在分析管理正式软件版本和与bug lifecycle集成的程序。

您使用什么错误生命周期模型?为什么?

例如,假设每周为QA生成一次正式版本。您在什么时候将错误标记为已解决?

  • 当开发者提交更改时?
  • 何时审核并合并到发布分支?
  • 何时创建正式候选版本?

您使用跟踪软件跟踪软件的过程或功能是什么?

您可以分享任何提示/建议/建议吗?

1 个答案:

答案 0 :(得分:1)

如果您足够幸运能够获得能够捕获错误的单元测试,或者如果您能够添加专门测试该错误的新测试,则可以提供良好且客观的分辨率测量。

如果使用回归测试进行连续构建,那么只要相应的测试在主分支上传递,就可以认为该错误已得到解决。这样做的好处是,它可以很容易地考虑在一个分支上解决但在另一个分支上无法解决的错误,从而使您尽早尝试集成并测量成功。

根据您的文化,如果在所有分支中传递自动构建,您可能只希望将错误标记为真正已解决。

另一个优点是,如果将来再次出现该错误,您可以捕获该错误,例如由于有人还原某些东西或合并灾难。