Something to keep in mind:
“Not everything that counts can be counted”. (William Bruce Cameron, 1963, Informal Sociology, a casual introduction to sociological thinking).
Realistically Meaningful Information for Reports
- Number of test cases
- Number of passed test cases
- Number of failed test cases
- Number of blocked test cases
- Number of identified bugs
- Number of accepted bugs
- Number of rejected bugs
- Number of deferred bugs
- Number of critical bugs
- Number of estimated test hours
- Number of actual test hours
- Number of bugs detected after release
How this could possibly look and be broken out:
Test Coverage
- Requirements
- Functionality
- Test cases
Test Status
- Testing
- Bug resolution
- Readiness for deployment
- Pass/Fail
Progress
- Based on test goals and objectives
- Blockages
Defects
- Categories
- Trends
- Detection Percentage
- Resolution Status
Test Completion Percentage
- Completion %
- Automation %
Resources
- Time expended in QA/test tasks
- People needed for QA/test tasks
This template could be edited as need be per project. These aren’t metrics that need to be gathered for every type of testing, or we may not need all the information every time we test. But generally speaking, any combination of these types of reports and metrics should give insight into trends QA is seeing and expose vulnerabilities.
Another note is that reports will look different depending on the project as some things may not apply.
The types of reports run, and metrics gathered can be paired down as we realize information is meaningful and what’s not needed.
