How would QA contribute to a team that says everyone owns quality?

Example Answer

I'd make shared quality responsibility concrete. Before development, I would help the team identify address-change risks: the shipment cutoff, who can change an order, and whether fulfillment receives the new address. I would turn unresolved examples into decisions with product and engineering, rather than wait for a finished screen.

During development, developers would own implementation and appropriate automated checks. I would contribute test design, inspect coverage at the service boundaries, and explore behaviors that scripted examples may miss, such as an address change racing with shipment creation. The designer would help verify understandable feedback and accessible interactions.

Before release, I would report what we tested, what failed, and what remains uncertain. I would recommend a decision based on that evidence, while the product manager makes the release decision under the stated ownership. After release, support signals and incidents would feed back into our tests. QA adds independent investigation and a coherent picture of risk; it does not transfer responsibility away from the team.

What the interviewer is assessing

Core checks (1 point each):

• Names specific address-change risks before development.
• Assigns implementation, QA evidence and release authority from the brief.
• Explains how post-release evidence improves future test design.

Stronger (+1 after all core checks): Identifies a cross-system or timing risk and explains why business UAT acceptance cannot waive a failed account-access check.

Acceptable alternatives: Different team rituals work if the same risks and responsibilities are covered.

Red flags: Describes QA as the only owner of quality, treats developer tests as sufficient evidence for the whole journey, or promises a defect-free release.

Follow-up

What if a developer says the ticket meets every written acceptance criterion?

Example response: I would show the concrete unaddressed scenario and its consequence, then ask whether the criteria describe the intended behavior completely. If the team agrees that the scenario matters, we would clarify the requirement and test it. Passing the current examples is useful evidence, not proof that the requirement has no gaps.

Business users accepted the screen, but a required cross-account access test is blocked. Can QA sign off?

Example response: Business acceptance supports the tested workflow; it does not establish access isolation. I would report the gap, ask engineering and the environment owner to unblock the fixture, and obtain the required access review. The product manager decides release under the brief. A signature cannot turn an unexecuted mandatory check into a pass.