公司规定，所有的软件release前必须达到90%的bug修改率。也就是说，用户、测试人员、开发人员在平时、Alpha测试、Beta测试期间发现的bug至少90%的已经改正，软件才能发布。如果软件是升级版本，那么还需要包括commercial版本上的那些bug。
今天开会，一个测试经理介绍了一个项目对此的处理办法：项目经理经常关注bug的总数，一旦数量有上涨，他会立刻查看这些新发现bug的内容，并将它们分派的各个开发人员头上。这样，他们项目的bug修改率总是维持在一个较高的水平，在release之前也不会急匆匆的去处理这些bug。不知道他们是怎么做到、并且坚持做到控制住bug总数的，因为开发过程中开发人员时间是比较紧张的，总会有很多新功能等着去实现，不可能会有大量时间来处理那些随时发生的bug。但是他们做到了，bug一旦发现、尽量及时调查原因、及时修补改正，并且在整个开发过程中坚持这个做法。
而很多项目的做法是，开发人员大部分时间都是关注开发新功能，等bug积累到一定数量、或者在Beta测试、发布之前集中一段时间修改bug。寄希望于这一次性的努力把bug修改率提高到一定水平。但是没有一蹴而就，过段时间，bug又会多起来。这时候，我们应该考虑一蹴二保持，通过一蹴达到高水平后再保持这个高水平。
听起来挺像敏捷开发中的增量式开发，在软件质量达到一定标准之前不进行新功能的开发，应该确保每个功能完成后软件质量都达到一定水平，达到可以commercial的水平。这样软件可以随时发布，而不需要通过发布前的那一蹴达到发布标准。