Bug Counts vs. Test Coverage

1. nothing to worry about.
2. Communicate with management. When bug counts are low, use test coverage to justify them. This doesn't mean dismissing the fact that the bug count is low. It means using the bug count as an indicator to do some analysis into the testing practices you are doing, and verifying that high test coverage is being achieved. If it is, explain to management your findings. Demonstrate by solid metrics that you are performing thorough testing, that you can't force bug counts to go up, and that maybe-just maybe-a low bug count means you've got a quality product on your hands!

One thing to bear in mind: while you can use the above methods during testing cycles to understand and cope with a low bug count, the ideas are still applicable before testing even begins, while test cases are being written for a project, and while development is still in full swing. Good test coverage is something to be planned ahead of time, and having gone through the effort of mapping coverage and functional test cases early in the project, you will prevent yourself from spending valuable testing cycles repeating tasks.

While low bug counts can cause people in both development and management to question the effectiveness of the testing, do not be defensive about it. Use it as a trigger to prove what you should already know-your testing efforts are appropriate, effective, and your coverage is maximized. Don't let your bug counts do the talking-your test coverage should say it all.