Are bugs the only metric on which to evaluate a tester?

What then can serve as the true performance indicators for a tester? Should we rely solely on the number of bugs reported, or is there more to it?

Do you evaluate your testers through collaborative skills, test coverage, critical thinking, or risk awareness?

Would love to hear your thoughts, and how your teams approach this!

1 Like

15 years ago, the number of “valid” bugs reported was used as a KPI for testers at a company I worked at.

Suffice to say it was a complete disaster.

  • The testers created bugs for absolutely everything so JIRA was flooded with irrelevant “bugs”
  • The testers contested every bug that was closed as a duplicate, claiming that their bug was the original bug, which took up the developers’ time
  • The testers started discussions for every bug that was closed as “invalid” creating even more costs

What you measure is what you get. What a company wants everyone to do is contribute value - you need to figure out what that means in your context for testers.

What value a tester contributes to a team is much more complex than the number of bugs reported.

7 Likes

Take a step back and consider why you want to measure their performance.

On the face of it is seems an obvious thing to do but its not, do you measure a family member or a friends performance, there are differences there but the consideration will allow you to question why you want to measure their performance.

What are the goals and value you want to see by measuring them, what results do you want to achieve, what are you going to do once you get those measures?

Here are a few I have seen.

A command and control activity in a hierarchical environment where trust is not in place so this gives management a false sense of influence and control.

Salary reviews are coming up and you have a budget and you need to justify its allocation. Its a costly superficial way to reward some people, punish others and just enough to tell people to are doing sort of okay but could do better.

Part of a joint ongoing development plan, ask individuals the keys skills they can improve on, find a measure of where they are now, put in place an action plan to support their development and then use the measure to try and gauge progress of your actions. This one I have seen being useful.

Quantitative measures are abstract at best, at worst they are gamed and result in worse behaviours of something else to achieve that goal. They are easy to make up though.

Qualitative ones tend to be better but involve many others in getting feedback and judgement and are rarely one size fits all. Team members over time tend to pick up naturally who is doing well and who could do with some help. This can also help pick up on those that may be struggling with life things that they could benefit from support on.

Testers also have some deliverables often around communication, these can be reviewed and improved on over time.

Trust is often at the root of managers wanting to measure individuals, did they not hire the right person for the job, were they not qualified so lets keep measuring them.

Measuring at team level tends to make more sense than individuals when its about product improvement.

Measuring without an support for improvement plan is futile, people just dont improve due to measuring them, it takes actions to change.

So go back and define your goals.

4 Likes

To explore these issues further, I would recommend reading The Leader’s Handbook by Peter Scholtes
. It is a guide to inspiring people. and has a useful chapter on performance without appraisal

3 Likes