Hi everyone!
I am curious, for those of you working in bigger engineering teams what is your quality engineers to software engineers ratio?
Thanks!
The project team I’m in has me as the sole tester, 4 engineers, and an engineer lead, making it 1:5 ratio.
5 Likes
My current team has 5 developers and one tester (little old me) and it results in a pretty good work pace - I’m not bored, but on the other hand, there is a steady regular flow of stuff to test. My previous team has only 2 developers and the work tempo felt very slow.
3 Likes
Depending how you count things, currently I’m the solo QE, working with 7 Developers. But there are other roles in the team as well. So purely DEV:TEST doesn’t give the whole picture.
4 Likes
At my company I am the sole tester and there are 9 devs, so can get quite busy for me at times, but I do get support from the PO’s with testing if needed and the devs do try and do some basic testing.
2 Likes
13:1 
That’s got to be some sort of a record!
4 Likes
QEs (which is still vague to me): 0
Testers: 4
Developers: 25-30
I would love to have some more tester coworkers while I also coach and guide my dev coworkers in testing.
Having to cope with 5-10 devs is demanding and I’m short on time to even slightly touch every topic / issue we work on.
2 Likes
2:1 here, so 4 test engineers to 8 software engineers (and a bunch of hardware engineers whose platform development we rely on too).
My wider business has multiple sites globally and ratios vary wildly. However, the organisation is alert to the benefits of testing (or at least the consequences of not resourcing test accordingly).
The ultimate goal is a 1:1 ratio for me - and for some others within our organisation. No idea if that is achievable - but with an increasing reliance of the development of automated test solutions (and since I work in embedded software there is often no COTS solution available) to meet challenging deadlines and growing product portfolios I need to grow the team. Developing a test framework and then authoring tests, alongside the essential manual testing means (at least from my viewpoint) that 1:1 is a reasonable goal. As the number of software engineers in test grow in my team if there is ever any slack from test solution development, test implementation and test execution, then that resource can be gainfully employed on product development - provided I can ensure independence of test when it comes back to my team for our regular activities.
3 Likes
The ultimate goal is a 1:1 ratio for me
I read in a clever paper somewhere that more testers is not always better. More testers might just lead to developers not bothering with any testing at all and throwing everything to the testers. Which makes testing ultimately a much slower and more costly process than if developers catch most bugs themselves.
edit: here’s the paper: https://www.researchgate.net/publication/2928929_Managing_The_Proportion_Of_Testers_To_other
5 Likes
Yeah. It’s interesting and it depends very much on what you’re doing really. Just for sheer amount of engineering work I have for my team to produce test solutions and implement the tests requires a lot of time.
We still demand good developer testing (functional - where they usually stick to happy path), and unit test implementation. Since test are involved at the pull request level we can perform an analysis of the unit tests before the code even makes it into main. So here, at least, where I can control what happens to some extent in conjunction with the cooperation of the software manager, software just coming over the wall with no testing doesn’t happen. Collecting metrics about requirement bounce back and bug fixes not sticking first time can help to spot trends and target education.
The ratio is probably something not to worry about to much. Its more about getting the right number of people for the work you have. That would happen to be 1:1 in my ideal situation here.
2 Likes
In my current team it’s just me to 4 developers.
A little while ago I wrote about the right ratio of developers to testers saying there is no right ratio that you can compare from company to company. Context matters too much. What’s the right ratio of developers to testers?’
Having said this, within a company you can use the ratio of devs to testers to some effect to know when you might need to hire.
I also cite the influencial paper written by Elizabeth Hendrickson after attending a STMR workshop which showed a correlation of a high number of testers to developers in bad projects.
3 Likes
Until the start of this year, I was 1 to about 35. We are now 2 
But I have been looking for more people for the team but wanted to get a feeling for where to get to.
5 Likes
I agree with @ckenst, context really matters (as usual).
There’s an answer to the question of “What’s the right ratio of developers to testers?” from a context-driven perspective in the free AST e-book “Navigating the World as a Context-Driven Tester” that I’m putting together with crowdsourced responses.
Check it out at navigating/navigatingcdt.md at main · associationforsoftwaretesting/navigating · GitHub
1 Like
3 testers to about 70 developers and I’m not overworked in any way.
On a project by project basis 1 to 10-15 is usually also fine unless its a government project with a lot of evidence of testing, regulatory requirements and very high complex risk levels.
The other case I see that swings the ratio’s is where a product already has technical debt in its regression risk coverage and it does not make sense for developers to change to cover this, here you can throw loads of testers at regression risk.
This model works when developers are part of the quality ownership and apply decent coding practices which include their own testing and automation.
4 Likes
I work in a service based organisation where mostly the ratio of QA’s to Dev’s is always 1:4. Service based companies run various projects within and it is difficult to offer QA’s with higher ratio. But the case differs with the Product based Companies where there is at least 1:2 ratio there. Certainly there is always a lesser ratio of testers in the team compared with Devs.
Seems like some lazy developers? XD This ratio is nuts hahaa
I make here an interesting observation:
Some differentiate between QE and QA/tester while others look like to not know the difference.
I’m even not sure how Deborah means it.
2 Likes
On the QE vs QA vs tester difference, 9 times out of 10 I’ve rarely seen a difference its just the title that changes.
The one exception being if the company is very script focused in their testing, I see higher ratio’s of these roles to developers when the focus is on scripted coverage.
If the comparison is primary on automation engineers which some titles represent in some companies the difference though also varies significantly.
I find it an odd one that where scripted coverage is the primary focus they tend to have higher QA to dev ratio’s as developers tend to be very good at doing scripted coverage. The higher ratio’s here can represent lower responsibility levels in developers or tasks developers are very suited for passed to other roles, sometimes with good reason.
4 Likes
@dsherwood Do you mean explicit quality engineers, like e.g. @fullsnacktester talks about? Like it’s been discussed here Can we talk about quality "engineering"? ?
Or any test focused role, no matter the name?
2 Likes
We are 3 testers and 7 devs, but that’s just people. Looking at hours we have about 1.5 : 6 . The testers work on multiple projects while the devs just have the one. It’s really stressful because they are so fast. There are teams in the company where this would be too many testers.
3 Likes