Quality assurance stories and horror go hand-in-hand. Horror has been a source of cautionary tales for generations. Learn from the terrible mistakes of others, and use them as a guide for what not to do.
And that’s what we’ll be doing today. Nothing about morality or money (directly), though; instead, we’re gathering around the metaphorical fire to share horror stories about quality assurance failures — horrible things that could have been prevented if only the developers had done a bit more double-checking.
Proceed at your own risk!
What is QA and why does it matter?
Before we dig into the three horrific examples, let’s take a moment to review.
It’s easy to throw quality assurance around during the dev cycle as something vague. We’ll go back and check on this later, you might hear.
Automated solutions, for example, can help developers QA test at any time, which is great, but to set those systems up or do any other kind of QA, you need to first define what QA is and what it means to you.
What QA means
QA stands for quality assurance. It’s shorthand for a set of procedures that help in deciding whether your program or application meets its necessary requirements.
What requirements are those? Well, that depends. Your developers or business managers (or both) might set out guidelines and goals, or you may be using the numbers set out by the ISO 9000 family of Quality Management. The 90003 series lays out specific standards for software development, which includes applications.
But that’s a large-scale set of standards that might be a little bit lofty for your teams’ software goals. A few testable parameters that you can review that hit a little closer to home include:
Battery drain
If your app vampirically saps up too much battery power, then it will undoubtedly frustrate users and drive down review scores. Constantly charging is a hassle, and users prefer to do it as little as possible. If they notice a difference after they download your app, then you won’t last long on their machine.
Poor user experience
Users want simplicity and a familiar navigation experience. Testing should ensure that they can accomplish everything they need to within the app in a reasonable amount of time.
Notification response
Receiving too few notifications means your users have no prompts to engage with you. But too many means you annoy your users. Those users uninstall, which cuts off your revenue. Worse, they must leave a negative review.
What makes QA so important?
QA is all about avoiding adoption failure, which is bad for business. No app can become successful if nobody makes use of it.
Worse still, people with very negative experiences can leave bad reviews. Most users don’t trust apps with an overall rating of fewer than four stars. A few bad reviews can tank the average and damage your relationships with future customers before they even form.
QA testing is all about ensuring that your customers have a positive experience with your application, whether they’re first-time downloaders or have used your systems for years.
Three true quality assurance stories: What can go wrong?
Remember that everything that can go wrong will go wrong, so QA needs to be ready to test for everything you can think of — and a few things that you can’t.
Here are but a few chilling quality assurance stories and from companies whose names you may know — poor souls who tested too little and too late…
Discord
Discord is a popular online chat application for both desktop and mobile users. Originally developed for gamers, it became a go-to communication service during the pandemic, with more than 150 million users.
In August 2022, Discord switched its Android app from being a natively-written program to using React Native, the same UI software framework that it uses for its iOS applications.
Discord touted the update as a way to increase performance, lower developer costs with a single codebase, and bring iOS-only features to Android, but unfortunately, a failure to properly QA test meant it had many problems.
Users reported errors in text display, issues with image compression, significant and disruptive battery drainage, and even some, albeit unconfirmed, temperature spikes.
This update was a clear business move meant to reduce developer costs — one codebase costs less to maintain than two, after all — but because of those goals, it didn’t receive the attention and QA it deserved. As of this writing, the problems continue, damaging much of the goodwill of Discord’s Android market.
Facebook (now Meta)
Even tech giants aren’t immune to failures in QA testing. Facebook (nowadays known as Meta) has become infamous for its multiple security breaches over the years, exposing user data that includes phone numbers, email addresses, and user profiles on an unprecedented scale.
Though Facebook rectified the issue in 2019, it faces some accusations of knowingly letting the issue pass by until it became too large to cause problems.
Meta’s problems have grown worse still over the years. What other tech companies with such an enormous influence make mistakes so massive that they end up being called before the United States Congress?
A company of Meta’s size, with the personal information of its billions of users it holds, makes for a tempting target. Experience tells us that Meta is aware of this, and Meta certainly has the resources to perform all the testing in the world.
Constant and cutting-edge security QA is vital for a website in Meta’s position. Time will tell if Meta shifts its direction and grows from its past mistakes or use their monopoly to maintain their position.
Amazon Web Services (AWS)
Simple mistakes that slip through the cracks can cost millions. A routine debugging procedure within Amazon’s systems lost companies a combined $150 million. A single mistyped command by one programmer brought the whole system down.
On the surface, this massive financial loss looks like human error rather than a QA problem, but applying out-of-the-box QA testing could have recognized the potential catastrophe and let programmers implement a check. One extra step that highlighted the potential scope of the change and requested confirmation before a push to live could have made all the difference.
Amazon and other FAANG companies might hire the best and assume that those checks aren’t necessary, but even the best of the best can make mistakes, and when they do, the program has to be ready to catch them.
Learning from terrifying quality assurance stories
Heed these warnings, lest you meet the same fate. It’s important to understand why QA is important, but it’s just as important to know what kind of testing you need to do.
Should you use a simulator to test the program on its own or an emulator to test the way it interacts with hardware? Or can you skip the uncertainty of emulators and test on real devices? Is the general user experience more important than accessibility? Do you have the manpower to perform manual testing, or will no-code automated testing pay dividends in the future?
The unfortunate reality is that many app developers don’t have the force, budget, or motivation to do as much quality assurance testing as they should, and they risk tripping into the same pitfalls we discuss above. Fortunately, there are plenty of solutions out there to make testing easier.
These solutions give developers the tools they need to advocate for proper QA testing on a smaller budget, which makes business managers happy. And then, developers don’t have to worry about correcting problems later.
Fixing a small problem that hasn’t caused issues is much, much better than fixing a big problem that’s caused a catastrophe. Less PR damage equals less panic and happier developers who can take pride in a job well done.
As they say, an ounce of prevention is worth a pound of cure. This Halloween, consider more QA testing as a way to dodge the scares you want to avoid while you look for spooky thrills out in the night. We’re always happy to help here at Sofy!
Disclaimer: The views and opinions expressed above are those of the contributor and do not necessarily represent or reflect the official beliefs or positions of Sofy.