The problem I can see with counting defects, is that all defects are not equal. You might move a release deadline when you find a single bug - a showstopper resulting in complete data loss for the customer, but you'd be unlikely to do so for even a few dozen cosmetic bugs.
On the other hand - you can't just discount cosmetic bugs either. What if that cosmetic bug is a misspelling of your company's name, or a typo that renders a sentence unintentionally obscene, bang in the middle of your home page? Suddenly, all cosmetic defects are not equal either.
Equally, you might be "95% done" - but the remaining 5% is a critical business function, and it's been blocked by one bug after another for the last five months, and you're now having to explain to senior management that just because the percentages look great, that doesn't mean the project is in good shape and you really really need more time. You need to factor in not just how many bugs, but where they are, and where you haven't been able to test yet. If most of the app is inaccessible due to a handful of blocking bugs, or this particular project requires tedious and lengthy data setup, you might also have really low defects per tester hour.
If you're going to be basing release (or rather, not-release) decisions on these measures, you need to be very sure that the measures you use genuinely reflect what you want to measure - as we can see, mere defect counts don't do that well.
It's time to trot out my favourite paper: Kaner and Bond's "Software Engineering Metrics: What Do They Measure and How Do We Know?" Reading this, and applying the advice within will help you to evaluate the measures you choose. Poor metrics are extremely dangerous - they will become the rope used to hang you. I've worked on a team that was suffering from years of reporting on a measure that didn't reflect the risk - we got pressured to make the numbers better, even though we knew sometimes that made the testing, and the product, worse. :( It's really tough to argue against an established measure though.
So, what other options are there? Well, Gojko Adzic has listed some useful suggestions. I really like the idea of heat maps - either to measure which files are associated with most defects (it's just occurred to me that we could implement this at work by gathering the information we have on JIRA - we have subversion checkins associated to each issue, so if we can separate the issues that are bugs, we might have some interesting data. No idea how much work that will be though!), or a functional measure to show how much testing you've conducted in an area of the application compared with how much you feel is needed. The attribute-component-capability matrix is also interesting - being able to identify that there are blocking bugs in areas that are key to the business is a compelling argument.
In terms of passing a build back to developers, here are some approaches I've seen:
- Identify key end-to-end paths through the app. Create a carefully selected set of acceptance tests that cover key paths through the app - for an ecommerce site, one test might be that a customer can order and checkout. ALL tests must pass before you start testing. (It can be a small set, if you pick carefully - a small set is much easier to get agreement on.) If you frequently have integration bugs that block large areas of functionality, this is worth using.
- You find X number of bugs of severity Y within the first few days of testing. This one didn't work, I never saw a build returned and it led to endless hours wasted wrangling over just how severe a bug was.
- More than X% of planned test cases blocked. This is one of those that seems objective, but it's actually very subjective - maybe one project has a test lead that writes lots of short simple tests, another one has a test lead who tends to write long complex tests.
I hope some of the ideas above are useful to you. This is an area I find really interesting, but unfortunately, I have a lot more questions than answers. (I think testers should approach software engineering metrics with just as much skepticism as to the systems they test).