TL;DR
Successful leaders measure project outcomes rather than individual productivity. Measuring individual productivity is generally an anti-pattern that obfuscates deeper structural problems.
Do you have too many bugs? Turn your teams loose on reducing the amount of bugs released into production. Are bugs taking too long to fix? Get your developers and testers involved in improving code coverage and diagnostic value of your test suites. Think your developers or testers are "lazy?" Make sure it's not the process that's broken, or unrealistic expectations from outside the team at fault; then hold management accountable for hiring inexperienced or ineffective people, or lacking the leadership to redirect or kill a failing project.
Metrics are useful for process improvement. They are rarely accurate measures of individual productivity, and are often poor proxies for determining accountability. In that regard, your mileage will not vary.
Analysis & Advice
Metrics can be helpful, but in knowledge work (and especially in software development) measuring the right things is NP-hard. It often grows from a desire to measure by proxy, and is therefore always a leaky abstraction that can inherently be gamed.
Especially when evaluating "bugs," you can't accurately measure in a non-complex way. You can't simply measure number of tickets closed or lines of code touched for a patch. For example, measuring the complexity of a reported bug, time needed to isolate or replicate the bug, and determining the cyclomatic impact of the bug and/or patch on the rest of the code base are a priori data points needed to perform any sort of apples-to-apples comparison. While there are people who study this sort of problem, the pragmatic view of those in the industry is that the juice is almost never worth the squeeze.
Imagine a bug that takes two weeks to track down, but only one character of code to fix. Is that developer more or less "productive" than one who fixes a bug that takes only two hours to fix by removing a dozen custom classes and replacing it with an off-the-shelf component? If you can't answer that question is terms of anything other than time, then you've failed to fully capture the complexity of the abstractions here.
The only pragmatic approach to determining individual developer productivity is to ask the other developers on the team to evaluate one another. Experienced, self-organizing teams will generally know how hard the bugs are, why certain classes of bugs crop up routinely, and whether each team member is contributing as effectively as possible within the limitations of the current process.
Be aware that asking teams to measure individual performance, rather than simply measuring team output, invites process and structural problems that can be very hard to fix. That isn't to say that some people aren't more efficient or effective than others, but unless a person's performance is disrupting the team or process, then looking at individual performance is usually a sign of Theory X management. Measuring individual rather than team productivity will generally encourage CYA behaviors rather than teaming or continuous process improvement.
