Scenario-based QA interview questions, and how to answer them

"You've been given a feature to test. No documentation, no acceptance criteria, and the BA who wrote it has left. What do you do?"

Can you generate your own test basis when nobody hands you one? Juniors wait to be told what correct looks like. Mid-level engineers go and find out.

First establish what sources of truth actually exist, because "no documentation" almost never means zero information. Read the ticket and its comments, the pull request and its description, the code diff if you can read it, and any chat thread linked from the ticket. That usually recovers most of the intent.

Then use the product itself. Explore the feature and write down what it currently does as a set of statements: "submitting an empty form shows an inline error", "the session expires after 30 minutes". That document is now the closest thing the team has to a spec.

Take that list to the developer and the product owner separately and ask them to correct it. It is much easier for a busy person to correct a wrong statement than to write a spec from nothing. Anything they disagree on is either a bug or a genuine requirements gap, and both are worth surfacing before you test a single case.

• What if the developer and the product owner give you contradictory answers?
• How do you decide something is a bug when nothing says what correct is?
• Would you block testing until you got sign-off on your document?

"I'd refuse to test without requirements." It sounds principled. It reads as someone who will be blocked for two weeks every time a process is imperfect, which is most of the time. The mirror-image trap: "I'd just test it based on my experience", with no attempt to write anything down or get it confirmed.

"How would you test a login page?"

Not a test-case question — a structure question. They want to know whether you can organise a large surface area out loud without rambling. Almost everyone fails it by listing cases at random until they run out.

The performance version of this answer is about order, not coverage. Say your categories first, then fill them in:

"I'd break it into six areas: functional happy path, input validation, security, session behaviour, integrations, and non-functional."

Then one or two lines each. Functional: valid credentials land on the right page, remember-me persists, the redirect after login returns you to where you were going. Validation: empty fields, whitespace-only, case sensitivity on email versus password, max length, unicode in the password field. Security: lockout after N failed attempts, no user enumeration in the error message, rate limiting, injection payloads in both fields, credentials only over HTTPS. Session: expiry, concurrent logins, behaviour after password change, logout invalidating the token server-side. Integrations: SSO, password reset, MFA. Non-functional: response time under load, a screen reader and keyboard-only pass, cross-browser.

Then stop and ask which area they want to go deep on.

• Which of those six would you cut if you had one hour?
• What is a user enumeration vulnerability and how would you test for it?
• Which of these would you automate, and which stay manual?

Starting with "I'd test valid username and valid password" and free-associating for four minutes. The content might be fine and you will still score badly, because the interviewer can't tell whether you covered the space or just remembered a lot of things. Categories first, always. The second trap is skipping security entirely — the fastest way to sound junior on this question.

"You raised a bug. The developer can't reproduce it. What do you do?"

Do you own the investigation, or hand the problem back? "Cannot reproduce" is where most valid bugs quietly die, and they want to know whether you're the reason they die or the reason they don't.

Start by assuming the difference is in the environment or the data, not in whether the bug is real. Reproduce it again yourself on a clean state, and count. Five out of five means the report is missing a step. Two out of ten is the actual finding, and you need to say so explicitly, because the developer has probably tried twice and stopped.

Then diff your context against theirs: build number, environment, browser and version, user role and permissions, feature flags, the specific account and its data, whether you entered the flow from a different page. Feature flags and account state are where it usually hides.

If it still won't pin down, go for evidence instead of steps: a screen recording with the network tab open, the request ID from the failing call, the server log around that timestamp. And offer to sit with the developer for ten minutes and reproduce it on your machine. That conversation resolves it faster than four rounds of ticket comments almost every time.

• What if it only happens in production and you can't reproduce it anywhere else?
• At what point do you accept it can't be reproduced and close it?
• How would you have written the original report to avoid this?

Reopening the ticket with "still happening on my side" and no new information. That is a status update, not an investigation, and it burns the developer's goodwill. The other trap is over-claiming in the first place — if you wrote "happens every time" and it happens one time in six, you've spent credibility you'll need later.

"You're asked to test a release and nobody can tell you exactly what changed. How do you scope it?"

Can you do impact analysis without being handed one? This is a common real situation, especially on teams with weak release notes.

Build the change list yourself from the artefacts. The commit log or the merged pull requests between the last release tag and this one gives you the raw truth, even if you only read titles and changed file paths. Ticket IDs in commit messages let you pull the actual tickets.

From there, map code areas to user-facing areas. If the diff touches the payment service, you are regression testing checkout regardless of what the ticket claimed. Shared modules matter most: auth, session handling, anything in a common utilities package, any database migration. Those are the changes whose blast radius is bigger than the ticket describes. Config changes count as changes, even when no code moved.

Write the scope down as a short list and send it to the tech lead as a question, not a request: "I'm planning to cover these six areas and skip these three. Anything you'd swap?" Two minutes of their time, and you get a correction if you've missed something — which is what you actually want.

• What if there are no tickets linked to the commits?
• How do you handle a database migration in your test scope?
• Would you test areas that weren't touched at all? Why?

"I'd run the full regression suite." On a small product that might be honest. On anything real it means either you don't have a full suite or running it takes longer than the release window — and the interviewer knows that. Saying it signals you haven't had to make this call for real.

"You've logged a bug as critical. The developer says it's minor and wants to close it. What happens next?"

Can you defend a technical position without turning it into a personal fight — and do you understand that severity is an argument about impact, not about who is more senior?

First check whether you're arguing about the same thing. Very often the developer is assessing how hard it is to fix, and you are assessing what happens to the user. Those are different questions and both people can be right.

So move the conversation off adjectives and onto specifics. Not "this is critical", but: who hits it, how often, what happens to them, and is there a workaround. "This affects any user paying with a saved card, which is about half our checkout volume, and there's no workaround" is a much harder position to wave away than the word "critical".

If you still disagree, don't escalate it as a conflict. Take it to whoever owns the priority call — usually the product owner — and present both readings honestly, including the developer's. Your job is to make sure the decision is made with accurate information, not to win. And if the decision goes against you, make sure it's recorded as an accepted risk rather than a closed bug, because those are very different things six weeks later.

• Give me a real example where you did this and lost the argument.
• Who should own severity, and who should own priority?
• What if the developer is the tech lead and outranks you?

Two failure modes, mirror images. "I'd escalate to my manager", immediately — someone who can't hold a technical conversation with a peer. Or "I'd defer to the developer since they know the code" — someone who won't defend a user-impact finding. Interviewers listen for whether you can stay in the disagreement productively for one more round before either.

"A developer keeps closing your bugs as 'works on my machine'. Four times this month. How do you handle it?"

Can you address a pattern rather than re-fighting each instance, and raise a people problem without accusing anyone?

Four times is a pattern, so stop treating it ticket by ticket. Pull the four tickets and look for what they share. Usually there is something structural: they test on localhost with seed data and you're on a shared environment with production-like data, or they're on a different build, or the tickets genuinely are missing a precondition you've been assuming.

If the cause is on your side, that is the cheapest fix available — change how you write reports. If it's environmental, that's a team problem worth naming, and it goes to standup as "we've had four cannot-reproduce closures this month; I think our environments have diverged" rather than as a complaint about a person.

And change the medium. Async ticket comments are terrible for this. Ten minutes of screen-sharing, reproducing it live while they watch, ends the disagreement permanently and usually improves how you work together afterwards.

• What if you look at the four tickets and the cause really is on the developer's side?
• When would you involve your manager or theirs?
• How do you keep that conversation from becoming defensive?

Framing it as a character problem. "Some developers just don't take QA seriously" tells the interviewer exactly how you'll talk about their team in six months. Describe the system, not the person.

"You report something as a bug. The product manager says it's intended behaviour. You think it will confuse real users. What do you do?"

Do you know the boundary of your authority, and can you still advocate effectively inside it?

The PM is right that it's their call. Intended behaviour isn't a bug, and arguing that it is goes nowhere. But "this is intended" and "this is good for users" are separate claims, and you can push on the second without disputing the first.

So re-file it — not as a defect, as a usability observation, with evidence rather than opinion: the specific point where a user has to guess, what they'll most likely do, and what it costs them when they guess wrong. If support data or session recordings show users already hitting it, that's worth ten opinions.

Then let it go. The risk is visible and filed somewhere it can be prioritised later. Escalating a design disagreement past the person who owns the design is a good way to be excluded from those conversations in future — and being in the room early is worth more than winning one ticket. The exceptions worth naming: accessibility, data loss and security, where "intended behaviour" is not the end of the conversation.

• What if it's an accessibility or legal compliance issue rather than usability?
• How do you decide what's worth pushing on versus letting go?
• Has this happened to you, and were you right?

"I'd keep reopening it until they listened." Persistence is a virtue right up to the point where it becomes a reputation. The other trap is being unable to name any situation where you'd override the PM — a good answer knows where that line is.

"Tell me about a bug that reached production that you should have caught."

Can you own a failure without collapsing into self-blame or deflecting onto process? The highest-signal question on this list, and the answer is almost entirely about tone.

Pick a real one. Four parts, and keep the first short.

What happened: "We shipped a change to the discount engine. Percentage discounts worked; fixed-amount discounts applied twice on orders with more than one item. It was live for two days before support flagged it."

Why you missed it — honest and specific: "I tested both discount types, but only on single-item carts. I had a multi-item case in my plan and dropped it during a time squeeze without flagging that I'd dropped it." Not "requirements were unclear". The pressure was real and it isn't the reason.

What you did when it surfaced: reproduced it quickly, established the blast radius by querying how many orders were affected, gave finance the list, verified the fix.

What changed: "Cart composition is now a standing dimension in my test design for anything touching pricing, and when I cut scope I write down what I cut and send it to the lead. The second habit has caught more than the first."

• Why didn't your test design cover that case in the first place?
• How did you communicate it to the business?
• Did the same class of bug happen again after your change?

Choosing an example where it wasn't really your fault. Interviewers ask this specifically to see ownership, and an answer that ends with "so it turned out to be the developer's mistake" fails the question completely, however good the story. The opposite trap: excessive apology, no analysis, no change. One sentence of ownership, three of judgment.

"It's Friday evening. Users are reporting that checkout is failing. You're the only QA person online. What do you do?"

Do you know the difference between testing and incident response? Under an incident, your job changes completely.

The first job is not root cause. It's scope, and getting the right people awake. How many users, which flows, which regions or platforms, when did it start — a rough answer to those four decides whether this is a page-someone-now event.

Reproduce it once so you can describe it precisely, and grab the evidence while it's live: a failing request ID, the error response, a timestamp. Then notify whoever owns on-call for that service with those specifics rather than "checkout is broken". A concrete report gets a faster response.

In parallel, find the correlation: what deployed recently, what config or feature flag changed, is the payment provider itself having an incident — their status page takes fifteen seconds to check and closes a surprising number of Friday-night mysteries.

While the fix is worked on, your job is verifying the rollback or fix quickly and honestly, and checking for damage the fix doesn't address: orders stuck half-created, duplicate charges, emails never sent. Then a written timeline, so Monday's post-mortem isn't reconstructed from memory.

• Rollback or forward fix — how do you decide?
• What if you can't reproduce it and only some users are affected?
• What goes into the post-mortem, and who writes it?

Starting with "I'd write a bug report." During an active incident, filing a ticket is roughly the fifth action, not the first. And never claim you'd deploy or roll back yourself unless that's genuinely your access level — overstating authority in an incident answer is memorable in a bad way.

"How do you decide when to escalate something?"

Everyone says "I escalate when necessary". They're checking whether you have an actual threshold or just a vibe.

Escalate on triggers decided in advance, so the call isn't made emotionally in the moment.

Useful triggers: anything involving data loss, data exposure or money moving incorrectly goes up immediately, regardless of how few users are affected, because those don't get better with time. Anything that blocks a release date goes to whoever owns the date the moment you're confident it blocks. Anything raised twice without movement goes up, because at that point you're the bottleneck if you keep waiting. And a cluster is a trigger by itself: three bugs in the same module in one sprint says something structural, worth a conversation even when no individual bug is severe.

Below those thresholds, handle it directly — escalating everything is the same as escalating nothing. And when you do escalate, bring the impact, what you've already tried, and what decision you're asking for. Escalation without a specific ask is just handing someone a problem.

• An example where you escalated and it turned out to be unnecessary?
• Who do you go to first — your manager or the tech lead?
• What if your manager tells you to stop raising it?

"I escalate everything to my manager and let them decide." Sounds safe; reads as no judgment. The opposite — "I handle everything myself first" with no ceiling — is how a critical bug sits in someone's DMs for three days.

"There was a production incident. By the time anyone looked, it had resolved itself and nobody knows why. What do you do?"

Can you tolerate an unresolved unknown responsibly, or will you declare it fine because it stopped?

A self-resolving incident is not a resolved incident — it's an incident with an unknown trigger and an unknown recurrence interval. So the first move is pushing back, gently, on closing it.

Practically: reconstruct the window. Error rates before, during and after. What was deploying, what scheduled jobs run around that time, whether traffic spiked, whether a downstream dependency wobbled. Self-resolving usually points at something time-based or load-based: a job, a cache expiring, a connection pool exhausting and recycling, a rate limit resetting, a token refreshing.

Then check for silent damage, because "it recovered" often means the system recovered and the data didn't: failed transactions retried into duplicates, records written half-complete, notifications never sent.

If the cause genuinely can't be determined, argue for two things rather than a close: an alert that would catch it faster next time, and a written record with the timestamp. The second incident is much easier to solve with the first one documented — and self-resolving issues almost always come back.

• What would you put in the alert, specifically?
• How long do you keep this open before accepting you won't find it?
• Who decides whether to spend more time on it?

"It's working now, so I'd close it and monitor." The answer of someone who has never met the same incident four weeks later at a worse time.

"Regression normally takes a week. You have two days. What's your plan?"

Can you cut scope deliberately and defend the cut, or do you just test faster and hope?

Cut by risk, and make the cut visible rather than silently doing less.

What survives, in order: anything in the change's blast radius, based on the actual diff. Then the revenue-critical paths — for most products signup, login and checkout — regardless of whether they were touched. Then areas with a regression history, which the bug tracker will tell you if you filter by module. Then anything with a recent hotfix, because hotfixes are written fast and break things nearby.

What gets cut: low-traffic admin flows, cosmetic checks, browser-device combinations outside the top few by real usage, and anything already covered by a trusted, green, non-flaky automated check — if the suite genuinely covers a path, don't manually repeat it.

Then write the cut list down and send it with the plan. Two days of coverage plus an explicit list of what was not tested is a much stronger position than two days of coverage and silence, because it turns your constraint into a decision the business gets to make.

• How do you find out which areas have a regression history?
• What if the business won't accept the gaps you listed?
• What would you change so this doesn't happen next release?

"I'd work overtime and get it all done." It sounds committed. It tells the interviewer you'll absorb a planning failure quietly — which means it repeats forever and nobody ever finds out the schedule was wrong.

"Your manager says there's no time to test properly this sprint. How do you respond?"

Can you disagree with a business constraint without caving or becoming an obstacle? This tests your reaction as much as your plan.

Don't argue with the constraint — arguing with a deadline rarely changes one. Change what's being decided. "No time to test" isn't a decision anyone can act on. "Here's what we can cover in the time we have, and here's what ships untested" is.

Come back quickly with two or three concrete options rather than a complaint. Option one: full coverage of checkout and the new feature, skip the reporting module entirely. Option two: ship behind a flag to 5% of users and test in production with a fast rollback. Option three: move the date two days. Each with what it costs and what it risks.

That reframes it from QA-versus-the-deadline into a business choice, which is what it actually is. Whether the company accepts the risk is not your call. Making sure the risk is stated in plain language before the call is made — and that nobody later believes it was tested when it wasn't — is exactly your call.

• What if they pick the option you think is worst?
• How do you word the risk so it's taken seriously without sounding dramatic?
• Would you sign off on the release in that situation?

"I'd tell them quality can't be compromised." Everyone in that meeting already knows testing is valuable. Saying it out loud without a plan attached is the moment QA gets categorised as the department that says no — and that's genuinely hard to come back from.

"The regression suite takes six hours. The team wants a go/no-go answer in thirty minutes. What do you run?"

Do you understand that a suite is a portfolio you can slice, not a monolith you either run or don't?

Thirty minutes buys a specific kind of answer, so be clear which one: "nothing catastrophic is broken", not "this release is good".

Run a smoke set built for exactly this: can users authenticate, can the core transaction complete end to end, are the critical integrations responding, does the deployed build actually serve pages. That's usually 15–40 checks, well under thirty minutes. If no such set exists, tagged and ready, building one is the thing to fix immediately afterwards — this request comes every release.

Add whatever targets the specific change going out, since the suite doesn't know what's in this build and you do.

Report it in exactly those terms: "Smoke passed. That covers auth, checkout and the payment integration on this build. It does not cover reporting, admin, or anything about performance. On that basis I have no blocker, and I'll have a fuller answer in six hours." Precision about what a green result means is the whole value of the answer.

• How do you choose which tests belong in the smoke set?
• What if two smoke tests fail and you suspect they're flaky?
• Would you say go based on a smoke run alone?

Running a random 30-minute slice of the suite and reporting "tests passed". A green result whose coverage nobody can describe is worse than no result — it manufactures confidence backed by nothing.

"The feature depends on a third-party API that only exists in production. You can't call it from staging. How do you test it?"

Can you design around a constraint instead of declaring yourself blocked — and do you understand the difference between testing your code and testing their service?

Split it into two problems, because they need different solutions.

Your integration logic is the part you can test properly. Mock or stub the third party at the boundary and drive every response you care about: success, their documented error codes, malformed payloads, empty results, a timeout, and a slow-but-successful response. Timeout and slow-response handling are where integrations actually fail in production, and they're the cases nobody writes because the happy path is what's in the docs. Build the stubs from the provider's documentation — or better, from real captured responses if any are logged. If there's no contract testing, this is the moment to argue for it, since the remaining risk is the provider changing their response shape without telling you.

Then there's the part you genuinely cannot verify pre-release. Design a narrow production validation: a test account, a single low-value real transaction, run immediately after deploy with a rollback ready, and monitoring on that integration's error rate so you find out from a dashboard rather than from a customer. Write it down as a known gap rather than letting it pass silently.

• How do you keep your mocks from drifting away from the real API?
• What if the provider has a sandbox but it behaves differently from production?
• What would you monitor after release, specifically?

"I'd test it in production" as the whole answer, with no stubbing and no plan, reads as someone with no design skills. Testing in production is a real technique with real prerequisites — a safe account, low blast radius, monitoring, a rollback. Name those and it's a strong answer. Skip them and it's a shrug.

"How would you test a nightly job that reconciles payment records? There's no UI."

Can you test something you can't click? Many manual QA candidates have only ever tested through an interface, and this question finds out immediately.

With no UI, the observable surface is the inputs, the outputs, the logs and the side effects — so that's where the test design goes.

Start with the data. Build input datasets for the cases the job has to handle: matched records, unmatched in each direction, duplicates, records at exactly the boundary of the time window, and the ones that always break batch jobs — timezone edges, currency and rounding, records arriving during the run itself. For each dataset, state the expected end state of the database before running anything.

Run the job against a known starting state and diff the database against the expectation rather than eyeballing it: row counts, sums, specific record states.

Then the operational behaviour, which is where these jobs really fail. Is it idempotent — if it runs twice, does anything double? What happens if it dies halfway — partial state or rollback? Does it complete inside its window at production data volume? Does it alert on failure, or does it fail silently until a finance report three days later?

• How would you test idempotency specifically?
• What if the job is slow only with production-size data?
• What monitoring or alerting would you ask for?

"I'd check the logs to see if it ran." Confirming a job executed is not confirming it was correct — a job that runs successfully every night while producing wrong numbers is the exact failure mode this question exists to probe.

"The test environment has been broken for a week. What have you been doing?"

Are you someone who is blocked, or someone who finds work? They're also checking whether you'd let a week pass without escalating.

Part of the answer is that a week is too long — escalate on day two, with a cost attached: "We're blocked on the environment. That's roughly X days of testing not happening and it puts the release date at risk." Environment problems get fixed when they have an owner and a visible cost, and they linger when they're only QA's problem.

Meanwhile there's real work that doesn't need the environment: writing test cases and test data for upcoming features, reviewing requirements and pull requests for the work in flight — which catches things earlier and cheaper than testing does anyway — cleaning the bug backlog, fixing the flaky tests in the automated suite, building the test-data scripts everyone always means to build.

And try to unblock yourself technically: run the app locally, point at a different environment, test the API layer directly even if the UI is down. Partial access is usually available if you go looking.

• Who would you escalate to, and what would you actually say?
• How do you quantify the cost of the downtime?
• What would you propose so it doesn't happen again?

"I waited for it to be fixed." Even said honestly, it's the answer of someone who treats their own blocked time as somebody else's problem. The related trap is escalating with frustration rather than with a number.

"There's a test in the suite that fails maybe one run in five. Everyone just re-runs it. What do you do?"

Do you understand that flakiness is a trust problem, not a test problem — and will you do the unglamorous work of fixing it?

The real cost isn't the failing test; it's that the team has learned to ignore red. Once re-running is the reflex, a genuine failure gets re-run too, and the suite has stopped protecting anything.

First, quarantine it — out of the blocking pipeline, into a separate non-blocking run, so the main suite goes back to meaning something. Quarantine with a ticket and an owner, not quarantine as a graveyard, or it sits there for a year.

Then diagnose rather than patch. Run it in a loop, fifty times, and capture screenshots, video and logs from the failures. The usual causes: a race between the assertion and the application state, tests sharing mutable data, an implicit dependency on execution order — or a genuine intermittent bug in the product, which is the reason to look properly before assuming it's a test problem. Some flaky tests are correct tests catching a real race condition.

The fix is almost always waiting on a condition rather than a duration, and isolating the test's data. A retry or a sleep is the thing to avoid — it hides the signal rather than removing the cause.

• How would you tell a flaky test from a real intermittent product bug?
• What's wrong with adding a retry?
• How do you stop new flaky tests entering the suite?

"I'd add a wait and move on." It works today, slows the suite forever, and teaches the team that flakiness is normal. The other trap is "I'd delete it", said without checking what it covers.

"You're not confident in this release, but the business wants to ship. What do you say?"

Do you know where your authority ends, and can you still be useful past that line? Can you convert a feeling into something a decision-maker can act on?

"I'm not confident" is not usable information, so the first job is converting it into something concrete. Is it specific known bugs? Coverage you didn't get to? Instability you saw but couldn't pin down? Those lead to different decisions.

State it as risk rather than verdict: "There are two open medium bugs in the payment flow. I didn't get to the refund path at all. The most likely failure is X, and if it happens it affects roughly this many users." Concrete enough to weigh.

Then offer the middle options, because ship-or-don't is almost never the real choice: behind a feature flag; staged to 5% first; ship with monitoring on the specific paths you're worried about and a tested rollback; ship, and you'll run the untested path in production within an hour of deploy.

Then the business decides, and that's correct. What you won't do is say the release is fine when you don't think it is. Say what you know, what you don't, and what you'd watch — and make sure it's written down.

• Would you formally sign off in that situation?
• What if it ships and your predicted failure happens?
• How do you keep doing this without becoming the person who always says no?

"I'd refuse to sign off." QA usually doesn't have veto power, and claiming it signals a misunderstanding of the role. The worse trap is the opposite: "It's their decision, so I'd approve it." Making the risk explicit and legible is your job, and it doesn't require a veto.

"Tell me about a time you were wrong about a bug."

Can you be corrected without becoming defensive — and do you actually change how you work when you find out you were wrong?

Give a real one where you were confidently wrong, not trivially wrong.

For example: a report showed numbers that didn't match the UI. Certain it was a calculation error, you escalate it as high severity two days before release, and a developer spends most of a day on it. It turns out the report intentionally excluded cancelled orders and the UI didn't — documented behaviour, in a spec you hadn't read carefully.

What was wrong wasn't noticing the discrepancy, which was reasonable. It was the certainty. "The calculation is wrong" sent the developer hunting for a defect; "these two numbers disagree and I don't know which is correct" would have sent them looking for the difference.

The change that sticks: separate the observation from the diagnosis in every report. The observation is what you saw and can prove. The diagnosis is your hypothesis, clearly labelled as one. It costs nothing to write and stops you anchoring someone else on your guess.

• How did you handle telling the developer?
• Has separating observation from diagnosis actually changed anything since?
• When is it right to include your hypothesis at all?

Picking something so minor that being wrong cost nothing — which dodges the question. Or the humblebrag version, where you were "wrong" in a way that made you look diligent. Interviewers hear both constantly. Pick the one that cost someone else time, and say so plainly.