The problem with any form of hard metric in a field like software QA is that - to use the answer I give so often here - it depends. Each hard data point is really only helpful in the context of the development project it links to, and even then there are variations.
I'd suggest you take a look at the answers to the question user867 suggested as a possible duplicate, including my answer.
Deliverables should, in my view, consist of information about the system, as Dale Emery said. If you have use cases or user stories, some things you would consider for each project are:
- link use cases/user stories to test cases covering them and report their status
- list which test cases are automated and why those cases were automated (in general the scenarios that are most likely to get the heaviest use are the best candidates for automation)
- the state of overall product regression if you have it (this is particularly important when you're dealing with development against an existing product)
- areas that weren't tested, the reasons these were not tested, and the potential risks exposed. It's very rare that everything can be tested, so there's always going to be a need for testing triage.
Where there are no use cases/user stories (which is far from ideal, but certainly happens), you'd want to look for these items:
- a breakdown of the product or project by functional area is essential because without use cases/user stories the specification is by default the working software.
- test cases linked to the functional areas of the product/project.
- items 2, 3, and 4 from the use case list above.
If you can data-mine the issue tracking database, some areas to consider are:
- Issues found by testers and issues found by customers. This should not be a straight ratio metric: instead look for clusters of functionality in customer issues and whether your testers have noted that area as a problem region but have not (usually due to time constraints) been able to build in regression around that area.
- Issues reported by testers and not corrected, then later reported by customers - here you want to look at why the issue wasn't corrected (in my experience it's usually a case of "nobody would do that" - and inevitably someone does).
- How many of the customer-reported issues are core problems and how many are edge cases. If your test team is doing well, you should find that most of the customer-reported issues are edge cases with respect to your entire customer base or to the actions that are problematic (this doesn't make the issue less problematic to the customer - the goal here is to look at whether you would reasonably expect your testers to have found the problem before release. With a good test team and a reasonably mature automation effort, the answer will usually be "no").
Some other things to consider are the nature of the information the testers generate: do they routinely provide information on complex configuration that later becomes the core of the documentation team's work? Do they provide a list of "gotchas" or caveats about the software, such as whether a particular feature should be used in conjunction with other features, or required settings? Do they warn of fragile software that works only if everything is exactly right? Do they try to ensure that the software guides the users to the correct/preferred actions?
It's worth remembering that software development is an odd mix of science and art, and testing is possibly even more so. The science part can be quantified, but the art aspect can't, and like art every software development project is different.
