零错误反弹

零错误反弹是指在项目中的某一点上，开发活动最终赶上了测试的步伐，当前已经不存在活跃错误，如图11-4所示。在零错误反弹之后，错误数量的峰值将显著减小，并且错误数量会持续减少直到产品足够稳定，进而构建出第一个候选发布版。取得零错误反弹是项目组逐渐接近稳定的候选发布版的明确标志。注意，在到达这一里程碑之后，必定还会发现新的错误。但是，它却标志着项目组能够第一次诚实地报告已经不存在活跃错误了，虽然这只是针对当前情况。而且它可以让项目组集中力量保持在这一点上。

事实上，正是通过Bug bash的方式，来达到ZBB的效果。Bug bash（Bug大扫除）来源于微软，通常发生在项目开发各阶段（微软叫里程碑）的末期，比如Beta版发布前，划出一个专门的时间段（通常1～3天），在这期间所有参与项目的人员，集中全部精力，运用各方面的知识，尽全部智慧来搜寻项目的Bug。

这是一个非常有意思的活动，但要组织好这样的活动并非易事。一般有以下要点：

（1）尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益。

（2）要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug。

（3）为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。

（4）可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等。

  

Zero Bug Bounce

The point in time after code complete when the project has no active bugs that require a fix or a resolution. This signals a point where development has caught up with testing and any long-standing issues in the code are resolved. Inevitably, more bugs will be found after meeting this criteria (commonly referred to as "the bounce"), but assuming a consistent bar is maintained for existing and incoming bugs, the incoming or resolve rate and remaining bugs are more reliably predictive of the end of the project. At this point, future release candidates and release dates in the product schedule can be more accurately predicted.