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

Question

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

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

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

• 开发人员何时提交更改？
• 何时审核更改并将其合并到发布分支？
• 正式候选版本何时创建？

您使用什么过程或错误跟踪软件的功能来跟踪此问题？

您有什么提示/建议/建议可以分享吗？

Answer 1

如果您有幸拥有一个捕捉错误的单元测试，或者如果您能够添加一个专门针对错误进行测试的新测试，那么它提供了一个良好且客观的解决方案度量。

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

根据您的文化，您可能只想将一个错误标记为真正解决，前提是它在所有分支中都通过了自动构建。

另一个好处是，如果它在未来再次出现，例如由于某人恢复某些东西或合并灾难，您可以捕获它。