DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for Getting Rid of QA Engineers is aΒ Mistake
Tyler Hawkins
Tyler Hawkins

Posted on • Originally published at levelup.gitconnected.com

Getting Rid of QA Engineers is aΒ Mistake

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 (19)

Collapse
 
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄ • Edited on

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.

Collapse
 
moopet profile image
Ben Sinclair

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.

Collapse
 
jfbrennan profile image
Jordan Brennan

Agreed. SWE should write tests for their features because it’s their code and they’re right there and know the requirements. And they should absolutely run through it a couple time to confirm the thing works, but then comes the trade off: use up more engineering time to get mediocre QA (because by now they’re burned out on that feature, not in the QA mental space, and have the next feature haunting them) or let a motivated code-wrecker spend time finding all the little things and - and this is something I’ve come to appreciate - have QA do the debugging as well because throwing unhelpful β€œit’s broken”, β€œthere’s a bug” feedback at the SWE is awful for everyone.

Collapse
 
thawkin3 profile image
Tyler Hawkins • Edited on

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.

Collapse
 
theaccordance profile image
Joe Mainwaring

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!

Collapse
 
thawkin3 profile image
Tyler Hawkins

Thank you for reading!

Collapse
 
mariosk profile image
Marios Karagiannopoulos • Edited on

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:

  1. >80% Unit Testing code coverage (running though CI on every MR)
  2. 95-100% Automated feature/integration tests (running though CI on every MR) with 100% Passed
  3. No P0/P1 Bugs

Implemented by SDET team:

  1. 95-100% Automated Solution tests (Customer facing E2E tests)
  2. 100% Automated Scalability/Longevity tests
  3. Chaos engineering Automated tests
  4. Critical Bugs that affected customer scenarios -> Automated tests running as regressions

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.

Collapse
 
jonrandy profile image
Jon Randy πŸŽ–οΈ • Edited on

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.

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.

Collapse
 
thawkin3 profile image
Tyler Hawkins

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.

TBH, most QA teams I've worked with don't find half the stuff I find and I sometimes wonder why they're there.

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.

Collapse
 
jonrandy profile image
Jon Randy πŸŽ–οΈ

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.

Thread Thread
 
thawkin3 profile image
Tyler Hawkins

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.

Collapse
 
dhruvjoshi9 profile image
Dhruv Joshi

Short term benefit, long term huge mistake!

Collapse
 
adam_cyclones profile image
Adam Crockett

Oh my goodness, I thought it was just me, QA testers are getting rarer, you can't trust me to mark my own homework!

Collapse
 
codingchili profile image
Robin Duda (they/them)

Everyone must own quality, for the same reasons everyone must own security.

If you think it dilutes responsibility, assign quality as a responsibility to a role.

QA increases time to feedback. Developers are encouraged to NOT test their code. This is ineffective and soon you'll be swimming in bug reports AND poor code. QA does a lot of manual testing, ineffective. Test close to the code and inside the developers feedback loop. QA is just more work for everyone with no guaranteed benefits.

Collapse
 
thawkin3 profile image
Tyler Hawkins

Everyone must own quality, for the same reasons everyone must own security.

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.

QA does a lot of manual testing, ineffective.

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.

Collapse
 
kggayo profile image
Keviniano

What is MR?

Thread Thread
 
thawkin3 profile image
Tyler Hawkins

Merge request. For those us of who use GitLab instead of GitHub that calls them pull requests. πŸ˜‰

Collapse
 
ldrscke profile image
Christian Ledermann

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.

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.

Collapse
 
thawkin3 profile image
Tyler Hawkins

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!

16 Libraries You Should Know as a React Developer

Being a modern React developer is not about knowing just React itself. To stay competitive, it is highly recommended to explore the whole ecosystem. This article contains some of the most useful React component libraries to speed up your developer workflow.