Agile QA interview questions
Agile QA questions a QA / manual tester can be asked, from first job to senior. Open one to see the strongest answer and why it works.
A screen fails with “something went wrong.” What do you ask the team to add?
The strongest answer: Testability: a visible error id, a log I can attach, and a way to set the state again — I cannot investigate a brick wall
Why it works: Exactly. Controllability and observability. A correlation id beats a shrug.
- Ask for an error id.
- Ask for a log you can attach.
- Ask for a way to seed the state.
- That is testability, not luxury.
What does “shift left” mean when a hiring manager says it?
The strongest answer: Find risk earlier — in the story, the design, the contract, the unit tests — not “QA starts coding the feature”
Why it works: Exactly. Earlier questions, cheaper defects. It is not “QA writes the product.”
- Ask earlier, in the story and the contract.
- Use tests at the cheapest layer that can catch it.
- It is not “no QA.”
- It is not “infinite regression.”
The team is writing its Definition of Done. What do you insist belongs in it from QA’s side?
The strongest answer: That the acceptance criteria are verified on a deployed build, that bugs found in the story are fixed or explicitly accepted, and that the regression risk is covered — not “tested on a developer’s machine”
Why it works: Right — done means verified where it will actually run, with the known bugs decided rather than forgotten.
- Done is a condition, not a person.
- Criteria verified on a deployed build.
- Bugs fixed or explicitly accepted.
- Regression risk covered.
You cannot put an account into “past due” without a week of waiting. What do you ask for?
The strongest answer: A test seam: a clock, a fixture, or an admin action — controllability — plus a way to see the state — observability
Why it works: Exactly. If you cannot set it and cannot see it, you cannot test it. That is a design ask.
- Ask for a seam to set state.
- Ask for a way to see state.
- Do not wait a week in CI.
- Do not use a real customer as a fixture.
Where does QA sit when a story is still a paragraph?
The strongest answer: On the acceptance and the risks: what would make this story false, what data we need, what we cannot prove in staging — I do not wait for a “QA column”
Why it works: Exactly. Shift-left is questions on the story. Not owning their backlog, not waiting for a column.
- Join the story early.
- Write risks and acceptance.
- Name what staging cannot prove.
- Do not start with the tool.
A story’s acceptance criteria read “the page should be fast” and “errors are handled nicely.”
What do you do with them?
The strongest answer: Take them back with a testable version — a number for “fast” on a named action, and the specific errors with what the user sees and can do next — agreed before the sprint, not at the demo
Why it works: Exactly — proposing the wording is faster than asking an open question, and it settles the argument before anything is built.
- Make criteria testable before the build.
- Replace “fast” with a number.
- Replace “nicely” with the message.
- Agree it in the story, not the demo.
Every sprint, the stories all arrive for testing in the last two days and testing spills over.
What do you change?
The strongest answer: Attack the batch: slice stories so they finish through the sprint, agree a limit on work in progress, test each story as it lands, and put the spill in the retro with the numbers
Why it works: Right — the cause is batching, so slicing, a work-in-progress limit and a visible spill are what actually move it.
- The problem is the batch.
- Slice stories to finish early.
- Limit work in progress.
- Show the spill with numbers.
You sit in a design review. What testability asks belong there?
The strongest answer: How we seed states, how we see errors, how we time-travel clocks, how we test the empty and the full — I do not wait for a build to discover a brick wall
Why it works: Exactly. Seams and oracles in the review. That is shift-left you can point at.
- Ask for seams.
- Ask for visible errors.
- Ask for empty/full.
- Do not wait for the brick wall.
Shift-left failed here before (“QA in the sprint, still late”). What was probably missing?
The strongest answer: Power: QA can change the story and the contract, not only sit in the ceremony — a seat without a brake is theatre
Why it works: Exactly. Shift-left is authority to change the work early. A silent seat is late QA with better snacks.
- Give QA a brake on the story.
- Contracts and seams, not only tickets.
- Ceremony ≠ shift-left.
- Do not solve it with a rename.
When do you reject a design as untestable?
The strongest answer: When we cannot seed the state, see the result, or isolate the risk — I write that as a defect on the design, not as a personal preference
Why it works: Exactly. Controllability, observability, isolatability. That is a bar you can teach.
- Seed, see, isolate.
- File untestable as a design defect.
- Teach the bar.
- Do not silently adapt to a wall.
Releases wait for a heroic QA weekend. What do you install?
The strongest answer: A train: a paved smoke that fits the cadence, a residual ritual, and a deputy — I do not staff quality with heroics
Why it works: Exactly. Cadence-shaped smoke and a ritual. Heroics are a smell.
- Fit smoke to the train.
- Ritualise residual.
- Name a deputy.
- Do not plan on weekends.
Eight squads, eight definitions of “tested.” What do you standardise?
The strongest answer: The gates and the language (severity, smoke, residual) — I do not standardise every case or every tool
Why it works: Exactly. Shared gates and words. Local cases and tools can differ.
- Standardise gates and words.
- Let cases stay local.
- Do not become the approver of everything.
- Do not write a shelf-playbook.