In Scrum, QA is an embedded, full member of a cross-functional team rather than a separate downstream gate. Testers participate from the moment a story is discussed, contributing to quality across the whole sprint instead of receiving 'finished' work to test at the end.
The biggest mental shift from traditional QA is that quality becomes a shared, whole-team responsibility, with the tester as its steward rather than its sole owner. A QA engineer on a Scrum team refines stories (asking the clarifying questions that expose ambiguity before coding starts), defines and reviews acceptance criteria, pairs with developers, tests continuously through the sprint rather than in a crunch at the end, automates regression, and gives the Product Owner a clear quality and risk picture at any point. Crucially, QA is not a bottleneck that work queues behind, nor the scapegoat when a defect escapes — the team collectively owns quality, and QA amplifies it by making risk visible and testing early. This 'built-in quality' model is what interviewers probe when they ask about your role in Agile.
During backlog refinement, a QA engineer asks 'what should happen if the discount code is expired?' — a case the story didn't cover. Because the question is raised before development, the team adds the acceptance criterion up front, and the edge case is built and tested correctly instead of becoming a bug found after the sprint.
Scenario: You join a team that treats QA as a final gate — developers hand over 'done' code late in the sprint and testers scramble to test everything in the last two days, so bugs constantly slip to the next sprint. In an interview, how would you describe changing QA's role to fix this?
The phrase interviewers listen for is 'quality is a whole-team responsibility' — then back it with concrete upstream activities (refinement, acceptance criteria, pairing), not slogans.