Why are there so many quality engineering misconceptions to explore and challenge?

I've just reviewed Philippa Jenning's lesson for the Software Quality Engineering Certificate (SQEC).

As is stands, Philippa describes 18 common quality engineering misconceptions and what to do about them. It's a powerful piece with lots of thoughtful reflections and advice. Nice one, Philippa! 🏆

I'll take a few that stood out, yet they're all helpful.

Misconception 1: “Quality Engineers do Quality Engineering, like testers do testing.”
This frames QE as a specialist service lane, where one person “does the quality work” and everyone else hands stories over for sign‑off. It quietly creates bottlenecks, disconnects developers and product from critical quality thinking, and encourages leaders to “fix” delays by hiring more QEs instead of changing how the team works. To challenge it, start mapping team quality behaviours, redraw workflows to show shared loops instead of handoffs, and gently ask “What’s the entire team’s part in this quality decision?” whenever someone says “The Quality Engineer will take care of that”. Watch for QE-only columns on boards, requests for “QE sign‑off,” and phrases like “We’ll hand this to the Quality Engineer later”.
​
Misconception 2: “Quality Engineering is just a new name for testing.”
Simply renaming testers to “Quality Engineers” can feel like modernisation while leaving expectations, access, and practices exactly the same. That keeps QE stuck at the end of the process, focused on post‑build testing, and makes it easy for leaders to conclude “QE didn’t work” when nothing about the wider quality system actually changed. Challenge this by asking what new quality decisions teams can make now, and by showing how strategy, risk modelling, observability, and system learning expand QE far beyond “just testing”. Watch for role renames without practice change, QEs only seeing software at the end, and no shared understanding of what “Quality Engineer” actually means in your context.
​
Misconception 3: “Automation = quality.”
High automation coverage feels modern and efficient, so it’s tempting to assume it equals confidence in quality. In reality, automation can only assert what teams already know to look for, and will happily confirm all the “known knowns” while missing the messy, emergent risks that cause the most painful incidents. A better stance treats automation as supporting infrastructure: good for fast feedback on known behaviours, but always combined with exploration, modelling, analysis, and collaboration. Watch for “Just add another automated test,” pipelines treated as proof of quality, and teams labelling automation gaps as “edge cases” instead of signals that deeper exploration is needed.
​
These ideas (and more) are part of Module 5: The good, the bad, and the better of Quality Engineering in the Software Quality Engineering Certificate, available soon on SQEC via Ministry of Testing.

In the meantime, reply with a common quality engineering misconception. What good intention does it come from and what is the partial truth about the misconception? How do you spot and challenge it?