How many testers to developers? – The question that does not solve anything.

How many testers to developers?

I still see the posts on Facebook groups and other websites for testers, that ask “how many testers do we need for every developer?”. What is funny, is the fact that what you usually get are plenty of different answers.

To give you the most unique/distinct ones:

• 1 tester to 2,3,4…8 developers
• 1 tester to 3 back-end developers and 4 front-end developers
• “We don’t have testers”
• 1 QA to 4 developers
• 1 QA to 2,5 developers (maybe the other half of developer is taken care by another tester? Or maybe someone employed half a person? Hmm…)
• 1 Automated tester to developer

And so on, but mostly everything centers around this answers.

Purpose?

What is the purpose of this question? Does anyone ask this question using some statistic to create some “perfect tester/QA etc. to the developer equation”?

Should we also add the managers to this metric, admins, devops or even the stakeholders (just for fun or better results),

or simplify it?

Does it make any difference?

Another pointless metric

I have a problem with this question because, in my opinion, it is just another example of a pointless metric (alongside with a number of test cases, bugs found, pass rate etc.).

We want to compare the ratio of testers/developers in companies without looking at a bigger picture of each company/project and understanding why they have this kind of team structure.

What about:

• Level of experience of testers and developers
• Development process, they are using
• Project scope
• Team type (on-site, distributed)
• Communication in team
• Tools used

The reason?

Why even bother with searching for an answer to this question?

The answer is simple IMHO, we as testers/QA/etc. want the best quality, and some of us think that more testers are the solution to the problem. Moreover, we want to show in our company that other companies (on this metric alone) have more testers to developers than we do, so we should hire more (“for the greater good”).

But what if I tell you (and your managers) that there is another solution?

Maybe the problem is not a testers/developers ratio, but the whole development process. So, we should focus our concerns on this area.

I don’t believe that more testers equal better quality. I believe that bad development process equals worse quality and more testers would not improve it. We need a whole dev team concerning about quality because the quality is everybody’s concern, not the testers only.

And I am willing to say that 1 tester/QA or whatever what you want to call that person in charge of testing could be enough for the whole development team if two things are to be changed. The process itself and development culture.

A different point of view

It could be easy (in theory) to have one one-man army QA or Omega tester in the project. But it demands that every person in the team would be on board with process changes.

And what are these changes, you ask?

First of all and the most important thing is to acknowledge the following:

Deal with your development and testing process and don’t follow the pointless metric like “How many testers to developers”

We got that checked. Great.

So what’s next?

Sit down with your managers and other leadership roles and discuss the definition of done, so it would include the testing process in it. Not just a testing process at the end of development, but the one that lives in symbiosis with the development process. Because why to have the development process for developers and the testing process for testers only. When you could have one development process with testing in it.

Make the testing not locked up only for testers/QA, let’s leave our silos and share testing knowledge to other team members. Let’s give our developers knowledge and ways to test the feature they are developing (or at least check the software before giving it to the testing team).

Give them the necessary information about what impact do their changes have on the rest of the platform.

Work with your dev team, show them how to test properly, what to take into consideration and also evaluate their work. Check the automated test cases (if you have the skill to do it) and information about the new feature (what have changed, how did they test it etc.). Do some test pairing to find new bugs faster. Show them proper testing techniques, ways to find the boundary values or even your concerns about releasing this new feature. Work with them and also show the experience and the value you are giving to the team.

No tester to developer ratio is needed. Just the process flows.

Have fun.