Common Quality Assurance Myths

The Machine turns fiction into fact

We’ve established that software quality assurance (QA) is more than just testing, and good QA is essential to tracking the health of your software development project, but there are a bunch of different myths surrounding QA that gives testers a bad rap, or prevent people from treating the discipline seriously.

So let’s take a look at a few of them, and shed some light on this exceptionally important aspect of software development, that is often the first on the chopping block.

Defects are bad, so if we’re finding lots of defects our software must be bad...

Software is complicated, and defects are inevitable. Yes, inevitable! The mere existence of defects doesn’t speak negatively to the quality of your software, it simply means the software isn’t ready for prime-time yet. In fact, if you made a piece of software with no apparent defects, it isn’t because you’re some kind of development genius, rather you simply haven’t looked hard enough to find them.

Every defect found is a defect that can be fixed; an opportunity to improve the final result for your end-users. So, if you spot a defect, take heart! Take the time to investigate it, log it in your issue tracking tool, and get it fixed. Well done! You just made your software better.

QA is too expensive, and we’re too small to worry about it.

While it’s true that a highly rigorous QA procedure is time-consuming, requires professional management, and changes to your underlying development methodology, all projects—no matter their size—will benefit from QA.

There are a huge number of tiny ways QA practices can be built into small projects without breaking the bank, and each one will improve the quality of your software. A template for logging issues that captures the key information you need to fix them, building time for fixing defects and verifying they’ve been fixed into your QA plan, and the production and maintenance of a risk register are just a few small ways QA can be implemented by your existing personnel.

But, you should consider employing or contracting a testing professional! Ultimately, you’re paying for quality and confidence - the better the tester, the more they will cost! They can advise on how best to spend your budget to get the most out of the time they have with your team.

They’re not just finding defects, they are helping improve all facets of the project - highlighting risks, reviewing processes, providing advice, and ensuring consistency.

It’s cheaper to do testing at the end of the project.

The earlier you find a defect - the more cheaper it is to fix. For example, if you find a defect in design documentation (say a < sign was used instead of a >), it doesn’t cost much to edit the document to fix the problem. How much more would the defect cost to fix if it had been implemented as-written, found in testing, and investigated by your developers before being fixed? Add to that the cost of reputation damage if the issue was found after your software was released, and you’re talking about an exponential increase.

The simple solution here is to include QA in your project early, and have people testing and verifying your software before it’s even committed to code. Sure, there’s cost involved, but the amount you’ll save in reducing defect load over time is huge.

I’m a developer, and the tester on my team is trying to make me look bad!

Not at all, testers are here to help! By finding the issues early, they help the team ensure that the final product is of a higher quality, which in fact makes you look good when it’s released. As we learned above, defects are an inevitability in software development. Testers are your safety net, to make your excellent work even better!

How defects are described or highlighted in discussion can make a difference to how they’re perceived. It’s important for anyone in a QA role to treat a defect for what it is: A necessary part of the process of software development, a task to be resolved. It helps nobody when people are blamed for the existence of defects, better to spend that time and energy on getting them fixed moving forward with the project.

Eugh, QA people are just nit-pickers

Testers are generally very good at finding issues that would otherwise be overlooked - this is an advantage, as their unique perspective and independence from the code makes them capable of finding a large range of defects. A better way to think about it is as “Quality Assistance” - they’re helping the team improve to produce the best work they can. This can be through logging defects (directly improving the software itself), providing advice about process improvements, and highlighting project risks. Keep in mind, their job is to pinpoint discrepancies between the designs and the implementation - they’re not raising defects to be difficult, they’re raising them because that’s how they contribute to making your project the best it can be.

If you have experienced toxic behaviours from people in QA roles in the past, this speaks to a lack of training and experience. QA isn't about poking holes in your hard work, it's about making your work the best it can be. Experienced QA personnel are taught that defects are just part of the cost of making software, and to never make it personal.

There isn’t a career for me in QA!

QA is its own discipline. There are a number of different areas that can be focused upon - automation testing, team management, or usability, with a number of different certifications that can be trained for and attained.

It’s a highly sought-after skillset, and is adaptable to a wide variety of fields. It has a low bar for entry, and can give you access to some incredible opportunities for moving up or sideways within companies, and even development sectors.

Additionally, QA encourages an understanding of all of the different aspects of a project, giving testers a unique and valuable perspective on it as a whole.  Anyone with an eye for detail and excellent communication skills can develop a highly rewarding career in QA.

Remember, QA is here to make everyone look good! Its purpose is to highlight the inevitable and understandable flaws in a project, to help it become the best it can be.