Why QA Can’t Improve the Quality of Your Application

Who I am: 👩‍💻I'm a female software engineer in test, sports lover, part-time digital nomad. I'm glad to be part of @Women Buidl, to support female creators and engineers in tech industry.

Let’s say your team is developing an application. You want someone to test it before delivering it to users, and you believe having a Quality Assurance (QA) team in place will make it a perfect app with zero bugs. In this post, I’ll cover what QA can do, and unpack why they can’t improve the quality of an application alone (don’t worry, I’ll explain).

As a software engineer in test, I collaborate with other developers, product managers (PMs), and UX/UI to define manual testing plans, write backend and UI integration tests, and build and maintain test frameworks and tools. Our core focus is to ensure that we deliver the highest-quality products to our customers.

Let’s See an Example

For the purpose of this example, let’s say we see the beta app as a perfect product with a quality score of 100. When developers hand the app over to QA, they start their job, which is looking for bugs. The observed quality score will drop from 100 to 70 due to the bugs they find and developers will come and fix them. However, there will probably be some issues that won’t get fixed in this initial release. Why? Of each remaining bug, developers might say:

• “This is taking too long!”
• “It’s a tiny, trivial issue, users won’t mind that.”
• “We will need to rewrite everything...”

After fixes on round two, the app now has a quality score of 90, so QA will start looking for bugs again. Of course, they usually find new issues, so the score drops from 90 to 80. After a few cycles like this, when the app finally goes to production, we manage to have a quality score of 90, which isn’t bad! Now you easily see what QA does — in this case, drops your app’s quality score from 100 to 90!

How About Just Cutting QA?

To help explain my point, I’m going to tell a story. Have you heard about the Scandinavian ship Vasa? It launched in 1628 and was considered the world’s most powerful warship, but after only 20 minutes of sailing, it sank to the bottom of Stockholm Harbor.

Why did that happen? Well, the ship was unstable, with too much weight in the upper structure of the hull, and its narrow profile made it difficult to compensate for the instability. Actually, before the ship’s launch, there was what was known as a lurch test: 30 men ran side-to-side along the deck to get the ship rolling, exactly what Captain Jack Sparrow did in Pirates of the Caribbean to flip the Black Pearl.

However, the test was abandoned after three trips, because Vasa was lurching way too far and about to capsize. Vasa was still ordered to sea, even though it never passed any tests before launching!

Building an application is just like building a boat. If we cut QA out of the picture, we would believe our boat has a quality score of 100, solid as stone! We would be confident that it can carry 64 cannons, withstand huge waves, and weather a strong storm. If we set out to sail 500 miles in the ocean, it turns out the boat would actually sink after 50 miles, due to hidden holes.

Without knowing our limits, we make unrealistic plans and even wrong strategies, such as landing too early in a new market or carrying too many key features with an unstable release to all user groups instead of selecting some non-key user groups.

What if we are aware of the issues that have already been fixed and the imperfections (issues we choose not to fix at the moment) of the app? What if we knew how far the boat could go without sinking, which rocks to avoid, and how many cannons it can carry? Would it be a different story?

If Not QA, Then Who?

Who is going to be responsible for the quality of your application? Let’s go back to the boat example and find out who played a role in our boat’s quality. The easy answer is it’s a team effort. PM designs the specification of our boat with client demands: the largest warship in the world with the capacity to carry 64 bronze cannons. There should be massive decorations and sculptures on the boat to show the king’s power, but even these additions will make the boat heavier than it can handle.

UI/UX designs the amazing look of the boat and developers build it. QA, like we mentioned before, looks for holes that exist in the boat, reports to developers, and then developers fix those holes. As you can see, there is never a key person responsible for success, but a whole team.

The Truth Behind the Quality Score

The truth is, there are some bugs that are never found by QA, which we will call X. The real quality score, therefore, is 90-X. X stands for the hidden holes in your product. Our goal is to reduce X through tests, so the smaller X is, the greater your app quality will be. That’s why it’s important to not just own a QA team but to work wisely with them to minimize the mysterious X.

That sounds easy, but how is it done in practice? Go through the whole process and devote time to every single step. For instance, I have worked in a team where we try to improve each step of the development life cycle. PM prioritizes features from customer requests, designers create the balance between function and aesthetics, developers write testable code and handle legacy structure, and QA gets involved when appropriate.

How to Involve QA Wisely

1. Start Earlier

QA should be involved at the very beginning of the project to test each part of the product and review the requirements often. That way, the team can fix bugs in an early stage, and make sure the whole team is always aligned with the specifications.

2. Automate the Boring Work

Develop automated tests instead of doing manual testing forever, because human intelligence should be used for thinking and creating, not for repeating. In order to do so, the team should upgrade their QA tester to QA automation engineers.