The question often arrives near the end of a release:
“Is the product ready?”
And QA is expected to answer.
That can make QA look like the owner of quality—the team that either approves the release or blocks it. But by the time that question is asked, many of the decisions that shaped the product have already been made.
Product decided what to prioritize. Design defined the experience. Development chose how to implement it. Timelines, scope, and technical compromises were negotiated throughout the cycle.
QA can test the result, explain the evidence, and assess the remaining risk. It cannot create quality alone after everyone else has finished making decisions.
I learned that the strongest quality model is not one where QA accepts responsibility for everything. It is one where product, design, development, and QA understand their individual responsibilities and make important decisions together.
Shared accountability does not mean that everyone owns everything.
It means ownership is explicit.
When Quality Arrives Too Late
In a reactive process, QA becomes involved when a feature is considered ready for testing.
At that point, the team may discover that:
- Expected behaviour was never clearly documented.
- Different disciplines interpreted the same requirement differently.
- The feature is difficult to test in the available environment.
- Important user risks were not discussed during design.
- The implementation is technically complete but does not support the intended experience.
- There is not enough time to fix and validate significant problems safely.
QA may report all of this correctly and still appear to be slowing the team down.
The real problem is not that QA found issues. The problem is that the product waited too long to expose uncertainty.
When quality conversations happen only at the end, every finding becomes more expensive. A small misunderstanding can require changes to design, assets, code, test documentation, and release scope. What could have been a short discussion early in the cycle becomes a difficult release decision.
The solution is not to make QA test faster. It is to bring quality into the conversation sooner.
Give Every Feature a Quality Partner
One practice that changed how my team worked was assigning a QA owner to each feature.
The title “owner” did not mean that this person was solely responsible for the feature’s quality. I saw the role as a quality partner for the people designing and building it.
That QA engineer participated in relevant design conversations, sometimes mainly to listen. They learned why the feature existed, how it was expected to behave, which assumptions were being made, and what might be difficult to validate.
They also became responsible for organizing the testing knowledge around that feature:
- What the intended behaviour was.
- How the feature should be tested.
- Which environment and build were required.
- Which risks or dependencies were important.
- What the rest of the QA team needed to know.
This created continuity.
Instead of receiving a finished feature with limited context, QA developed an understanding while the feature was taking shape. Questions could be raised before implementation became expensive to change. The engineer who knew the feature could then share that knowledge with the rest of the team.
The important distinction is that the QA owner did not become a gatekeeper. They became a connection point between design intent, implementation, testing, and release risk.
Participation Does Not Require Controlling the Meeting
QA does not need to lead every design meeting to add value.
Sometimes listening is enough.
When QA hears the original discussion, it becomes easier to recognize when the implemented behaviour differs from the intended behaviour. It also helps testers understand why a decision was made instead of validating only the final ticket.
This matters because requirements are not always fully captured in one place. Important context can live in design conversations, visual references, prototypes, technical constraints, and business priorities.
A QA engineer who joins early can ask questions such as:
- What are we assuming the user already understands?
- What happens if the user does not follow the expected sequence?
- Is the behaviour the same across supported devices?
- How will we know that this feature is ready?
- What information will QA need to reproduce a failure?
- Which parts of the experience are still likely to change?
These are not questions that belong only to testing. They help the entire product team make the feature clearer and more testable.
Agree on What a Useful Bug Looks Like
Shared accountability also changed how we reported defects.
If QA defines a bug-reporting format alone, development may receive information that looks complete to a tester but is not enough to investigate efficiently. If every tester reports issues differently, developers spend time asking for missing details before they can even begin.
We agreed with development on the minimum information a useful defect should contain. Depending on the issue, that included:
- Clear reproduction steps.
- The environment and build where it occurred.
- Expected and observed behaviour.
- An image or video showing the problem.
- Any relevant device or account conditions.
This was not bureaucracy for its own sake. It was a working agreement between the people discovering problems and the people diagnosing and repairing them.
We also announced new defects in a shared channel connected to the team’s tracking process. That gave developers visibility before a bug disappeared into a queue. Someone familiar with the affected area could recognize it, add context, or help route it to the right person.
The result was less time lost between discovery and investigation.
Developers were less likely to respond only that they could not reproduce an issue, because the evidence and conditions were clearer. QA had a better understanding of who could help with particular systems. The defect became a team problem with enough information to act on—not a document thrown from one department to another.
Release Readiness Is a Team Decision
The same principle applies to release approval.
I do not believe QA should make release decisions in isolation. QA should own the quality assessment and be prepared to make a clear recommendation. But the final decision must include product priorities, technical risk, user impact, and business consequences.
In release discussions, I reviewed feature status and risk with product leadership and the development lead. Together, we considered questions such as:
- Is this feature essential to the release?
- What happens to the user if it fails?
- Is the current problem recoverable?
- Can we remove or postpone the feature safely?
- Do we have enough time to fix it and validate the fix?
- Would the fix introduce more uncertainty than the known issue?
- Is the proposed date still realistic?
Sometimes a feature was removed because it was not critical. Sometimes one feature was prioritized over another because the business value was different. Sometimes I had to say that the evidence did not support releasing with a particular failure. At other times, I had to explain that the proposed date no longer allowed enough time for responsible validation.
Those were not QA-versus-product conversations.
They were product-risk conversations.
QA brought testing evidence and user impact. Development brought technical context and repair options. Product brought business priority and release goals. The decision improved because no single discipline pretended to have the complete picture.
What QA Should Own
Saying that QA should not own quality alone does not reduce QA’s responsibility.
It makes that responsibility more precise.
QA should own:
- A clear assessment of product risk.
- The strategy used to gather quality evidence.
- Visibility into what was and was not tested.
- The quality of defect reports and test documentation.
- Communication of important gaps, failures, and assumptions.
- A release recommendation supported by evidence.
QA should be able to explain why a problem matters, who may be affected, how confident the team is, and what remains unknown.
That is real ownership.
What QA should not own alone is every decision that created the product, every ambiguity in its design, every engineering compromise, and every business tradeoff. Asking QA to accept all of that responsibility at the end creates the appearance of accountability without giving QA the authority or context required to carry it.
What the Other Disciplines Own
Shared quality works only when responsibilities remain visible.
Product
Product owns priorities, intended outcomes, scope decisions, and clarity about what value the release is expected to deliver. Product must also participate in deciding whether known risk is acceptable.
Design
Design owns the coherence and usability of the intended experience. That includes responding when testing or observation reveals that users may interpret the experience differently than expected.
Development
Development owns implementation quality, technical design, maintainability, meaningful developer-level testing, and transparent communication about technical risk and constraints.
QA
QA owns risk-focused validation, evidence, investigation, coverage strategy, and communication about release confidence.
These responsibilities overlap by design. Overlap creates collaboration. Confusion appears only when the team assumes that overlap means nobody needs to be explicitly accountable.
The QA Manager’s Role Changes
In this model, the QA Manager is not the person who tries to inspect everything personally or protects the organization by saying no at the end.
The role is to build a system in which quality information moves early enough to influence decisions.
That means creating:
- Clear feature ownership within QA.
- Early participation in design and planning.
- Shared standards for useful defect reporting.
- Stable environments and understandable build flows.
- Release discussions based on evidence and risk.
- Explicit expectations for every discipline.
It also means developing QA engineers who can do more than execute test cases.
A quality partner needs to listen, ask useful questions, understand product intent, investigate failures, communicate with different disciplines, and distinguish a serious user risk from a technically interesting edge case.
The QA Manager creates the conditions for that judgment to develop.
Five Questions That Reveal Whether Quality Is Truly Shared
A team can say “quality is everyone’s responsibility” while still expecting QA to carry the entire burden.
These questions make the difference visible:
- Is QA involved while features are being designed, or only after implementation?
- Do product, design, development, and QA agree on what success means?
- Are defect-reporting expectations shared working agreements or rules imposed by QA?
- Can every discipline explain its responsibility when a release carries risk?
- Are release decisions made from combined evidence, or handed to QA as a final yes-or-no question?
If the answers depend entirely on QA, quality is not yet shared.
Quality Is a Product Capability
The purpose of QA leadership is not to make QA the centre of every decision.
It is to help the product team make better decisions with clearer evidence.
Assigning a QA partner to each feature gave testing earlier context. Joining design conversations exposed assumptions before they became expensive. Agreeing on useful bug reports reduced friction between discovery and repair. Reviewing release risk together made tradeoffs visible and deliberate.
None of those practices removed accountability from QA.
They placed QA’s accountability inside a stronger product system.
Quality becomes sustainable when every discipline knows what it owns, when uncertainty is discussed early, and when release decisions reflect the combined reality of the product—not only the test result at the end.
QA should lead that conversation.
It should never have to carry it alone.