I saw a conversation pop up on Slack recently
Our team is starting to think about resourcing for the next year, unsure how many developers they’re going to be hiring but I want to make sure I ask for the right amount of testers for whatever they say.
Which reminded me of this thread from a few years ago
Furlough has, I’m sure, affected the ratios that teams currently have but I’m curious to know, what’s your current dev to tester ratio? And is it a ratio you’re comfortable with?
On paper: I’m the tester, we have 4 programmers, an architect, 2 “service folk”, and a PO who writes the functional specifications. This means I’m either 1:4, 1:5, 1:6 or 2:one of the previous numbers, depending on what the service folk are doing.
In reality: It’s complicated. The team hasn’t had a tester for 6 months before I got here last week, so they can obviously test themselves. One of the management team is a tester and wrote some of the automation, and helps with testing a lot. One of the service folk works on the development and programming when he can, and the other is THE domain expert, so his fingers are in a lot of pies. We work closely with another department, so their 3 team members sometimes hop on our stuff and vice-versa. I’ve actually written some code, but technically I’m not supposed to. So on that day we were 9 coders to no testers? …
My long term goal is to adopt “Modern Testing” principles in this team, but I’m not sure how to approach that.
Ordinarily we look for 1:3 as an ideal ratio. That varies, currently we have a 2:2 team and a 3:4 team and a 0:6 team, none of which we feel are problematic given the nature of the work and respective maturity of the teams in devs testing other devs’ work.
I guess my opinion is any flat ratio is misleading and the best choice is to make the team composition fit the work and the people you have available; that can mean some junior testers doubling up, devs doing some testing of others’ work or testers working between teams on a consultation basis.
In my last 5 jobs:
I do not have concerns on the ratio, the main problem is the difficulties of the context. Some of the past challenges:
Our team is starting to think about resourcing for the next year, unsure how many developers they’re going to be hiring but I want to make sure I ask for the right amount of testers for whatever they say.
I’d ask, how well do you know your context? What are the risks on the product/project, concerns of stakeholders, what’s the speed of dev, releases expectations, processes, managers and stakeholders, complexity and dependencies on people or systems, etc…
The ratio can be 0 testers to 10 devs up to more testers than devs…
Also to note, not all testers are equal, have the same strengths, have the same speed/efficiency, cost the same. There could be cases where you could have a single tester to replace 3 others. There could be cases where the devs or business are enough for testing the product.
In our company there are 10 developers (of which 6 regularly have work for test with remainder not so often) to 2 testers. We have zero automation and very aggressive timelines. So as you can imagine, it’s all go go go for test team 
I second the quote above that ratios alone will not form universally applicable rules IMHO. Also, certainly in our business there is an increasingly big push to get non-testers to do testing as right now getting stuff signed off is a bottleneck. As to the wisdom of this, done right, we should be able to mitigate a lot of the possible risks inherent in it, but in the haste to do anything to increase throughput, then perhaps we are not being sufficiently circumspect and will get bitten. I have been very clear to point out that I’m not simply being negative about having developers test each other’s work, but unless they are upping their own testing skillset (and the dedicated testing team have not really got the time to help them with this), then the fact there are generally a lot of bugs means we may want to think hard about this. However, as in so many things, ultimately we (i.e. testers) can but give the advice/facts as we see it and the company decides what risk they are prepared to accept. #TheJoysOfTesting 
Last 5 jobs have seen 1:4 and 1:5 roughly speaking I’ve been lucky.
Wild ride, I was last in this seat 20 years ago.
We have 14 devs, 2 dev ops, and 6 QAs (who also take care of release management).
Until very recently it was 14 devs, 2 dev ops and 4 QAs - and that was getting very tough. Happy to get those extra new testers, feels much more comfy
First of all, a few years ago I started talking about programmers and testers and analysts and so on, as with the agile mindset, everyone working in an agile team is meant to be a developer, as the whole team develops the product together - not only the programmers are developing and the other roles do something else.
So with this said, we currently have 3 testers and 4 programmers in our team (and 1 analyst and two mainly DevOps engineers), and this ratio is quite ok, sometimes we have work for another tester.
In my experience, there should not be too few testers, and I would not recommend going under 1:2 ratio of tester:programmer, 3:4 is even better.
With all those ratios, it is highly dependent on the product, its complexity and most of all on the experience of the team according a whole team approach to quality and the level of real teamwork practiced within the team.
For new teams: add an additional tester role in the beginning, it will clearly help in setting up a good workflow and sharping requirements, user stories, unit tests, code quality, architectural quality, documentation quality and teamwork - testers are not only writing test cases
Just don’t ask me about our male:female ratio, hahahaha
Oh dear 
I’ve worked in ratio’s of Tester:Dev 1:2 up to 1:8. If you find yourself at the higher end of that spectrum you have to change the approach to testing if you dont want bottlenecks. So whole team responsible for testing, TDD, pairing, mobbing and automation where possible. I take the ratio as a good indication of what is expected. When it was 1:2 it was an old codebase that was difficult to automate with really complicated functionallity and low tolerance for risk.
across the board in my company it’s roughly:
2QAs 8 Devs 1 outcome
Which i think is fairly manageable. The 2 QAs usually consist of one more experienced/SDET type role and the other maybe not so technical but with the desire to be so. We’re lucky because we work with WIP limits so once there is a clog the devs generally offer a helping hand and our processes have allowed us for more of a blur between dev and QA so the devs are fairly adequate testers
I’m running my department with 1 1/2 testers to 5 devs at the moment with the half being me (I’m the dev manager and split my time between a number of functions within my department) but am about to add a junior (complete newbie) tester to the mix who knows the products but has never tested before. Normally I’d like to run a maximum of a 1:3 ratio but it really depends on the team velocities and what’s being asked of the testers. I’m expecting my testers to include automated regression suites in their workload (we don’t have a separate set of QAs covering automation).
We deal with bottlenecks by slowing dev through moving one or two of the devs on to testing temporarily (I’m lucky to have devs who are comfortable switching to test or analysis as required).
I’d love to hear how onboarding your new tester goes 
We currently have a 1:16 ratio. We deal with this by making sure we are included in the process as early as possible to prevent problems later in the development phase, having group testing sessions which reduces time it takes to test, having engineers write tests with assistance from us and product as far as focusing on what we’re testing, and teaching all stakeholders how we test and what we look for. We have some days where it’s a bit more stressful but overall it works.
We will likely hire a new tester next year as we plan on growing our teams and I’d like to get back down to a 1:7 or less.
I think the answer depends on your circumstances. If your developers write good code & good unit tests, and if the team even does some higher level testing, then you’d probably need fewer testers instead of more.
These days, I see many companies having 1 tester support many developers, often across multiple projects. Ex. qa : dev = 1 : 6, 1:10, 1:20 just to get an idea. I have also seen some companies in which there are literally huge armies of testers ex. 4-6 : 2, many of who are contractors from staffing or consulting companies. I suspect that the latter kind of companies have bigger problems than just dev & testing practices.
Side note - It appears that the trend is to have very low qa-dev ratio, regardless of whether that is right for the company or not. From the perspective of the job seeker, the QA role might be harder to get into these days, unless you are exceptionally good at it.
Currently five developers to one tester. That just about supports the level of activity we have going on, from a business perspective, but also makes the process of automation slow going.
Currently, for me I’ve got about a 1:8 ratio of QA to Dev
Even though I have one dev almost consistently helping me with test automation when he has time, I still feel I’m a bottleneck. I also feel like I barely have time to do other “clean up tasks” like re-analyzing test cases, refactoring automation, pairing with developers, etc…
The team tries to help me out by at least writing as many unit tests as they can and do some manual testing. Even my manager wants to get one more QA in the team but he’s still waiting for an open req.
For now, I can only hope by pushing the “whole team approach” as best as I can.
@brian_seg, @conrad.braam, @heather_reid, @wildtests, @ipstefan, @gerardmccann, @snowkat100, @a_miller, @oconis, @pnaranja - I posted a question which is partly related to this question.
I’d appreciate it if you could share your thoughts there, at Reasons to leave the testing or QA career. It appears to me that the QA to DEV ratios are falling in many companies. Perhaps its time to rethink the QA career itself.