What Quality Assurance Is Not
quality , process , practices , qa
A few years ago, during a particularly tense retrospective, someone said:
“Wasn’t this bug supposed to be caught by QA?”
The room went quiet.
It wasn’t an open accusation. But in that sentence there was a clear boundary: quality had an owner. And it wasn’t “the team”.
In that moment, I realized the problem wasn’t the bug. It was our definition of quality.
We often talk about tools, pipelines, automation. But many team tensions don’t come from missing technology - they come from cultural misunderstandings.
Before defining what quality is, it might be more useful to clarify what it is not.
Quality Is Not a Department
When quality becomes someone’s job, it stops being everyone’s responsibility.
I build. You check.
I deliver. You validate.
It’s a convenient separation - and a fragile one.
Control creates defensiveness. Defensiveness creates distance.
Movements like DevOps tried to break down these silos, but the real issue is cultural. If quality is perceived as a final phase, it becomes a filter instead of a property of the system.
Quality is not a checkpoint.
It is the result of how a team collaborates.
If it belongs to a few, it doesn’t truly belong to anyone.
This is not about redefining QA as a more technical role.
It’s about questioning the idea that quality can belong to a role at all.
Quality Is Not a Direction
Over the years we’ve learned to talk about Shift Left and Shift Right.
Move testing earlier. Observe better after release.
These approaches are useful, but they become limiting when treated as positioning strategies. Quality is not something you place along a timeline.
It’s not “before” or “after.”
It’s a continuous tension.
It’s attention during design.
Care during implementation.
Observation in production.
Learning when things go wrong.
You don’t move quality around.
You cultivate it.
Quality Is Not Blame
When something breaks, the first reaction says a lot about a team’s culture.
If the first question is “Who did this?”, quality turns into fear.
And fear produces silence.
An error is not a personal label. It’s information about the system.
When people are afraid of consequences, they hide problems.
And what is hidden cannot improve.
Quality grows where transparency exists.
It fades where shame dominates.
Quality Is Not Slowness
Another persistent myth: quality requires slowing down.
More approvals.
More manual checks.
More gates.
At first, it feels like caution. Over time, it becomes friction.
When the process is experienced as an obstacle, people will eventually try to bypass it. And at that point, quality turns into a ritual rather than a value.
Real quality doesn’t block flow.
It makes it sustainable.
Fast feedback, smart automation, small and frequent releases - these are not shortcuts. They are the conditions for continuous improvement.
Bureaucracy creates the illusion of control.
Flow creates learning.
Quality Is Not Perfectionism
Confusing quality with perfection is a subtle mistake.
Perfectionism is rooted in the fear of making mistakes.
Quality is rooted in the ability to respond to them.
A complex system will never be flawless.
A mature team does not deny errors - it integrates them into its growth process.
Quality is not the absence of problems.
It is the ability to face them without drama.
In the End
Looking back at that retrospective, the sentence about QA wasn’t really about a missing test. It was about a boundary.
Quality is not a boundary between those who build and those who check.
It is not a phase.
It is not punishment.
It is not bureaucracy.
It is the reflection of a team’s culture.
Tools help. Practices matter.
But without shared responsibility, they are just mechanisms.
Quality cannot be installed in a pipeline.
It is built every day, in the way we choose to work together.