Most QA interviews are one question wearing five different costumes: here is a thing — how would you test it?

That's not a criticism of the format. It's a genuinely good work sample, because the answer is unfakeable. A tester who has done the job generates cases in a recognisable order and stops in a recognisable place. Someone who has memorised the vocabulary produces a list of testing types and runs out.

So this list is organised by what the interviewer puts in front of you, not by testing theory. The object changes; what they're watching does not.

5
Things they'll hand you across a QA loop
1
Instinct being tested every time: how you generate cases
0
Specs that contain everything you need

They hand you a feature

The opening round, and the question everyone knows is coming.

  1. How would you test a login page?
  2. How would you test a lift?
  3. Where do you stop testing?
  4. You have two hours before a release. What do you test?

Saying it out loud: question 1 fails on structure, not on knowledge. Almost everyone can list valid credentials, invalid credentials, empty fields. What separates a strong answer is announcing the axes before listing the cases: "I'd split it into functional, then boundaries, then security, then everything around the happy path — network dropping mid-request, back button after login, session already expired in another tab. Let me start with functional and go through in that order." Now the interviewer knows you have a system, and every case you name lands inside it instead of sounding like recall.

Question 2 is the same test with the software removed, and it exists to catch people who only know web testing vocabulary. Same move: name the dimensions — capacity, sequencing, interruptions, emergency behaviour, what happens on power loss — before you start listing.

Question 3 is the one candidates dread and it has a real answer: you stop when the remaining risk is smaller than the cost of continuing, and you say what risk you're accepting. "When all test cases pass" is the answer of someone who has never shipped under a deadline.

They hand you a bug

Where they find out whether you make problems smaller or just report them.

  1. A bug reproduces on one device and nowhere else. How do you narrow it down?
  2. What makes a bug report good enough to act on?
  3. A developer closes your bug as "cannot reproduce". What now?
  4. How do you set severity and priority — and who wins when you and the developer disagree?

Saying it out loud: question 7 is a collaboration question disguised as a technical one, and the wrong instinct is to defend the ticket. The strong answer treats "cannot reproduce" as information about the report: "It usually means my report was missing something I didn't know mattered — a state I'd built up earlier, a specific account, a slow connection. So I'd try to reproduce it on a clean environment myself first, and if I can, I'd record it and add exactly what changed. Reopening it with the same description just moves the argument to the next standup."

What gets ignored

A report that describes the symptom

“Checkout is broken on Android. Steps: go to checkout, tap pay. Expected: payment goes through. Actual: error.”

True and unusable. Which Android, which build, which account state, and does it happen every time? Every missing answer is a message the developer has to send before they can start, and each one costs a day.

What gets fixed today

A report that removes the guessing

“Pixel 7, Android 14, build 412. Reproduces 5/5 with a saved card added before the app was updated; 0/5 with a card added after. Error appears about two seconds in — log line attached, video attached.”

You've done the halving already. The frequency and the working case are what turn a ticket into a fix, because you've handed over the difference rather than the symptom.

There's a longer walkthrough of that skill here: how to explain a bug report clearly in a QA interview.

They hand you a spec

Middle rounds. The section that separates testers from test executors.

  1. Here's a requirement. What do you ask before writing a single test?
  2. What's an edge case you'd add that isn't in the spec?
  3. How do you test something with no spec at all?
  4. The spec and the implementation disagree. What do you do?

Saying it out loud: question 12 has a trap in it, and candidates fall in by answering confidently in one direction. Neither "the spec is the source of truth" nor "ask the developer" is the answer on its own: "First I'd raise it rather than resolve it, because a mismatch usually means two people had different pictures and neither of them is wrong yet. What I'd bring is which one the user is better off with, and what it costs to change each. If the implementation is better, the spec is the thing that needs updating — otherwise the next tester finds the same mismatch again."

Question 11 is increasingly the realistic one. Interviewers want to hear where you'd get the intent — existing behaviour, the support queue, the analytics, the person who asked for it — rather than a complaint that the requirements are missing.

The pattern across the first three sections: every strong answer named its structure before its content. The axes before the cases. The clean environment before the reopened ticket. The two pictures before the mismatch. That is the whole difference between a tester and a list of test types — and it's audible in the first fifteen seconds of an answer, which is why interviewers keep handing candidates objects instead of asking definitions.

They hand you an API or an automation question

Where the loop gets technical, and where the honest answer beats the ambitious one.

  1. What do you automate, and what do you deliberately leave manual?
  2. A test suite has become flaky. How do you approach it?
  3. How would you test an API with no interface in front of it?
  4. What makes a test suite still worth maintaining in two years?

Saying it out loud: question 14 is the best seniority signal in the list, because flakiness is where inexperienced teams do the most damage: "The one thing I wouldn't do is add a retry and move on, because that hides the failure and eventually hides a real one. I'd find out whether it's the test or the environment — timing assumptions and shared state cause most of it — and I'd quarantine the flaky test out of the blocking suite while it's investigated rather than leaving it to erode everyone's trust in red builds. A suite people ignore is worse than no suite."

Question 13 rewards a boundary rather than an ambition. Regression paths and anything with a stable contract get automated; exploratory work, anything visual, and anything still changing weekly stay manual — and saying that plainly reads as more experienced than saying you'd automate everything.

They hand you a release decision

The final round, and often the one that decides the level.

  1. Testing isn't finished and the release is tonight. What do you say?
  2. What do you report in a release meeting, and in what order?
  3. A bug reached production. What happens next?
  4. How do you know whether your testing was any good?

Saying it out loud: question 17 is checking whether you'll take a decision that isn't yours. The senior move is to convert a yes-or-no into a risk statement: "It isn't my call to ship or not, and I'd say that plainly. What I can give them is what's been covered, what hasn't, and what the worst realistic outcome of the untested part is — 'payments are covered, the new onboarding isn't, and if it's broken the failure is silent, so we wouldn't find out until Monday.' That's a decision someone can actually make."

Question 19 is a culture question. Every strong answer starts with containment rather than blame — how many users, can it be turned off, does it need a hotfix — and only then asks how it got through, framed as what the process missed rather than who missed it.

Question 20 is the hardest and most revealing. The honest answer names an outcome measure: what reaches production, how much of it was in an area you'd covered, and whether the same category of bug keeps escaping.

The part that isn't about testing

Every question above is answered out loud, usually while someone interrupts you halfway through to add a constraint. QA loops do that deliberately — testers get interrupted constantly on the job, and the panel wants to see whether an interruption resets your whole answer.

The two habits that carry it are having a structure to return to, and being able to open cleanly before you get into detail. The opening is its own small skill, and it's the first thing the loop tests: “tell me about yourself” for QA engineers. If your loop includes a test-plan walkthrough, there's a full guide for that round: the QA technical interview.

Practical target: take question 1 and answer it out loud, but say your axes first and then stop after four cases. If naming the structure feels slower than diving into cases, do it anyway — it's the part interviewers score, and it's the only part that still works when they interrupt you.