[olegious]

As a former QA myself, we never insisted on the bug count being 0, instead we focused on the "critical" bug count being 0 and the "major" bug count being as close to 0 as possible before shipping the product. Often it comes down to a negotiation between QA, dev and product but a good company will give QA a great deal of input in when a product is ready to ship.

[absconditus]

This strategy backfires when managers want the release out so they fight to lower the severity for every defect that is entered. Then they generate a report showing no high severity defects and release the software. Another common problem is a high number of low severity defects that make the software annoying to use.

I am not claiming that a bug count of zero is possible with most software, but testing quality in at the end is the wrong approach. Nothing affects quality as much as the skill level of the developers.

[steve8918]

Agreed. At thing point, any software company with a modicum of experience knows that reaching a 0 bug count is not only impossible, but a waste of money. You get out the new features that you want and make sure it works well, and without causing regressions. Any bugs that inhibit functionality that 80% of the users would use needs to be corrected, as well as any bugs that make us look bad (UI bugs like spelling mistakes, etc).