Just a short piece on a metapher I like to use, when someone tries to explain me how important bug metrics are.
“Bugs are like a piece of fruit!” But, every bug is a different piece of fruit, of different size, different degree of ripeness, and different amount of calories. Now give that fruit to a developer. How many fruits can a developer eat (fix bugs), before he is stuffed (end of the day). Do you know how the developer is eating the piece of fruit? Why not take a single grape, wash it, slice it up, remove the seeds, enjoy every bite and clean up afterwards. Or slice a watermelon, and eat a couple of bites of every slice in the same time. Leaving lots of water melon still to eat. Which means, the bug is not fully fixed, maybe to a certain acceptable degree, or not. So back to the slices and have more water melon. If the fruit is not ripe yet (bug not fully described), it needs to ripe some more. What if the developer grabs a bite, finds out he doesn’t like the taste and gives it to some other developer.
So, why do you count melons and apples and grapes with the same numbers and compare them. Or you try to get any additional information out of those numbers.
Without more information on the sort of bug, how long did it take to fix, what was the root cause, did the retest fail – maybe more than once. You just know there was a box full of fruit that development had to eat.
Just my 2 cents, why basic bug metrics are of no good use without additional information or even the story behind them.
Test Pappy 
The QA engineer’s role is not just reporting bugs, but much more, they can team up with developers to make the product much more effective.
That’s true. Never stated anything against that. If you read my other blogs and articles you would see, that this is also my view.