Table Of Contents
“Quality is never an accident; it is always the result of intelligent effort. There must be the will to produce a superior thing” – John Ruskin
Something goes wrong. A defect makes it to production. A client finds a bug. A release does not go as planned. And almost immediately, someone asks the same tired question: “Where was QA?”
Not “where were the requirements?”. Not “why were the unit tests missing?”. Not “why did we rush this out the door with known issues?”. Just “where was QA?”.
I have seen this play out more times than I can count, and it never stops frustrating me. QA did not promise the feature. QA did not design it. QA did not build it. QA read whatever requirements existed (if any), tested the product, found that some things were fine and some were not, raised defects, and reported their findings. That is the job.
And then people lose their minds.
The Insinuation Nobody Talks About
When someone says “QA is responsible for quality,” there is a sneaky insinuation buried in that statement. It suggests QA will also fix it. That is not how any of this works.
QA identifies the problems. Developers fix the code. The business decides what ships and what does not. Everyone has a role, and quality is the sum of all those roles done well. It is not the output of one team scrambling at the finish line.
Somewhere along the way, our industry decided that the people who find the problems are the ones who own them. That is like blaming the smoke alarm for the fire.
So Who Actually Owns Quality?
Everyone. I mean that literally. Every single person who touches the product.
It starts before a line of code is written. When sales teams overpromise or set unrealistic timelines, quality is already compromised. When contracts are signed without a clear understanding of scope, you have set the product up to fail before the project even kicks off. Nobody blames sales when a feature is buggy, but maybe we should be asking better questions about how the expectations were set in the first place.
Project managers own quality when they plan timelines and manage scope. If the schedule does not allow for proper testing, that is a planning failure. Not a QA failure.
Product owners (including the Agile team) own quality when they write requirements and acceptance criteria. Vague stories, one-liners, shifting goalposts, and unclear expectations all produce defects downstream. When QA is testing against half-written requirements that changed mid-sprint, the issues they find are not a testing failure. They are a requirements failure. Be exact. Be explicit.
Developers absolutely own quality. This means doing the right thing, not just ticking a box. Writing meaningful unit tests. Testing for failure so that a defect, once fixed, never comes back again. Not half-arsing a feature or a bug fix because the deadline is looming. Manage it properly. If you do not, it will come back, it will cost more, and QA may have to constantly retest it in future when they could be spending that time on far more valuable work.
And yes, QA owns quality too. But QA’s role is to be the gate where quality is understood. They assess risk, confirm that critical paths work, identify what does not, and report their findings. The team and the business then decide what needs to be fixed before release. That decision is not QA’s alone to make. They just told you what they found. What happens with that information is on everyone.
What Happens When Everyone Owns Their Piece
When quality is genuinely shared, it changes what is possible.
Requirements get reviewed and challenged before development starts. Not necessarily a formal ceremony, but someone is asking the right questions. Are the acceptance criteria clear? Are the edge cases considered? What risk are we introducing? Can this actually be tested? These questions get answered before anyone opens an IDE.
Developers write meaningful unit tests that are used during and after development. This should not be optional extra work. It is the work. When combined with CI/CD pipelines, even basic automation gives a level of quality confidence before QA ever touches the build.
By the time QA receives the product, the foundation is already solid. QA can then confirm positive and negative testing paths, verify that risk-based needs have been met, and ensure critical paths hold up under scrutiny.
And here is where something valuable happens. When QA is not buried under a mountain of obvious defects that should have been caught upstream prior to handover, they have time. Time to go looking through the deep, dark recesses of the product for issues quietly waiting to bite the business.
This is where experienced testers truly shine. Using exploratory techniques and creative thinking, they probe the product in ways that scripted tests and automation simply cannot replicate. They think about the things nobody else thought about. They find the issues that lose clients, damage reputations, or worse. This is QA securing the future of the product and, by extension, the future of the business.
Quality reporting becomes a meaningful conversation about risk and readiness, not paperwork. Not a tick-box exercise to satisfy a process.
That is what good looks like. Everyone doing their part, so QA can do theirs.
What Happens When They Don’t
Here is the uncomfortable truth. QA rarely gets enough time to do their job properly. Sometimes developers do not either. Everyone is squeezed. But when time runs out, it is testing that gets cut first. The feature has to ship. The deadline is firm. The client is waiting.
This is where the Dev vs QA arguments arise. They shouldn’t. QA is just doing the job they were hired for. What QA finds should never be seen as personal. But defences go up and people will point fingers.
And then the gambling begins. Various parties just want it out the door. QA raises concerns that get dismissed. Others reason or twist words just to appease and get out of the meeting quickly. Risk gets accepted without genuine discussion. Questions go unanswered. Assessments are not trusted. And when it inevitably goes wrong in production, everyone turns around and asks that same question again.
QA was right there. Raising defects. Flagging risk. Waving red flags. The business chose not to listen.
If QA is spending all their time retesting broken basics or on defects closed without a proper fix, the business is wasting its most valuable quality resource on problems that should have been solved long before QA got involved.
That is not a quality assurance problem. That is a culture problem.
Don’t treat QA as a tick box prior to release, it’s too late. It’s everyone’s responsibility to do the right thing before QA do their part, whether it be Waterfall or Agile. Not doing the right thing breaks both. One just does it much faster.
The Take
Quality is not a phase. It is not a department. It is not something you bolt on at the end and hope for the best.
It is a mindset that starts at the very first conversation and runs through every decision until the product reaches the people who depend on it. Every individual in the delivery chain is responsible for quality. From sale to requirements to code to handover, every step should be done with care and intent. Not rushed. Not half-arsed.
QA did not promise anything. QA did not design or build it. QA just told you what they found.
A Note on Context
Every business and every project is different. What works in one place won’t work in another, and that’s the point.
Nothing here is meant to be a step-by-step prescription. It’s guidance, drawn from my own experiences, and deliberately kept general to avoid pointing fingers anywhere.
Take what’s useful, ignore what isn’t, and adapt it to your own context. Or as Joe Colantonio always says: “Test everything and keep the good.”
