Firing QA Testers Is the Biggest Mistake You’ll Make All Year

Making your developers test their own code is bad business, and you should feel bad for doing it. The last thing a dev wants to do after completing complex work on a feature is test it across a bunch of different platforms, devices, and scenarios. Yet, it’s increasingly expected as organizations cut back on software quality assurance and security teams. Aloof bosses with unreasonable demands, such as Ian Grimm from “Mythic Quest,” are hilarious on TV but not so much fun in the real world.

As quickly and often as modern software changes, it’s easy to fall into wagon ruts: critical paths you follow as your most likely QA testing patternfor a given feature. These wagon ruts lead you to miss obvious alternative cases. You’ll test the main path over and over, but you won’t notice that other paths have broken.

Although software development testing is essential, it doesn’t mean you should make your devs QA testers. They’re more prone to these wagon ruts because it’s hard to judge your own work. (Think about an important proposal or email you’ve written. Without spellcheck or a volunteer reader, would you have noticed your mistakes?) A second set of eyes is a crucial part of the dev cycle workflow, so don’t skimp on quality assurance in software testing.

The indisputable importance of QA testing

An ounce of prevention is worth a pound of cure, and software testing is the prevention. Some bugs are minor, only making your product look less polished. However, delivering bad bugs to your customers can lead to expensive mistakes, such as missed invoices and data loss. Without QA, customers complain more, which can lead to poor customer retention and higher customer acquisition costs.

Testing saves your business time, money, and embarrassment. Delivering bug-laden software erodes trust; customers rightfully judge you when they run across one because it was your job to fix it—not theirs. When you’re not holding up your end of the bargain, it won’t take customers long to move on.

Software testing is an important part of any dev cycle (especially regression testing) to ensure it doesn’t impact the existing functionality. The last thing you want is a new feature breaking everything, overwhelming everyone, and impairing your business. And although there’s a platonic ideal to be found in a strong continuous integration/continuous delivery pipeline and best practice automated test engineering, other priorities usually make such a transition difficult or impossible.

Putting the manual QA burden on the shoulders of devs is a bad move for morale and velocity. QA testing is a detailed and time-intensive task; it’s not the best use of a dev’s time, education, and experience. Devs are coding and user experience experts—they don’t necessarily need to know your business well enough to perform proper tests. That’s your problem to solve.

Good QA testing by a group of trained professionals gives your dev team a safety net. It makes devs more comfortable doing what they do. But that hasn’t stopped some big-name companies from firing QA teams and unceremoniously dumping QA work on their devs.

Critical mistakes to learn from

Microsoft had an entire army of QA testers prior to 2015 that tirelessly tracked bugs and prepared reports to organize things for devs between Windows updates. But Microsoft fired that team during its unification of Windows, Windows Mobile, and Xbox to make customers the testers. (Now you know why Windows’s reputation is flagging.)

Windows customers are now using beta builds for Windows 11, and Microsoft relies on telemetry for QA. The dev team isn’t as strong in QA, so devs are flocking to competitors such as Meta. Imagine making a decision that not only harms your customers but also drives employees to competitors. And companies still aren’t learning: In 2021, Raven Software laid off its QA team.

Expecting too much of devs is unfair. It’s a form of moral injury, according to a Harvard Business Review article. Workers need proper budgets and training toperform the way that they want. Otherwise, you’ll struggle with decreased quality, poor productivity, and low retention rates.

Now you know firing QA teams is a mistake. Luckily, there is a simple fix.

Hire more QA testers to mitigate issues

Quality assurance in software testing is a specialization that doesn’t require the same level of coding genius your devs have. However, it does require you to liaise with other business units and have a general idea of how to translate their demands.

Software development is complicated, and even a highly skilled dev will work on one specific section, completely oblivious to how the rest of the system works. Their expertise lies in coding and developing software solutions; they aren’t experts in software development testing. You don’t know everything happening throughout your own business, so how can you expect that of your devs?

The money you might be trying to save today by overloading your devs will come back to haunt you, whether it’s by losing your best workers to a competitor or driving away customers. The fact is that nobody should be your test cases except your QA team.

Big tech keeps firing its first line of defense against a tidal wave of problems. Don’t make the same mistake: Maintain and support your QA team!

About the author

Chris Cardinal is a founding principal of Synapse studios, a product and software consultancy that solves complex challenges and helps power businesses forward with tech. Chris founded the company with his partner in 2003 and has since grown it into a firm of over 50 employees in downtown Tempe, Arizona. His primary focus is on business development, but he also enjoys helping architect solutions for clients.