Common Misconceptions About Quality Engineering

A practical look at the biggest myths about quality engineering and what they mean for your team.

Quality Engineering is gaining traction within the software industry, but there's a risk that we will fall into the traps of past fads and never emerge from the trough of disillusionment.

As with any new idea, misconceptions and myths emerge as people try to figure out how to apply it to their context and extract the value from adopting it. While this is not an exhaustive list, I see some pitfalls around Quality Engineering that we should watch so that QE doesn't become another fad.

Myth 1: All you need to do is rename your Testers to Quality Engineers

The thinking is that this will quickly fix their manual testing bottleneck, and by making them quality engineers, they'll get all the automation they want while improving the quality of their products. However, the reality is likely that people will continue as they are, just with a new title.

Myth 2: Building quality in means no more manual testing

Quality Engineering is all about building quality into the system, so people assume you no longer need to inspect for quality (testing).

You can only build the quality you know about. But every time the system changes or interacts with a third party outside your control, uncertain system behaviour could be introduced.

Therefore, you will always have some form of inspecting for behaviour. However, now that you better understand how quality can be lost within your system, you can target that inspection more accurately, leverage other inspection techniques, and minimise the amount you need to do.

For more, see The Testing Unknown-unknowns and Can We Automate All the Things? Exploring the Limits of Testing in Software Systems to learn more about uncertainty in system behaviour and how change can affect it. The six layers of testing also detail different strategies for inspecting for quality.

Myth 3: Quality Engineering Is a Developer's Job

If Quality Engineering isn't about testers or testing (see above), then it must be a software engineering task. It has the word engineering in it, and all this talk about building quality in over inspecting for quality can only be done by people doing the building. That's a "technical" thing done by developers.

Going back to my second post on Quality Engineering Newsletter, What is quality engineering?

If quality engineering is the study of quality, what is a quality engineer?

First, what is engineering from Wikipedia

Engineering is the practice of using natural science, mathematics, and the scientific method to solve problems, increase efficiency and productivity, and improve systems.

It goes on

The term engineering is derived from the Latin ingenium, meaning "cleverness" and ingeniare, meaning "to contrive, devise"

Considering these two views of engineering, a quality engineer works to solve quality problems and inefficiencies to improve software systems.

Building quality in is about solving quality problems and inefficiencies. How a quality engineer decides to do this is up to them using the skills and abilities they possess. They may do this from a technical perspective by writing code, from a facilitation perspective by helping the team define quality, and even by helping the team collaborate more effectively. Ultimately, it's about improving the software system by making it healthier to achieve more of the outcomes we want and less of the ones we don't. Developers can do this, but so can testers, delivery managers, agile coaches and even dedicated people who may or may not be called quality engineers.

Myths 1 to 3 cover common misconceptions about Quality Engineering. In the next section, we’ll explore deeper issues around inspection, resilience, and culture shifts—and how organisations can truly unlock the potential of Quality Engineering.