I’d love to hear from other QA leaders, what your ideal ratio would be? I’ve read 1:2 and 1:3 as ideal. Meaning for ever 2 or 3 devs there’s 1 QA engineer.
I’d also love to hear, would you include your automation team or regression team in these ratios? Or would you consider your testers only working on feature work part of your ratios? I’m really hoping to start a conversation to understand how other leaders are staffing their teams, and what difficulties you’re running into in terms of staffing or bottlenecks.
Some further considerations: Does this mean people with the job titles developer and QA/tester or the number of hours dedicated to development or QA/testing activity? As people with either job title can perform the other activity too.
I think we’re about 1 tester for 3 developers at the moment, but that’s based on job titles only. However developers do testing, testers do tech support and cloud operations, developers and testers also do business analysis and management.
In my team there are 4 devs and me as a tester, but devs test their own code before tickets come to testing, and afterwards the PO reviews the feature as well. Apart from unit and integration the API e2e tests are all done by the developers. No UI automation at the moment.
The best experience that I’ve had was within a scrum with 4-5 devs and 1 dedicated tester where there’s a culture that everyone and anyone tests. That means you aren’t risking overloading the tester whilst still providing that more immediate feedback.
Within my office the ratio is now about 20:1 as we’ve not rehired testers as they’ve left. The wider organisation probably has a similar ratio but that is largely with dedicated test teams that just test release candidates etc and do system testing.
Personally I don’t like the idea of separate automation or regression teams so I wouldn’t include them in the ratio. To me when thinking about ratios, it is the people working together.
If we’re talking about a product team, something like a scrum setup, then I’d say a good ratio is usually about 2 Devs to 1 QA. QAs and testers can be manual, automation, or a mix of both, and it’s best not to separate frontend and backend devs because, either way, you’ll need to test both back and front ends along with their integrations. In my experience, this ratio often works best, although a 5:2 ratio can also be effective. But really, it depends on a bunch of other factors like the dev processes in your team, the skills of the devs and QA, the approaches and methods they use, etc
I also had experience working for a big corp with a ratio of 7.5 Devs to 1 QA (they only counted frontend devs, no matter how many backend devs were on the team, assuming that they would handle backend testing without QA). I could say a lot was wrong there in terms of team management resources, product quality, and task management.
‘What are your dev:qa ratios?’
In the teams I’ve been into:
10 to 0
4 to 1(or 2)
20 to 1(or 2)
2 to 1
'what your ideal ratio would be? ’
It doesn’t depend on me, but on the manager of the product quality and how much value he would get from the information provided by a tester. I’m fine with whatever their choice is.
‘would you include your automation team or regression team in these ratios?’
That depends on the definition of ‘qa’ and the role they assume in the company.
In some companies, anyone hired in relation to quality are part of testing/quality. But not everyone tests. People have various tasks more or less related to testing.
Some companies/departments/projects make people have double the set of responsibilities, most commonly a business analyst will also test. The management can say at some time that they are ‘testers’ for a project.
We have a few squads but its about 4-5 devs to a QA. In my squad its 6 devs to 1 QA. When it comes to regression testing and if we don’t have Automated tests then devs will normally help out with regression testing. If i’m snowed under or focusing on writing UI automated tests then they would help out with manual testing.
I generally find the more highly performing the scrum team as a whole, the less time is needed searching for and logging bugs. Some codebases are inherently fragile, and require more testing (specifically more regression testing, so it depends if the regression tests are reliably automated); some developers are more ‘trigger happy’ than others.
There is no perfect ration, but with the best will in the world, I’d not feel comfortable with any less than a 3:1 ratio in my experience.
I’ve usually worked in ~ 1:3 teams and that seemed fine. However, now that automation test development and documentation are on my plate, the 1:3 (my current situation) can be a bit daunting at times. The work load can ebb and flow, typically it’s fine.
