BUG就像软件的影子一样，其生命周期和软件的生命周期同步持续进行。产品是想BUG的，研发是写BUG的，测试是找BUG的。在软件开发这场战役中，几乎所有的项目人员都在不停的与BUG做斗争，直到被打败。（在风险管理中，软件产品的风险被认为是不可避免的，只能设置相对完全的应对方案来降低风险度。就是说，BUG是永恒的，就看用户对它的容忍度。）
相对产品和研发，测试应该是防范BUG的最后一道保险。那么，需要解决的问题就是：怎么才能让BUG尽早的最大化暴露在测试过程中？
1.详细的产品需求文档
在开发之前，一定要有一份繁琐到不能再繁琐的详细需求文档。详细到每一个单元可单独量化，可测试。
2.规范的研发文档
研发文档这里指的是项目中编写的代码文档。涉及到《代码编写行为规范》
3.详细的单元测试文档
对应需求文档，会有一份单元测试文档，每个测试单元都对应一个需求单元，有一个独特、可证明的测试方案。完整的单元测试是基于详细的需求文档制定的，回归测试只是重复了一整套的单元测试。
4.规范化的BUG管理软件
这里借用禅道，禅道远远不只是BUG管理，虽然BUG管理只是软件项目管理的一部分，希望还是能用起来。
5.确认BUG到底属于需求还是代码
不是所有的BUG都是代码错误造成的，在需求中的BUG更难被发现。能及时的纠正需求中的BUG，能在时间维度上降低产品的风险。
6.确认BUG的重要程度，分级管理
在BUG被确认后，要对BUG的重要程度进行分级管理，ABC，不能做一揽子计划，保证最紧急的BUG最优先修改。
7.确认负责人
每个BUG对应每个实际的负责人，由该负责人出具BUG解决方案。
8.确认修复时间
在敲定负责人后，由项目负责人与该BUG负责人确认修复时间，到期及时结算。
9.修复后的重复测试和回归测试
总有一天我会有一座面朝大海的房子