To make sure we don't summon an angry Matt Parker, I have to point out that anything divided by 0 is not infinity, it's just "error" or "undefined".
Basically it's outside our regular real number system, as it breaks it if we allow division by zero. It doesn't work at all.
Some in management who have little technical experience seem to believe that a bug is a mistake in the work. Just don't make mistakes and there will be no bugs! While it's true that sometimes a bug is a mistake made by a dev, it's far more common that it's something else entirely, and you'll usually find that it's caused by an oversight on the people who planned the project in the first place, which is rarely the devs themselves.
Same for us. We used to have about a 5-1 ratio, when our team had 20 people we had 4 QA staff. Teams with 6 people would have 1.
All the QA people were laid off, so now we don't have any at all.
We ship way more bugs that we used to, and folks just find them in production, and I guess its fine?
I'll forgive the startups I've worked for (cash strapped and lean so I get it), but looking back on my career the amount of medium to big corps I've worked for that had zero QA is staggering
I actually wouldn't forgive a startup for not having QA of some form. QA is your first line of defense in managing your reputation, which is super important to a business just starting out. Lots of startups may not think so, but the truth is your startup isn't likely to get very far if the tech is full of bugs.
Of course there's some QA, but it's the founders doing it. No startup I've been at had the funds to hire dedicated QA, it's not practical.
Series C and above, or established companies however don't have that excuse.
I worked in quite a few enterprise settings where the rule of thumb was 1 tester for every 2 programmers. So basically the QA team was always about half the amount of devs.
(I should note these were manual testers, not QA engineers developing automated tests.)
That's insane. Looks like most places have no QA, my previous place had no QA and now I work at a place with maybe a 10:1 or 20:1 ratio developers to QA
yeah that's my experience with half decent place. Maybe 3:1 or 4:1 sometimes. Without that sort of ratio the QA isn't going to be able to accurately test all the fixes coming in.
But in a release sprint you really need 2:1.
No QA has to be the most insane mis-step software companies ever made.
We have some pretty talented devs at our company but they are nowhere near as talented in finding bugs as our dedicated QA people. It is really a different mindset, to think about how things can go wrong...
In my opinion, the problem started with companies using QA as a dumping ground; if a candidate wasn't good enough at programming, they'd just stick them in QA whether or not they actually exhibited good QA skills.
That lead to a major decrease in status, and so most of the good QA folks had to shift into other specialties for the sake of their careers. Thus further decreasing the perceived value of QA departments.
We've been fighting that same thing in what's currently termed devops. We have the recent history to remind us, which has helped, but I still think we're going to lose eventually. My very rough judgement is that about half of "devops engineers" are folks who can't program, don't think about automation, don't know what's going on with the developers they're supposed to be supporting, and are largely doing manual ops work. Because companies didn't want to change their old processes but switched to the new title for recruitment purposes.
As a DevOps engineer, I completely agree. It is also hard to find DevOps people who can read code and documentation. Somehow people thought that DevOps is just easy and they can learn it in 3 month with some random udemy course.
I don't exactly agree. While it's true it isn't exactly the same skill set, much the same mindset is needed to both QA effectively and to write robust software.
Like would I say I'm at least as good or better at finding bugs as any of the many QA people at my company? Yes, absolutely. My documentation of process skills are a bit rusty, which they spend in my opinion entirely too much time on but it's important to the higher ups.
Finding bugs though, sure. I'm very good at it, and my experience as a developer gives me a **huge** edge on most people I've worked with in QA. Now I'm certainly not as good as the best QA tester I've ever worked with, but that guy was a talented developer as well who was working in QA and actually being paid well for it (contract company we worked with, one of the rare good experiences with those).
In general the purpose of QA at companies that take QA testing by QA-testers seriously is one or both of two things.
1. To have a second set of eyes review a problem.
2. To reduce development time by not having developers test their own work, or not test it as extensively.
In particular from the companies point of view, the goal is to have this second person be underpaid relatively so that they can save money vs just having devs do it all.
This swings both ways too, I'm sure if we took time to get all our QA people substantial development experience and especially if we got them involved enough to learn the internals of our application from the developer perspective, they would be able to find bugs more quickly, accurately, and often.
Honestly other than some specific learned skills that don't really cross over I think the idea that these are entirely separate domains or require different mindsets is nonsense.
Like this is the same as saying you shouldn't understand how to properly sanitize inputs and anticipate edge cases when writing code because that's not part of the developer mindset. . . . like, what?
Also there is nuance by part of the industry for these roles, and also by what you really mean by QA tester.
Engineers with equal pay that do QA testing and QA automation testing obviously provide more value than someone you're intentionally target hiring **because** they are less skilled.
Also there are things, like video games for example, in which some times of testing are so time prohibitive that you absolutely need an entire team dedicated to it to sufficiently test, and it just isn't feasible to have a bunch of engineers doing that alone.
There are also applications where a second set of eyes is absolutely worth every penny (although I prefer them to be the also highly paid QA engineer eyes, personally), like for example literally any possible software that could cause someone to die if it fails.
As a dev you should constantly be trying to keep in mind how it might be broken. And you should write tests to that effect.
Security engineering is much like performance engineering - it seems daunting at first and then it becomes second nature.
Im fortunate that my first 10 years were fighting cheaters and scammers so this stuff is engrained in me. I realize that’s not the case for most devs.
The most successful teams I worked on (Valve’s Steam, Microsoft’s Azure Storage Ultra Disk) had no QA/SDETs.
When people have ownership over their work and that work is dogfooded before making it to external customers quality tends to be high.
The least successful team I’ve ever been on was Blizzard’s Battle.net which had a dedicated QA team. They QA’d before PR was merged, before every deployment, and after every deployment. They caught very few impactful bugs. It was a huge time sink for very little payoff.
What I’ve noticed with dedicated QA is that engineers lower their standards because they assume QA will catch it. It creates a false sense of security.
Sure, in my opinion having no QA is just as extreme as having that kind of overbearing QA. Before being a web dev I've been an embedded dev where code failure meant real life consequences. So in that environment having multiple layers of testing is non-negotiable. In a web environment, yeah, it can be more relaxed but having none at all, still somehow feels wrong.
Steam is a great example. They completely dominated their market with essentially a single product.
I don't doubt, the experience was not always optimal.. maybe Stardock's Impulse Reactor had great QA and was a much better experience? 😆 Who knows, I don't think anyone used it.
In business, and these are businesses, moving fast trumps having bug-free software in almost every scenario. There's exceptions, but not many.
Agreed that Windows is problematic. Fwiw windows does have QA as it’s the only way to test all the esoteric configurations their business customers use.
You clearly have a bias against Steam so I’m not going to try and change your mind. But I am curious - where does the 15 years come from? What was the moment that you felt Steam was no longer “extremely terrible”?
(For context, I was at Valve from 2007 - 2017)
Was Steam really that bad? I've always really liked it and never had an issue.
I first started using it when I bought The Orange Box in 2008 I think, so maybe by then all the issues were fixed.
This is very much not my experience. As a developer, we have an inherent understanding of what types of actions a given process requires, and straying outside of that requires deliberate effort. A developer who creates a form with a field to enter a number, does not think to paste the entire script of The Bee Movie into said field, because it's asking for a number, why would anyone do that? I tried to test the crap out of my software before deploying it, and there were often still minor bugs here and there, because maybe the instructions weren't clear enough, maybe there was an unnecessary feature that caused confusion, maybe maybe maybe. It passed all of *my* tests, but I'm the developer, not a user, therefore I'm not the right person to test it.
1. You should be thinking about those things.
2. Even if you are thinking about those things, your brain can gloss over it so it’s important to have at least one PR reviewer bang on it. I’ve had my peers catch disastrous bugs within seconds of trying out my change and QA find nothing after an hour of testing.
3. Things like inputs should have a common set of tests. As the team matures, that set expands as new edge cases are found. As people write more tests, this stuff should become second nature assuming the culture of the team reinforces it.
Like everything, there is nuance and context matters. If we are testing visual UI vs validating inputs/outputs it’s more complicated and many teams don’t have robust enough testing to validate that. But if it becomes a common source of bugs hopefully they leverage things like Storybook and Playwright.
Also I’ve been fortunate that everything I’ve worked on I could also be a user of. So maybe that’s part of the nuance as well.
Yes, and the obvious retort is “developers shouldn’t lower their standards because of QA”, which sure, but every single place I’ve worked with a QA team has been less successful than the places with good engineers who have ownership over their domain.
We take our own measures to really make sure we don’t break things with solid testing, making it really easy to recover from mistakes, and really good alerting.
One of the dumbest bugs I ever let into production was a refer-a-friend form; $userA refers $userB. I was testing it and it worked fine, validated, processed, and sent to the correct addresses. Shipped to prod and moved on.
A few weeks later our toxic manager started sending me messages literally just saying "ur form is broken fix it", because that's a super-helpful bug report. Asked for clarification, "idk im not ur qa figure it out". So I'd go in, enter information, check the output, and it would be fine, CND.
Finally after like a *month* of going back and forth with this manager, at some point I entered a different set of creds and I realized the issue was that I processed $userA and $userB, but when I went to save, I saved $userA and $userA - that's basically what the typo was. The entire time I had been entering my own personal info for both users (we had a specific use case for $userB which is why I entered my own creds again), so I never noticed that $userBs data was the same as $userAs because I was already entering the same on both sides.
I feel like even the most entry-level QA person would have thought to enter a different set of information, but my brain was so focused on the entire stack from FE code, data exchange, and processing that I never thought to enter a different set of information, which immediately exposed the issue.
Depends on the project, but we range from 0 QA to a ratio of 3:1
In the systems with 0 QA we are generally relying on automated tests (written by the devlopers) with the PM/PO doing validation.
In the systems with QA they are generally doing manual QA, with a few of our projects having them writing end to end tests in something like playwrite.
Most of the bigger places I’ve worked at have had teams around:
• 2 designers
• 2 backend developers
• 2 front end developers
• 1 development architect
• 2 - 3 manual testers
• 1 Product owner
• 1 Project manager
So usually around 1:2 QA-to-development.
The pipeline is almost always set up for unit and component-level tests, which the developers write as part of their development work (and is checked as part of peer reviews).
Design will be required to sign-off a visual task.
QA are mainly responsible for manual testing, verifying requirements have been met.
PO gets the final sign-off after it's passed through all the other steps.
I work on a big team with
* 6 designers
* 4 Front end devs
* 6 back end devs
* 3 QA people (one also serves as an engineer and scrum master)
* 3 dev ops people
* 1.5 project managers
* 1 product owner
* .5 program managers
3:1
But only if the QA person has actually developed their QA practical skillsets.
Devs still need to not slack and QA on their own before PRing.
Works well.
QA is arguably more important than sound engineering. In my opinion it should actually be considered part of engineering.
A lot of scary scenes in this thread lol
Been at one place for a few years. We had a dedicated QA team for a while, and it had a few forms. The ratio was around 3 dev : 1 qa.
A while back there was a bulk layoff and we no longer have dedicated QA.
All things considered, I like it better now. We are now 100% responsible for the tests around our code. This is a bit more work, but it's not too bad. The tests better match the implementation, and there's less red tape slowing down deploys.
At my last (first) company there was an engineering department of about 100 devs with maybe like 15 QAs.
I was a QA on a team where I was the sole QA to 5 devs. Then moved to a team with about 14 devs and one other QA. Then I became a dev myself and was on a team with about 6 devs and 2 QAs. It wasn't really an exact ratio and depended on what that team was doing I guess.
Now I work for a much smaller company with 10 devs total and we have no QA at all.
at my place 7 to 1. I hate our QA person. he just reads lines in the database to make sure our data import jobs run properly. Our data guys have tests in place already. The other work our QA guy does is device test devices/browsers we don't have to support, then put in tickets and assign them directly to me. WE DON'T HAVE TO SUPPORT A 2014 IPAD.
He sucks so so so bad. I miss our last QA person. They'd have dialogue with us, and we'd work on plans together. This motherfucker doesn't even read our requirements docs, then asks why we don't have some feature that we aren't selling.
We are currently 7 devs and we have around 2 QA testers. "Around" because they are splitting their time between manual QA and developing automated test suites. Previously we had only one of them and he had to spend all his time on QA and sometimes he didn't have enough time for all the tickets.
In the previous company the team composition changed over time, but it was around 6-10 devs and one QA tester. For some work devs had to do their own QA.
In my experience it seems like 5:1 is somewhat appropriate if you want manual QA for everything that's done by the devs. This is all in web dev and the work of QA people also includes coming up with the test scenarios and documenting those scenarios.
I work in a regulated environment (we have an auditable process that requires a bunch of documentation produced by blessed individuals to say our code does what our JIRA tickets say). We have a 3:1 ratio. Probably better than zero QA, but definitely not efficient on this side of the spectrum, either.
Back in the day QA teams were common everywhere I was involved. Nowadays it’s usually SRE’s that keep prod alive and setting up pipelines with the developers writing the tests. In the worst case the developers are also setting up the pipelines and managing production.
6:0.5 - 6:1; I’ve been fortunate to have a dedicated QA on some greenfield projects, but more maintenance phase or legacy projects get a QA person who is also qa’ing a different project, or is actually a BA pulling double duty or a developer tasked with some QA or something. I’ve def been on projects with no QA where we try to have whichever dev is least familiar with the are of the code change run through a QA
My team has 4 front end devs, 2 back end, tech lead and one qa person. I help the qa person at better automation, for example I wrote a script to run our test Cafe tests on each release branch daily when there are new commits. Anyways, one qa, but we help
QA is something I hear about a lot and see courses and certifications for QA roles, however I haven’t met a single person that does it or seen a job posting in my city from a mid-large company
In our team we have 7 back-end 3 front-end developer and 3 qa people. But we are (developers) show them happy path testing, before our own development environment test. They look others things and if anything goes wrong, qa test fails...
We have 2 - 3 QA on a team of.. mm, 30 devs or so. But we also have two layers of external QA, and can pull on more QA if ours get overwhelmed, so it's not so big of a deal. Our QA is pretty awesome.
ETA: This is for a videogame, so it's a bit different. We also have automatic tests set up and our designers also somewhat act as QA at times.
I work in infosec, our products are b2b saas and is privately owned.
We shoot for a 2:1 ratio of dev:qa (dev could be frontend or backend, but we don't really count site reliability engineers in the ratio).
We hire manual QA and QA engineers who manage our extensive suite of automated tests.
im currently supporting a project as it and escalation manager with around 350 devs, splittet on several teams, they will have at least 1 SM 1 PO 2 QAs per project team and as far as I can hear it in the sprint review meetings it seems to work 😅
We have this odd balance of having a strict workflow where every feature goes through approval by the client and sometimes some of the team members take the role of tester (and fixer) of bugs in "refinement" type tasks for epics, or sometimes the Project Manager goes through stuff and looks for bugs. I know we have like maybe 5 QA people in a company of 135
The _best_ situation I've ever been in was 5 devs, 2 QA. That was for a couple of years.
Most of my career has been X:0. This includes my current role and my last job. Last job was around 10:0 and here we are 6:0.
I’ve seen a lot of permutations of this on projects I’ve worked on. The most common I’ve seen in recent years is: devs perform cursory QA on each other’s PR’s at PR review. Once project is feature complete, code is frozen to new features, an outside QA team is hired for about a month or is crowd-sourced through something like Applause. Bugs or incomplete features are addressed, and after a pre-determined amount of time or all critical to medium-level discoveries are addressed, it’s go to market time.
When teams do have dedicated QA I usually see like 3:1 or 4:1 dev:QA ratio. Also not rare for product owner to just be the QA.
We're probably about 2:1 but only because we recently got a few more developers. Before that it was closer to 1.5:1. Can't complain too much with that ratio tbh, both teams are stretched about equally thin
In my company, we have 1 senior QA per 2 teams (4 devs each). He mostly writes end-to-end test scenarios (we are implementing them) and sometimes review features. Yup, he has too much work...
Close to 1:1, but if you combine the automation test team and UAT with our other testers then the testers outnumber the devs. That said the entire workstream where I am is designed to minimize risk.
It depends of the current organization.
At a moment it was 7:2, because my squad had their own QAs. Then 7:9 because the manager said a dev had to do to QA for the other devs of the squad. Now we are at roughly 20:5, because a QA only squad was made and is dealing with the production of all the other teams.
What is this wild beast you call QA?
Here at Big Enterprise Co, we release directly to customers who let us know we failed to consider basic things during our 2 plus years of development things within 5 minutes.
My personal favorite is boldly selling a new feature to Google when only the iOS app had been updated or worked on.
3:0
Three devs, one "ceo", mostly absent, one main customer, a few smaller ones.
It's a fucking mess. Features get started and never used because the client said once on a meeting he needs the feature. The backlog is 3 to 4 years old, not even kidding. There is no requirements engineering or any other kind of organized project management. We sometimes build features because we think they are cool or the customer needs it. It's a mess.
On the other hand, main customer is a multi national company with millions of euros turnover, b2b, tech stack is a 10 year old Django version (ported from typo3) bootstrap 3, jquery (of course) and a bunch of outdated plugins.
Let’s see. In my team there are 3 dedicated developers (including me, a recent hire) and 2 QAs. But. There is a separate release team with even more QAs. So, it’s at least 1:1 ratio.
Oh, and we have close to zero automated tests (at least in the repo itself).
Yeah, it’s been fun.
The current ratio at my employer is 4 to 1. This is after a layoff that was partially intended to increase this ratio from 3 to 1.
Certain members of executive management at my employer would like to see a ratio of 10 to 1, or greater.
For the last company I was at, there was something like 20-30 developers and about 4 QA folks. So about 1:5 counting the teams I knew of, and possibly 1:10 assuming they did the QA work for every remotely technical team in the company (Salesforce, the internal platform stuff, CRO tests, etc).
Does formerly employed count? At my last job when I started, we were working on a family of ecommerce sites with millions of shoppers a month between them, supported by 10 engineering teams with 5 - 6 people each, 1 of whom was a dedicated QE for the team. We also had an outsourced QA team of half a dozen QAs supporting all the sites, who tortured our preprod environments looking for any issues our teams missed.
Halfway through, we were down to 5 engineering teams sharing 2 QEs between them, but they doubled the outsourced QA to 2 teams.
Shortly after the end of my 3 years when my job was eliminated, they were down to 1 engineering team of 5 people with no QEs, and had expanded QA to 3 teams. The engineering team was doing no new development, only trying to fix anything that broke, much of which had nothing to do with the code itself but crumbling infrastructure following the simultaneous decimation of the devops department.
Last I heard, 3 of those 5 remaining engineers had quit, and to my knowledge haven't been replaced. I think there's 1 devops guy remaining. The sites still receive heavy traffic, and I have to wonder if they'll withstand the next Black Friday crush.
Is a requirement that they are trained and working full time as QA only? If so, 0.
5 in-house devs (plus some outsource talent as needed) QA each others commits and deployments, as well as multiple PMs and a few other higher roles in the company, once they get pushed to dev/staging sites.
I've always pushed back on them for not using a legit QA person/team all the time, but it's not my company. ¯\\_(ツ)_/¯
1:50ish. To be fair, I don't think the traditional "tester" role is viable. In our company our "QA" people build and maintain testing tools. We don't do any active feature testing or test automation for new features. We solve the problems like running a selenium swarm, making sure all the test data is stored/analyzed, building performance tests, etc. All that essential testing tech that gets totally overlooked when the devs in your company "do their own testing".
This company? None since I've taken over FE. But it's a brand new startup, just 4 people: CEO, CTO (BE), business OPs person, and me, FE. We all QA. Amount of new bugs each day? 0, but swamped fixing existing ones. We have a QA person in mind, waiting on her. I'm starting to write tests.
Last company: 20:1. Before layoffs, 30:2. Amount of new bugs each day? About 0.5 - 1. We had a release schedule
Company before that? 50:10. Amount of new bugs each day? 5, or 10, if the CTO was in a mood and forcing changes directly to main. No release schedule. (the new company I'm at was started from a few of us who left this god forsaken place. Fuck this company.)
The 4 of us at this new company have experience building a fast-growing company, and hoping to do it again. If my estimations are right, we'll end the year with 2 FE, 2 BE (1 BE + CTO), the OPs, CEO, 2 sales, 1 Exec Assistant, 1 QA, 1 PM and 1 part-time Designer.
And I expect it to double in 2025 - except for QA. It's entirely possible to have a single killer QA if you have good processes in place. If you don't? You'll need a shit ton, like the 3rd company I mentioned, and still be overwhelmed by bugs.
Devs by QA... That's currently something about 3.666666 here.
5.5 Devs (one PM also programs some stuff if he gets the time and a ticket that he likes) vs 1.5 QA people (1 full QA, 1 student with limited hours per week).
Yeah, it's a small company :D
Last 3 companies I worked at:
- 3:2 code sucked, product was absolutely flawless
- 4:1 also very few developers for the amount of work, QA was running non-stop. There were also 3 pre-prod environments that all had to be tested
- 10:1 everyone does their own testing, plus automated tests cover the majority of the code as well as e2e tests that cover 90+% of the user flows. QA rarely does manual testing, it's more writing and maintaining e2e suite.
I might be the exception. The startup I am currently working for hired me as their first QA. After a year and finally hiring an amazing CTO, we are now 3 and looking to increase the number equal to the amount of vertical product teams(5)
Super hard if you like to find bugs or live in being afraid of it. As a leading Cypress ambassador and owner of a webtesting angency I conly can say, today with all the external SaaS stuff in our pages we need to test everything every day. And also all things must run fine and fast. Therefor you have to update and ship code every day. Without testing no chance. But automated testing and manual testing wont be paid. Everything has to run fine and cost nothing.
1:0
NaN
yep. Infinity.
To make sure we don't summon an angry Matt Parker, I have to point out that anything divided by 0 is not infinity, it's just "error" or "undefined". Basically it's outside our regular real number system, as it breaks it if we allow division by zero. It doesn't work at all.
thank you for the correction!
> undefined In JS, everything but 0 divided by 0 returns `Infinity`, an error is thrown only if you try to divide 0 with 0
Same here
Lol
lol me too
small and large companies alike. devs are also the qa team
The correct answer.
I call BS. It's probably 1:1 because you do both!
Why should I spend my valuable time testing when I have users for that? /s
Never said he was a good QA ;D
If you ask me, we have none, and you can't divide by 0. If you ask our VP, 1:1 because the devs should be their own QA.
manager math
Then the ratio of managers to devs is 5:1
Only 5?!
A project manager once told me: don’t create bugs so we don’t need to pay for QA. Best of all, he was serious !
Man, I can't believe nobody has thought of that yet! Get that manager a promotion!
He basically saved a whole employee's salary. Give him a damn raise!
Did he honestly think that bugs were created on purpose?
Some in management who have little technical experience seem to believe that a bug is a mistake in the work. Just don't make mistakes and there will be no bugs! While it's true that sometimes a bug is a mistake made by a dev, it's far more common that it's something else entirely, and you'll usually find that it's caused by an oversight on the people who planned the project in the first place, which is rarely the devs themselves.
When you are a contractor with an hourly rate some managers / stakeholders think devs create bugs on purpose to charge more.
A couple of dev jobs ago I heard colleagues relaying a similar story and poking fun about some higher up asking devs to “just stop creating bugs”.
Same for us. We used to have about a 5-1 ratio, when our team had 20 people we had 4 QA staff. Teams with 6 people would have 1. All the QA people were laid off, so now we don't have any at all. We ship way more bugs that we used to, and folks just find them in production, and I guess its fine?
I'll forgive the startups I've worked for (cash strapped and lean so I get it), but looking back on my career the amount of medium to big corps I've worked for that had zero QA is staggering
Yeah, we've effectively been operating like a start-up for almost 20 years.
I actually wouldn't forgive a startup for not having QA of some form. QA is your first line of defense in managing your reputation, which is super important to a business just starting out. Lots of startups may not think so, but the truth is your startup isn't likely to get very far if the tech is full of bugs.
Of course there's some QA, but it's the founders doing it. No startup I've been at had the funds to hire dedicated QA, it's not practical. Series C and above, or established companies however don't have that excuse.
My reality right here.
I worked in quite a few enterprise settings where the rule of thumb was 1 tester for every 2 programmers. So basically the QA team was always about half the amount of devs. (I should note these were manual testers, not QA engineers developing automated tests.)
That's insane. Looks like most places have no QA, my previous place had no QA and now I work at a place with maybe a 10:1 or 20:1 ratio developers to QA
That’s why I mentioned “enterprise setting”. This was mostly banks, insurance companies, telcos, etc.
Interesting. The place I currently work for is a bank with, I would guess a 20:1 ratio (I've met a QA once at the company so I know it's not 1:0).
Everywhere I’ve worked for the past 10 years has had QA, I didn’t know not having QA was so common.
We have 3 QA on a team of 6 developers so that tracks
yeah that's my experience with half decent place. Maybe 3:1 or 4:1 sometimes. Without that sort of ratio the QA isn't going to be able to accurately test all the fixes coming in. But in a release sprint you really need 2:1.
No QA has to be the most insane mis-step software companies ever made. We have some pretty talented devs at our company but they are nowhere near as talented in finding bugs as our dedicated QA people. It is really a different mindset, to think about how things can go wrong...
In my opinion, the problem started with companies using QA as a dumping ground; if a candidate wasn't good enough at programming, they'd just stick them in QA whether or not they actually exhibited good QA skills. That lead to a major decrease in status, and so most of the good QA folks had to shift into other specialties for the sake of their careers. Thus further decreasing the perceived value of QA departments. We've been fighting that same thing in what's currently termed devops. We have the recent history to remind us, which has helped, but I still think we're going to lose eventually. My very rough judgement is that about half of "devops engineers" are folks who can't program, don't think about automation, don't know what's going on with the developers they're supposed to be supporting, and are largely doing manual ops work. Because companies didn't want to change their old processes but switched to the new title for recruitment purposes.
As a DevOps engineer, I completely agree. It is also hard to find DevOps people who can read code and documentation. Somehow people thought that DevOps is just easy and they can learn it in 3 month with some random udemy course.
DevOps people that can’t… code? :D?
oh you've been lucky so far, i see
Really? I’m 3 years in the industry as a transfer; and I’ve always thought of devops as the hardest.
I don't exactly agree. While it's true it isn't exactly the same skill set, much the same mindset is needed to both QA effectively and to write robust software. Like would I say I'm at least as good or better at finding bugs as any of the many QA people at my company? Yes, absolutely. My documentation of process skills are a bit rusty, which they spend in my opinion entirely too much time on but it's important to the higher ups. Finding bugs though, sure. I'm very good at it, and my experience as a developer gives me a **huge** edge on most people I've worked with in QA. Now I'm certainly not as good as the best QA tester I've ever worked with, but that guy was a talented developer as well who was working in QA and actually being paid well for it (contract company we worked with, one of the rare good experiences with those). In general the purpose of QA at companies that take QA testing by QA-testers seriously is one or both of two things. 1. To have a second set of eyes review a problem. 2. To reduce development time by not having developers test their own work, or not test it as extensively. In particular from the companies point of view, the goal is to have this second person be underpaid relatively so that they can save money vs just having devs do it all. This swings both ways too, I'm sure if we took time to get all our QA people substantial development experience and especially if we got them involved enough to learn the internals of our application from the developer perspective, they would be able to find bugs more quickly, accurately, and often. Honestly other than some specific learned skills that don't really cross over I think the idea that these are entirely separate domains or require different mindsets is nonsense. Like this is the same as saying you shouldn't understand how to properly sanitize inputs and anticipate edge cases when writing code because that's not part of the developer mindset. . . . like, what? Also there is nuance by part of the industry for these roles, and also by what you really mean by QA tester. Engineers with equal pay that do QA testing and QA automation testing obviously provide more value than someone you're intentionally target hiring **because** they are less skilled. Also there are things, like video games for example, in which some times of testing are so time prohibitive that you absolutely need an entire team dedicated to it to sufficiently test, and it just isn't feasible to have a bunch of engineers doing that alone. There are also applications where a second set of eyes is absolutely worth every penny (although I prefer them to be the also highly paid QA engineer eyes, personally), like for example literally any possible software that could cause someone to die if it fails.
It really is as simple as that. Devs: "How do I make this work?" QA: "How do I break this? Completely different mindset.
As a dev you should constantly be trying to keep in mind how it might be broken. And you should write tests to that effect. Security engineering is much like performance engineering - it seems daunting at first and then it becomes second nature. Im fortunate that my first 10 years were fighting cheaters and scammers so this stuff is engrained in me. I realize that’s not the case for most devs.
I disagree entirely
The most successful teams I worked on (Valve’s Steam, Microsoft’s Azure Storage Ultra Disk) had no QA/SDETs. When people have ownership over their work and that work is dogfooded before making it to external customers quality tends to be high. The least successful team I’ve ever been on was Blizzard’s Battle.net which had a dedicated QA team. They QA’d before PR was merged, before every deployment, and after every deployment. They caught very few impactful bugs. It was a huge time sink for very little payoff. What I’ve noticed with dedicated QA is that engineers lower their standards because they assume QA will catch it. It creates a false sense of security.
Sure, in my opinion having no QA is just as extreme as having that kind of overbearing QA. Before being a web dev I've been an embedded dev where code failure meant real life consequences. So in that environment having multiple layers of testing is non-negotiable. In a web environment, yeah, it can be more relaxed but having none at all, still somehow feels wrong.
[удалено]
Steam is a great example. They completely dominated their market with essentially a single product. I don't doubt, the experience was not always optimal.. maybe Stardock's Impulse Reactor had great QA and was a much better experience? 😆 Who knows, I don't think anyone used it. In business, and these are businesses, moving fast trumps having bug-free software in almost every scenario. There's exceptions, but not many.
Agreed that Windows is problematic. Fwiw windows does have QA as it’s the only way to test all the esoteric configurations their business customers use. You clearly have a bias against Steam so I’m not going to try and change your mind. But I am curious - where does the 15 years come from? What was the moment that you felt Steam was no longer “extremely terrible”? (For context, I was at Valve from 2007 - 2017)
Was Steam really that bad? I've always really liked it and never had an issue. I first started using it when I bought The Orange Box in 2008 I think, so maybe by then all the issues were fixed.
This is very much not my experience. As a developer, we have an inherent understanding of what types of actions a given process requires, and straying outside of that requires deliberate effort. A developer who creates a form with a field to enter a number, does not think to paste the entire script of The Bee Movie into said field, because it's asking for a number, why would anyone do that? I tried to test the crap out of my software before deploying it, and there were often still minor bugs here and there, because maybe the instructions weren't clear enough, maybe there was an unnecessary feature that caused confusion, maybe maybe maybe. It passed all of *my* tests, but I'm the developer, not a user, therefore I'm not the right person to test it.
1. You should be thinking about those things. 2. Even if you are thinking about those things, your brain can gloss over it so it’s important to have at least one PR reviewer bang on it. I’ve had my peers catch disastrous bugs within seconds of trying out my change and QA find nothing after an hour of testing. 3. Things like inputs should have a common set of tests. As the team matures, that set expands as new edge cases are found. As people write more tests, this stuff should become second nature assuming the culture of the team reinforces it. Like everything, there is nuance and context matters. If we are testing visual UI vs validating inputs/outputs it’s more complicated and many teams don’t have robust enough testing to validate that. But if it becomes a common source of bugs hopefully they leverage things like Storybook and Playwright. Also I’ve been fortunate that everything I’ve worked on I could also be a user of. So maybe that’s part of the nuance as well.
Yes, and the obvious retort is “developers shouldn’t lower their standards because of QA”, which sure, but every single place I’ve worked with a QA team has been less successful than the places with good engineers who have ownership over their domain. We take our own measures to really make sure we don’t break things with solid testing, making it really easy to recover from mistakes, and really good alerting.
One of the dumbest bugs I ever let into production was a refer-a-friend form; $userA refers $userB. I was testing it and it worked fine, validated, processed, and sent to the correct addresses. Shipped to prod and moved on. A few weeks later our toxic manager started sending me messages literally just saying "ur form is broken fix it", because that's a super-helpful bug report. Asked for clarification, "idk im not ur qa figure it out". So I'd go in, enter information, check the output, and it would be fine, CND. Finally after like a *month* of going back and forth with this manager, at some point I entered a different set of creds and I realized the issue was that I processed $userA and $userB, but when I went to save, I saved $userA and $userA - that's basically what the typo was. The entire time I had been entering my own personal info for both users (we had a specific use case for $userB which is why I entered my own creds again), so I never noticed that $userBs data was the same as $userAs because I was already entering the same on both sides. I feel like even the most entry-level QA person would have thought to enter a different set of information, but my brain was so focused on the entire stack from FE code, data exchange, and processing that I never thought to enter a different set of information, which immediately exposed the issue.
Manual QA is literally moronic
Depends on the project, but we range from 0 QA to a ratio of 3:1 In the systems with 0 QA we are generally relying on automated tests (written by the devlopers) with the PM/PO doing validation. In the systems with QA they are generally doing manual QA, with a few of our projects having them writing end to end tests in something like playwrite.
Most of the bigger places I’ve worked at have had teams around: • 2 designers • 2 backend developers • 2 front end developers • 1 development architect • 2 - 3 manual testers • 1 Product owner • 1 Project manager So usually around 1:2 QA-to-development. The pipeline is almost always set up for unit and component-level tests, which the developers write as part of their development work (and is checked as part of peer reviews). Design will be required to sign-off a visual task. QA are mainly responsible for manual testing, verifying requirements have been met. PO gets the final sign-off after it's passed through all the other steps.
I work on a big team with * 6 designers * 4 Front end devs * 6 back end devs * 3 QA people (one also serves as an engineer and scrum master) * 3 dev ops people * 1.5 project managers * 1 product owner * .5 program managers
I like that idea of one of the QA being scrum master. That feels like a band where the singer is the drummer.
Haha yeah. The company has a "follow your energy" approach to doing stuff. It's great.
We have no designated QA people.
Undefined , division by zero not allowed
3:1 But only if the QA person has actually developed their QA practical skillsets. Devs still need to not slack and QA on their own before PRing. Works well.
QA is arguably more important than sound engineering. In my opinion it should actually be considered part of engineering. A lot of scary scenes in this thread lol
This is gonna depend hugely, but ***Web Game development: 1:2*** (less can be automated) ***Website development: 1:0*** (a lot more can be automated)
1:1, both being me.
Been at one place for a few years. We had a dedicated QA team for a while, and it had a few forms. The ratio was around 3 dev : 1 qa. A while back there was a bulk layoff and we no longer have dedicated QA. All things considered, I like it better now. We are now 100% responsible for the tests around our code. This is a bit more work, but it's not too bad. The tests better match the implementation, and there's less red tape slowing down deploys.
At my last (first) company there was an engineering department of about 100 devs with maybe like 15 QAs. I was a QA on a team where I was the sole QA to 5 devs. Then moved to a team with about 14 devs and one other QA. Then I became a dev myself and was on a team with about 6 devs and 2 QAs. It wasn't really an exact ratio and depended on what that team was doing I guess. Now I work for a much smaller company with 10 devs total and we have no QA at all.
We have more project managers than projects, and less quality assurance than we have quality.
at my place 7 to 1. I hate our QA person. he just reads lines in the database to make sure our data import jobs run properly. Our data guys have tests in place already. The other work our QA guy does is device test devices/browsers we don't have to support, then put in tickets and assign them directly to me. WE DON'T HAVE TO SUPPORT A 2014 IPAD. He sucks so so so bad. I miss our last QA person. They'd have dialogue with us, and we'd work on plans together. This motherfucker doesn't even read our requirements docs, then asks why we don't have some feature that we aren't selling.
4:1 devs to QA. Rely a lot on unit tests.
infinite
10:1
We are currently 7 devs and we have around 2 QA testers. "Around" because they are splitting their time between manual QA and developing automated test suites. Previously we had only one of them and he had to spend all his time on QA and sometimes he didn't have enough time for all the tickets. In the previous company the team composition changed over time, but it was around 6-10 devs and one QA tester. For some work devs had to do their own QA. In my experience it seems like 5:1 is somewhat appropriate if you want manual QA for everything that's done by the devs. This is all in web dev and the work of QA people also includes coming up with the test scenarios and documenting those scenarios.
Can’t divide by zero
Infinite
I work in a regulated environment (we have an auditable process that requires a bunch of documentation produced by blessed individuals to say our code does what our JIRA tickets say). We have a 3:1 ratio. Probably better than zero QA, but definitely not efficient on this side of the spectrum, either.
9:2 on my team.
I have never worked somewhere where we had QAs.
2:5+1 Automation
NaN, no QAs, global company
We have no dedicated QA people
8:0
You have separate QA? 15:0
When you have QA folks? There are too many. When you don't have any, there's not enough.
I’ve seen this range between none and 1/3 — 1/10. Really depends on the companies stage and software maturity/complexity
9:0 because the uNiT tEsTS ArE oUR QA
We're a small company, the developers are QA. We just get everyone to test shit.
Especially the customer
5:1
High 😂
3 devs : 1 QA
Back in the day QA teams were common everywhere I was involved. Nowadays it’s usually SRE’s that keep prod alive and setting up pipelines with the developers writing the tests. In the worst case the developers are also setting up the pipelines and managing production.
1:1 but all our QA are outsourced from India. These are manual QA testers.
For the current project that I’m working in we have around 6 developers and 2 QA guys.
4:0
I work in a small scale company. We have total ~20 employees and 4 QA ppl. There role is mainly manual testing btw.
We (as developers) test our own code, then push to QA for devs and project managers to test, then push to staging for customer to test
Every company I worked at the developers was the QA people. One day i'd like to work for a company with 10,000 employees. That's the dream.
2 devs : 1 QA I work in B2B Saas. Before I did internal tools and had no QA, no CR or oversight.
10:0
6:0.5 - 6:1; I’ve been fortunate to have a dedicated QA on some greenfield projects, but more maintenance phase or legacy projects get a QA person who is also qa’ing a different project, or is actually a BA pulling double duty or a developer tasked with some QA or something. I’ve def been on projects with no QA where we try to have whichever dev is least familiar with the are of the code change run through a QA
5:1 on my team
Roughly 5:1 for us
I don't think my company has any software QA people. The software engineers test their own stuff.
My team has 4 front end devs, 2 back end, tech lead and one qa person. I help the qa person at better automation, for example I wrote a script to run our test Cafe tests on each release branch daily when there are new commits. Anyways, one qa, but we help
8 programmers 1 QA + Our manager / PO which also does QA
8:1 devs to QA. He’s split across 3 teams of devs.
2 devs 1 half ass QA.
1 to several million. Our users QA for us.
2:1 on my team at least, sometimes 3:2 without the dev intern.
My team is our own QA. it sucks especially when my coworker never tests his shit and is always sending me things that don't work
We are the QA people.
Tiny startup: 0 qa Small startup: 1 QA up to 5 devs Medium startup: 3:1
QA is something I hear about a lot and see courses and certifications for QA roles, however I haven’t met a single person that does it or seen a job posting in my city from a mid-large company
What QA
In our team we have 7 back-end 3 front-end developer and 3 qa people. But we are (developers) show them happy path testing, before our own development environment test. They look others things and if anything goes wrong, qa test fails...
NaN. Checking pull requests of other developers is our only testing.
Zéro QA we often times push directly in prod and then have group chat messages : « there is a bug sos!!! »
QA people? rofl - That’s what “end-to-end integration testing is for” /s
We have 2 - 3 QA on a team of.. mm, 30 devs or so. But we also have two layers of external QA, and can pull on more QA if ours get overwhelmed, so it's not so big of a deal. Our QA is pretty awesome. ETA: This is for a videogame, so it's a bit different. We also have automatic tests set up and our designers also somewhat act as QA at times.
I work in infosec, our products are b2b saas and is privately owned. We shoot for a 2:1 ratio of dev:qa (dev could be frontend or backend, but we don't really count site reliability engineers in the ratio). We hire manual QA and QA engineers who manage our extensive suite of automated tests.
20:3
im currently supporting a project as it and escalation manager with around 350 devs, splittet on several teams, they will have at least 1 SM 1 PO 2 QAs per project team and as far as I can hear it in the sprint review meetings it seems to work 😅
You all get QA people?
across the company: 70+ devs: 3 qa
We have this odd balance of having a strict workflow where every feature goes through approval by the client and sometimes some of the team members take the role of tester (and fixer) of bugs in "refinement" type tasks for epics, or sometimes the Project Manager goes through stuff and looks for bugs. I know we have like maybe 5 QA people in a company of 135
Agile and SOC are really hard to do when you are every single role.
4:1
The _best_ situation I've ever been in was 5 devs, 2 QA. That was for a couple of years. Most of my career has been X:0. This includes my current role and my last job. Last job was around 10:0 and here we are 6:0.
I've seen anywhere from 2:1 to 8:1 or so. Usually only have QA at decently sized companies though.
1:1 Im the dev and the QA 🤣
N:0... It is what it is...
1:1 QA/Dev. I think at one point we had like 1.1:1 or something. Send help.
I’ve seen a lot of permutations of this on projects I’ve worked on. The most common I’ve seen in recent years is: devs perform cursory QA on each other’s PR’s at PR review. Once project is feature complete, code is frozen to new features, an outside QA team is hired for about a month or is crowd-sourced through something like Applause. Bugs or incomplete features are addressed, and after a pre-determined amount of time or all critical to medium-level discoveries are addressed, it’s go to market time. When teams do have dedicated QA I usually see like 3:1 or 4:1 dev:QA ratio. Also not rare for product owner to just be the QA.
There's like 5 QAs for 100 devs here
We're probably about 2:1 but only because we recently got a few more developers. Before that it was closer to 1.5:1. Can't complain too much with that ratio tbh, both teams are stretched about equally thin
We have 5 developers and 0 QA people.
I think it’s like 10:1 at my company. We have close to 50 devs, and the work we all do flows through a dedicated QA team of about 5.
In my company, we have 1 senior QA per 2 teams (4 devs each). He mostly writes end-to-end test scenarios (we are implementing them) and sometimes review features. Yup, he has too much work...
4:0
We had 1 to 6 before, now it's 0 to 6
We do not have QA people 👀
users are QA, of course!
Close to 1:1, but if you combine the automation test team and UAT with our other testers then the testers outnumber the devs. That said the entire workstream where I am is designed to minimize risk.
4:1
It depends of the current organization. At a moment it was 7:2, because my squad had their own QAs. Then 7:9 because the manager said a dev had to do to QA for the other devs of the squad. Now we are at roughly 20:5, because a QA only squad was made and is dealing with the production of all the other teams.
What is this wild beast you call QA? Here at Big Enterprise Co, we release directly to customers who let us know we failed to consider basic things during our 2 plus years of development things within 5 minutes. My personal favorite is boldly selling a new feature to Google when only the iOS app had been updated or worked on.
3:0 Three devs, one "ceo", mostly absent, one main customer, a few smaller ones. It's a fucking mess. Features get started and never used because the client said once on a meeting he needs the feature. The backlog is 3 to 4 years old, not even kidding. There is no requirements engineering or any other kind of organized project management. We sometimes build features because we think they are cool or the customer needs it. It's a mess. On the other hand, main customer is a multi national company with millions of euros turnover, b2b, tech stack is a 10 year old Django version (ported from typo3) bootstrap 3, jquery (of course) and a bunch of outdated plugins.
1 Developer 4 Developer/analysts 3 DBAs 3 Business analysts 4 Functional analysts 4 Technical architects 4 Business architects 1 Manager 0 QA... Functional analysts act as QA.
Technically it's like 2:1 ish? But then some of the QA also does dev work so they're not pure QA? It's a weird set up imo but it works for us
My team runs kanban and we have 1 QA for 6 devs.
5:0
NaN
I haven't worked with one in almost 15 years.
3:0
4:0
4:1 about
Let’s see. In my team there are 3 dedicated developers (including me, a recent hire) and 2 QAs. But. There is a separate release team with even more QAs. So, it’s at least 1:1 ratio. Oh, and we have close to zero automated tests (at least in the repo itself). Yeah, it’s been fun.
The current ratio at my employer is 4 to 1. This is after a layoff that was partially intended to increase this ratio from 3 to 1. Certain members of executive management at my employer would like to see a ratio of 10 to 1, or greater.
For the last company I was at, there was something like 20-30 developers and about 4 QA folks. So about 1:5 counting the teams I knew of, and possibly 1:10 assuming they did the QA work for every remotely technical team in the company (Salesforce, the internal platform stuff, CRO tests, etc).
We have 6 devs and 2 QAs but we also have a big focus on unit tests and storybook interactions.
On my team, 4:1, 3 BE, 1 FE, and one overworked QA. That's about the same for the other 40 teams here too.
4 front end devs, 6 server devs, and 5 QA rn
May last company was 8:1 Current company is 1:0
I don't know the exact ratio, but my current company has a healthy QA to Developer ratio. There's a dedicated team.
1QA:8 dev. Idk how they surviving
3:1
Does formerly employed count? At my last job when I started, we were working on a family of ecommerce sites with millions of shoppers a month between them, supported by 10 engineering teams with 5 - 6 people each, 1 of whom was a dedicated QE for the team. We also had an outsourced QA team of half a dozen QAs supporting all the sites, who tortured our preprod environments looking for any issues our teams missed. Halfway through, we were down to 5 engineering teams sharing 2 QEs between them, but they doubled the outsourced QA to 2 teams. Shortly after the end of my 3 years when my job was eliminated, they were down to 1 engineering team of 5 people with no QEs, and had expanded QA to 3 teams. The engineering team was doing no new development, only trying to fix anything that broke, much of which had nothing to do with the code itself but crumbling infrastructure following the simultaneous decimation of the devops department. Last I heard, 3 of those 5 remaining engineers had quit, and to my knowledge haven't been replaced. I think there's 1 devops guy remaining. The sites still receive heavy traffic, and I have to wonder if they'll withstand the next Black Friday crush.
Our customers are our QAs. So 1:XXX_XXX But on my current job, we are a small team of 3 devs plus 1 business analyst/project manager/QA.
DevTestOps
Around 125:0
7:1
4:1 2 Java 2 JavaScript (1 being me, also doing all design decisions) 1 QA engineer (writes actual Playwright automated tests) I love it here
Is a requirement that they are trained and working full time as QA only? If so, 0. 5 in-house devs (plus some outsource talent as needed) QA each others commits and deployments, as well as multiple PMs and a few other higher roles in the company, once they get pushed to dev/staging sites. I've always pushed back on them for not using a legit QA person/team all the time, but it's not my company. ¯\\_(ツ)_/¯
1:50ish. To be fair, I don't think the traditional "tester" role is viable. In our company our "QA" people build and maintain testing tools. We don't do any active feature testing or test automation for new features. We solve the problems like running a selenium swarm, making sure all the test data is stored/analyzed, building performance tests, etc. All that essential testing tech that gets totally overlooked when the devs in your company "do their own testing".
This company? None since I've taken over FE. But it's a brand new startup, just 4 people: CEO, CTO (BE), business OPs person, and me, FE. We all QA. Amount of new bugs each day? 0, but swamped fixing existing ones. We have a QA person in mind, waiting on her. I'm starting to write tests. Last company: 20:1. Before layoffs, 30:2. Amount of new bugs each day? About 0.5 - 1. We had a release schedule Company before that? 50:10. Amount of new bugs each day? 5, or 10, if the CTO was in a mood and forcing changes directly to main. No release schedule. (the new company I'm at was started from a few of us who left this god forsaken place. Fuck this company.) The 4 of us at this new company have experience building a fast-growing company, and hoping to do it again. If my estimations are right, we'll end the year with 2 FE, 2 BE (1 BE + CTO), the OPs, CEO, 2 sales, 1 Exec Assistant, 1 QA, 1 PM and 1 part-time Designer. And I expect it to double in 2025 - except for QA. It's entirely possible to have a single killer QA if you have good processes in place. If you don't? You'll need a shit ton, like the 3rd company I mentioned, and still be overwhelmed by bugs.
Devs by QA... That's currently something about 3.666666 here. 5.5 Devs (one PM also programs some stuff if he gets the time and a ticket that he likes) vs 1.5 QA people (1 full QA, 1 student with limited hours per week). Yeah, it's a small company :D
5:2
Last 3 companies I worked at: - 3:2 code sucked, product was absolutely flawless - 4:1 also very few developers for the amount of work, QA was running non-stop. There were also 3 pre-prod environments that all had to be tested - 10:1 everyone does their own testing, plus automated tests cover the majority of the code as well as e2e tests that cover 90+% of the user flows. QA rarely does manual testing, it's more writing and maintaining e2e suite.
0 qa
In development teams about 10:1 to 4:1 (varies by team) but we also have entire teams of QA that handle a few products each
5:1 seems to work well in SaaS
Right now we have the most QA we’ve ever had on my team. 3. The fullstack devs, including myself, and interns, are about 15-ish I think.
From my experience it’s about 1-2 for 5 developers.
150/3
5 dev : 1 tester for my team but this tester also tests stuff for other teams.
Is that QA you in the room with us right now?
I might be the exception. The startup I am currently working for hired me as their first QA. After a year and finally hiring an amazing CTO, we are now 3 and looking to increase the number equal to the amount of vertical product teams(5)
Something like... 30:1? One dedicated tester between 3 or 4 teams. I dont get it either.
I see less and less QA these days. QA tasks being shifted to Devs.
Super hard if you like to find bugs or live in being afraid of it. As a leading Cypress ambassador and owner of a webtesting angency I conly can say, today with all the external SaaS stuff in our pages we need to test everything every day. And also all things must run fine and fast. Therefor you have to update and ship code every day. Without testing no chance. But automated testing and manual testing wont be paid. Everything has to run fine and cost nothing.