“QAs break software”

One of the most common misconceptions is that QAs break software. This couldn’t be further from the truth. All that has happened here is the QA has made the product do something unexpected, and this caused the software to break or crash. There can be any number of reasons that the software has ended up in this undesired state. Unfortunately, this is often heard as blame by the developer, and you hear the famous words: “it works on my machine”.

QAs find places through user paths that are broken and therefore produce bug reports from this. However, bugs aren’t always about something that is broken, they can be something that isn’t intuitive to the user, something that doesn’t work as expected, or even a difference in interpretation of the functional requirements.

When I started in this career there always seemed to be a divide between QA and developers. “QAs create more work for us,” developers would say. In this kind of blame culture, QAs are not only maligned when they don’t find issues/bugs but also resented for issues/bugs they do find, which expose much deeper problems within the software. Thankfully, it doesn’t have to be like this — we can work in harmony complementing each others’ skills.

“QAs are not technical”

This really is an odd one. I, myself, do not code, but this does not make me non-technical. My skills are about understanding the product we are building, having an in-depth knowledge of the problem we are trying to breach, all whilst keeping the user at the center of my thoughts. Being able to code is not the be-all and end-all of being technical.

Being able to communicate your findings about the product, or reproduce that odd error, or find the places where the developer's assumptions don't match the customer expectations before the customer sees the software — these are skills that matter. They're a lot harder to define and much harder to quantify than "can code as well as a developer."

The easiest way to describe it is that the QA complements the developer and vice versa. This allows the developer to focus on their primary activity — coding — and the QA time to focus on exploratory testing.

“QA just consists of writing tests and executing them”

This really couldn’t be further from the truth! When I first started in my career you could have argued that this had some truth to it, particularly if the software development followed waterfall methodology. However, even then, to think that any software could be documented well enough and detailed test cases could be written before the software was done, is complete madness! You would need an army of QAs and the requirements to also be understood and defined well enough to be able to write test cases. And you have to remember that requirements always change, making test cases obsolete, which leads to that army to have to rewrite everything — what a WASTE OF TIME!

“QAs can only test one project at a time”

I find this completely untrue. If anything, working across multiple projects keeps you focused. What I mean by this is that by working on multiple projects that require QA involvement stimulates the mind and keeps the eyes fresh! Working on one single project for a long period of time you become so used to looking at the same thing that you start missing the obvious. By working on multiple projects your mind and eyes don’t have long enough to get too used to looking at the same thing for too long! You are sharp and fresh, allowing the brain to spot bugs quickly and efficiently.

“QA takes place once development is complete”

You could argue that this was the case many years ago when waterfall methodology was the methodology of choice. Thankfully now this isn’t the case due to agile and the realisation that QA being involved early adds more value and having a deeper understanding of the product in question builds empathy with the user. Having early access to designs enables the QA to point out any usability issues that may not have been picked up by designers. Therefore testing is continuous throughout the lifecycle of the project.

“QA are quality gatekeepers”

I myself refer to my role as QA. However, rather than the usual term of Quality Assurance, I prefer the term Quality Assistance. We are not quality gatekeepers, we help assist in ensuring a product/software is of high quality in terms of usability and limited bugs, but we cannot guarantee a bug free product/software. There are any number of decisions that go into deciding whether to release or not, or even whether a bug should be fixed. Our role isn't to stand in front of the source control repository refusing to let anything through that doesn't meet our standards. It's to report on what we see and give an estimation of the risks involved in the possible courses of action.

With quality assistance, we evaluate quality as best we can from incomplete requirements because we're responsive. And by giving customers the best we can as soon as we can, we're allowing them to discover that what they thought they wanted isn't actually what they really needed. We advocate for quality and aim to reduce risk wherever we can, but it's not possible to mitigate all risks, and some things simply can't be predicted.

“QA is easy”

This is a surprisingly widespread belief — and one which software QA themselves naturally aren’t too fond of. As agile has taken root, many software development leaders have come to embrace the notion that everyone’s a QA, which therefore suggests that the job of the dedicated QA has become less critical and less demanding.

That’s hardly the case, though. The best agile software QAs will still play key roles, but those efforts will certainly prove challenging. We as QAs are now not only looking for bugs, we are also making judgements and providing recommendations based on the users needs. A developer, tasked with implementing working features, will only be slowed down if he or she is also expected to be continually stepping back to consider the broader contexts of the features. The same goes for a product manager, but from the opposite end: can they be expected to simultaneously consider the product as a whole, the immediate next steps, the team, and the roadmap while simultaneously being in the thick of unexpected user paths and a plethora of devices and interface paradigms?

“QA is not needed and slows the dev team down”

This really grates on me every time I hear this! When questioned where this thought comes from, often the response is: “we have unit tests.” Yes, unit tests have their purpose but they just test units, they do not test the full end-to-end flow, and they also can’t test the experience.

Another one that I’ve heard before is: “anyone on the team can test it.” Yes, I’m a big advocate of the everyone participating in testing, but this is no replacement for the QA’s mindset of what will happen if I click/tap here, and what will happen if I try and force the software to do things it shouldn’t. The benefits of having skilled QAs is that ability to find gaps in — let’s say — the interpretation of user stories/journeys. Thinking what will happen if I click this button, QA take into account usability and whether the application/software has an intuitive flow through the system.

“QA find bugs which slow us down”

This is just a crazy notion to think this! Problems in software do not just go away — it’s not like if no one finds them, they don’t exist! What happens here is a vicious cycle of the users/customers using buggy/not user-friendly software and then communicate to friends to avoid the product. QA being involved early in a project actually helps improve the product by pointing out issues early and getting the team to think about the product from a user’s point of view.

Conclusion

These misconceptions and myths are brought about through fear from an industry that has a false belief that cramming as much functionality into a product makes the product better — with no thought or care to whether that product is actually understandable or even usable.

This, thankfully, is changing within the industry as we adopt a more user-centric approach and constantly pose the question: is this — and are we — on the right path? Do we need all this functionality? What can we learn from getting a product out early (and therefore have a better understanding of future functionality needs)?

A skilled QA, involved from day one, acting as a user champion, will allow you to answer these questions and iron out fundamental flaws early, before the product — or its flaws — even reaches the user’s hands.