Most of the time it’s 5:1, for me, though I can sometimes find myself doing work for two teams. It used to be 10:1 plus I was the one with the winged feet when it came to client visits, back in the before times.
The current situation has worked quite well for me. I’ve quietly transitioned myself to more of an SDET type role.
I was thinking more about engineers who are writing automated tests. In my team I would expect these engineers to also do manual or explortatory testing.
Somehow I anticipated a specific definition like this. Titles are sadly very exchangeable and can be understood differently.
I hope you can still draw something from this answers.
If automation specific tasks most new projects these days its close to zero, the developers tend to do really good automated coverage.
The tester will generally help them out on the automation but its not their primary value contribution.
The exception being on a few large complex legacy projects where good developer automation practices were not have been applied in the early stages leaving regression risk as a high priority.
Its interesting though that if I join a team primarily as a tester often one to two days a week is optimal so I can be spread across multiple projects so a low ratio but if my primary contribution is automation its usually full time a much higher ratio. I’m personally much more productive in the former category adding value to multiple teams.
I’ve worked in ratios ranging from 6:1 to 3:1 (devs to testers). The ratios have worked well or badly depending on the context. When there is greater complexity, less good ACs and lower quality output coming to testers, then a lower ratio makes more sense due to the volume of work testers have to do, especially if we are trying to do test automation at the same time.
In a recent job we had 12 devs to 4 testers (3:1) and were able to add a lot of value through testing while staying on top of our automation with a little free time for things like refactoring and learning. Then we lost 2 testers (ratio went to 6:1) and that pretty radically changed how we felt and could perform as testers, which was that we began missing little things, there was zero time for refactoring or having a pull request process for our automation so that impacted our quality there too, and the little time we had for learning was non-existent.
It really illustrated well, to my mind anyway, how the 3:1 was the right ratio and allows us to make a business case to get it increased accordingly based on evidence of what worked well in the past.
Are you saying it’s actually greater that 1:7 then? i.e. ‘Greater’ in this case meaning your QE talents are serving more than 7 persons?!
Oh yes, most definitely. But please don’t worry for me, it’s a mutually supportive environment where we are together working to build products, with quality in mind. I’m not the only one carrying out testing activities, or the only one championing quality from different aspects.
It seems the ratio is increasingly going towards zero i.e. no QAs at all. In some cases its zero.
For me 1 QA : 2-3 Dev pair in a team.
My opinion toward more on How QA interact and collaborate with Dev in the team and How quality ownership being managed.
I saw QA armies and Devs work like throw the tickets over the fenced and that case might not reflect quality in term of ratio.
There is no specific number of QA engineers per developer that is standardized. The ratio of QA to dev can vary depending on various factors such as the complexity of the project, the method of development used, automation testing, volume testing, etc and the team member’s skills and experience.
So, it’s important to have enough resources to ensure the quality standards of the software being developed.
Dedicated QA team members or developers who also take on testing may be involved for this.
Ultimately, the ratio of QA to dev will depend on the needs and requirements of each project, and it’s the decision of
project management team to decide the appropriate members based on those factors.
In most of my Mobile QA projects for the last 14 years, it was mostly 4 - 8 devs per 1 QA.