I've noticed a growing trend in software companies over the last few years in which upper management declares that quality assurance roles will no longer exist at the company. Then, the entire QA department is either let go or transitioned into traditional software development roles. Everyone is now just a software engineer, and everyone owns quality.
This is a mistake.
I'd argue that the idea that everyone owns quality, while positive in intent, is deeply misguided for one big reason: when everyone owns quality, no one does.
Yes, every software engineer should take pride in their work. Yes, every software engineer should carefully test their code, both manually and with automated tests. Yes, every software engineer should consider more than just the happy path and look for edge cases and instances where things could go wrong. These things are all well and good.
But, software engineers and QA engineers simply have different mindsets. Software engineers want to build things. QA engineers want to see how they can break things. Software engineers have pressure to deliver new features. QA engineers have pressure to ensure the app works smoothly for customers.
So why not just train software engineers to have a quality mindset, you say?Sure, that's fine. Just know that transitioning between these two mindsets throughout the day is no small feat. Managing your time between software engineering and QA tasks is no small feat either.
There is also a difference in skillset. Software engineers are typically expected to have expertise in one or two programming languages and frameworks within the company's tech stack and to be good at building products with those tools. QA engineers are expected to have expertise in testing frameworks like Selenium, Pytest, Cypress, or Playwright and to be good at writing airtight test suites with those tools.
So why not just train software engineers on another testing framework, you say? Sure, that's fine. Just know that you're adding that to the list of everything else software engineers are expected to do. We must all be full-stack engineers, experts in both frontend and backend development, security, accessibility, localization, DevOps, and now testing.
How does the saying go? "A jack of all trades is a master of none."
Or do you prefer the alternate ending? "A jack of all trades is a master of none, but oftentimes better than a master of one."
Scholars have debated the origins of the phrase but generally accept that the second line was added later. Regardless, there is no denying that in the ever-expanding and hyper-specialized field of software engineering, one simply cannot become a master of all things. Yes, we can teach software engineers to use additional testing frameworks, but their expertise will never be as deep as someone's who focuses exclusively on QA.
The biggest challenge comes when testing end-to-end pieces of functionality that are built by multiple teams. Without a QA organization, questions of ownership arise.
Who's in charge of making sure this functionality gets tested? Who owns updating and maintaining the shared test suite? Who determines what level of coverage is acceptable, and who enforces that requirement? What about the actual test suite infrastructure and pipeline maintenance? Who owns that?
In general, the popular guidance is to create self-organizing cross-functional teams that can work in independent silos to build, test, deploy, and maintain their own areas of responsibility. This is good advice.
But the advice starts to break down once you reach any boundaries that need to be tested between teams. Without anyone formally in charge of QA, shared test suites and end-to-end tests will decay. Standards will stop being enforced. Coverage will decrease. Quality will decrease. Entropy is inevitable.
I've seen it happen. Twice.
Getting rid of all your QA engineers is a mistake.
Top comments (17)
I totally agree. The point of adding lots of unit tests and some integration tests should not be to remove QA engineers but to empower them to focus better on where their skills are most helpful.
I've definitely _not _noticed this trend in the places I've worked. Some places will choose to cut down on QA first, if they're running into financial troubles, but it usually comes back to bite them and hastens their demise.
I can’t say the trend reflects any of my observations with the industry, but I wouldn’t be surprised if certain leaders took this action. You’ve done a good job detailing why dedicated QA roles are beneficial, thanks for sharing!
Thank you for reading!
I also agree with you @thawkin3 and let me explain why. After 2 decades of working as a developer I decided to build and lead a SDET team. The only reason I jumped to this role was that the company's testing strategy included the following release exit criteria:
Implemented by Dev teams:
Implemented by SDET team:
In general the philosophy is to have fully automated all the tests so that everything is executed through CI/CD pipelines ensuring that no regressions have broken builds from MR to MR. I know, there are a lot of challenges to implement everything from scratch in a greenfield project and also bring the DevOps and Automation mentality to all teams. At the end though, the quality of the product will be outstanding.
Absolutely! I love having a good QA engineer around that can poke holes in my feature even after I've written a bunch of tests and done my own due diligence.
Having a second pair of eyes is usually helpful, and someone could argue that the second pair of eyes could be another software engineer, but even then that second software engineer is still under the same pressure to not spend too much time on this or be as thorough as they could be if this were their only responsibility.
I agree with that reasoning to an extent, but I come to the same conclusion as in my article by following that line of thinking. Everyone must own security, yes. So developers should be aware of basic security risks, have a working knowledge of things like the OWASP top ten, know how to prevent XSS attacks, know how to prevent SQL injection, etc.
There is still a ton of value in having dedicated Security Engineers on top of that. They act as subject matter experts, have deep expertise in the area, can audit various areas of the app for security issues that developers have missed, and help train and level up other engineers to be better at handling security properly. Effective QA engineers do the same thing.
Agreed, QA should not rely primarily on manual testing. I think we may have had different experiences with QA in our various companies we've worked at.
The most effective QA engineers (and organization setup in general) I've seen have been embedded in each engineering team, aren't required to review every MR before an MR is merged, are technical (think SDET) rather than just manual testers, have deep expertise in writing and maintaining end-to-end test suites, and are great at occasional exploratory testing. Those are the kinds of QA engineers I love to have around.
What is MR?
Merge request. For those us of who use GitLab instead of GitHub that calls them pull requests. 😉
This really isn't true at all. A good engineer should have a combination of both mindsets. If you don't, you will produce sloppy work. I have always tried to break the stuff I build if it is intended for the consumption of others, and I cannot stand it when I'm asked to review stuff that has obvious defects that take 2 minutes to find - it speaks to a total lack of care about what you are doing, or a lack of knowledge of how things should work. TBH, most QA teams I've worked with don't find half the stuff I find and I sometimes wonder why they're there.
Nobody trained me to work this way, it just seems the obvious way to work. There's no context-switching involved.
Thanks for your thoughtful comment! I'm agreed with most of what you've said.
Just to be clear, I'm not advocating for sloppy work, lack of testing by developers, or "throwing things over the wall" for QA to go test. That kind of working strategy is inefficient and leads to re-work. So we're 100% agreed that developers need to have a quality mindset, test their own code, look for bugs, look for edge cases, and shouldn't submit sloppy MRs with obvious errors.
It sounds like maybe you've had some poor experiences with bad developers and bad QA teams in the past, which is unfortunate. These comments are interesting, because we're all speaking from our own experiences, which I'm sure vary greatly from person to person. I think it's important though to differentiate between the two ideas of "the QA engineers I've worked with have not been very useful" vs. "QA engineering roles in general are not very useful."
The most effective QA engineers (and organization setup in general) I've seen have been embedded in each engineering team, aren't required to review every MR before an MR is merged, are technical (think SDET) rather than just manual testers, have deep expertise in writing and maintaining end-to-end test suites, and are great at occasional exploratory testing. Those are the kinds of QA engineers I love to have around.
There's nothing wrong with manual testing. I rarely use automated testing at all. If you're editing code, you shouldn't be - unless you understand that code and the ramifications of changing it. The building of that understanding should not be skimped on by relying on test suites that may or may not be correct or up to date.
Automated testing encourages the siloisation of knowledge and understanding, which - to my mind - can never be a good thing. The more deeply a developer knows and understands a project, the better they'll be at working on it. Also, they'll gain a better sense of involvement and attachment to the project as a whole.
Seems likely that we won't agree here. 🙂
I tend to favor the opposite viewpoint, which is that as a company's codebase grows, a single developer cannot and should not be expected to have a deep understanding of everything in the codebase. Yes, do your due diligence. Yes, develop a solid mental model of what you're working on. But when working on code written by thousands of developers over decades of time, it's often hard to know if there's a "gotcha" lurking in the shadows waiting to break when you change something that you swore was unrelated.
I'm always grateful when an automated test catches something that I didn't.
Short term benefit, long term huge mistake!
Oh my goodness, I thought it was just me, QA testers are getting rarer, you can't trust me to mark my own homework!
Coming from a python back end web development background, I wonder why QAs should have expertise in
Pytest. I always thought of it as a framework to build unit tests, and that should be left to the developers, rather than taken over by QA.QA and software development are distinct skill sets, and these are not easily transferable in either direction.
That's a good callout. You're right, Pytest isn't really in the same category as Selenium, Cypress, or Playwright.
Pytest is just a testing framework, so technically you could use it for tests at any level (unit, integration, or e2e). In one of my engineering organizations we used Pytest for a Python e2e test suite, but maybe we were the odd ones out!