QA / manual tester interview questions

You paste a screenshot into Slack and walk away. What did you skip?

The strongest answer: A ticket with steps, expected, actual, and a build — Slack is a ping, not a record

Why it works: Exactly. Chat is ephemeral. The bug lives in a system of record with the three parts.

• File a ticket.
• Keep Slack as the ping.
• Include build and steps.
• Do not leave evidence only in chat.

A test fails on a slow CI runner. A teammate adds sleep(5000). What do you do instead?

The strongest answer: Wait for the condition that means the page is ready — a visible name, a network idle you can name, a disabled button becoming enabled — not a guessed number of seconds

Why it works: Exactly. Wait for a signal. Sleep is a guess that is too short on a bad day and too slow on a good one.

• Wait for a named ready condition.
• Sleep is a guess, not a wait.
• Same wait policy on laptop and CI.
• Do not delete the oracle to go green.

A developer says they cannot act on your bug. What was most likely missing?

The strongest answer: A short repro, what I expected, and what I actually saw — plus the build and environment — not a feeling that “it is broken”

Why it works: Exactly. Repro, expected, actual, and where. That is the job.

• Write steps, expected, actual.
• Name the build and environment.
• A screenshot supports; it does not replace.
• Do not substitute “urgent” for evidence.

The app asks for camera permission. What do you test besides tapping Allow?

The strongest answer: Deny it and check the app explains what is lost and still works, revoke it later in system settings and return to the screen, and check what the app does when the user is asked a second time

Why it works: Right — deny, revoke-while-installed and the second ask are where real apps break or trap the user.

• Test the denied path first.
• Deny, then use the feature.
• Revoke in settings, come back.
• Check the recovery message.

You saw a crash once and cannot get it again. What do you file?

The strongest answer: What I did, what I saw, logs if I have them, and “could not reproduce a second time” — I do not file “crash” with no path, and I do not stay silent

Why it works: Exactly. Honest once-only reports still help. Silence and empty P0s do not.

• File the once, honestly.
• Attach logs.
• Say you could not repeat it.
• Do not inflate the priority to keep it alive.

Where should most automated checks live?

The strongest answer: In fast, isolated tests — units and API contracts — with a thin UI smoke on the money path, not a mountain of browser clicks for every field

Why it works: Exactly. Cheap layers catch cheap bugs. The UI pack is a scarce budget.

• Many cheap tests, few browser tests.
• UI pack = money path.
• Do not skip the glue.
• Tools follow the pyramid, not the reverse.

What is a regression in this interview?

The strongest answer: Something that used to work and now does not — I re-check the money paths after a change, I do not only poke the new button

Why it works: Exactly. Old behaviour broken by a change. That is why we keep a regression pack.

• Regression = used to work.
• Re-check money paths after a change.
• Keep a small, honest pack.
• Automation is for the boring repeats of that pack.

What is the difference between severity and priority?

The strongest answer: Severity is how badly the product is hurt; priority is the order we fix it — a typo on the pay button can be low severity and high priority

Why it works: Exactly. Impact versus order. A good bug names both and does not confuse them.

• Severity = user / system impact.
• Priority = when we fix it.
• They can disagree on purpose.
• Write both; do not merge the fields.

Which locator do you reach for first?

The strongest answer: A role, label, test id, or other name the product owns — not nth-child, a pixel offset, or a CSS class that is a styling leftover

Why it works: Exactly. Prefer what a user or a contract would name. Styling leftovers move.

• Role, label, or test id first.
• Do not use nth-child as a habit.
• Recorded locators get edited.
• Visible copy is a weak contract.

A bug “works on my machine” and fails in staging. What do you write first?

The strongest answer: The environment, build, and the data I used — “staging, build 184, user with an empty cart” — not another screenshot of the same screen

Why it works: Exactly. Env + build + data is how “works on my machine” becomes a bug.

• Write env, build, data.
• Do not assume “the” environment.
• Staging ≠ local ≠ prod.
• Automation reports the same three.

A page shows “Something went wrong.” What does the Network tab tell you before you file the bug?

The strongest answer: Which request failed, its status code, and whether a response arrived at all — so the bug says “POST /orders returned 500”, not “it broke”

Why it works: Exactly — the failing call, its status and its response turn a vague report into one a developer can start on.

• Open the Network tab before filing.
• Find the failing request.
• Read method, path and status.
• Put them in the bug title.

A new build lands. What do you run first?

The strongest answer: A short smoke of install, login, and the money path — I do not start a 4-hour suite on a build that cannot open

Why it works: Exactly. Smoke is a cheap “is this a build.” Then go deep.

• Smoke first: install, login, money.
• Then the planned depth.
• Automate the smoke if you can.
• Do not start long if launch is dead.

Two people cannot agree if a bug is fixed. What field would have ended the argument?

The strongest answer: The build / version / commit on the report and on the “fixed” comment — “latest” is not a version

Why it works: Exactly. Versions end he-said-she-said. Latest is not a number.

• Put a build on the file.
• Put a build on the fix.
• Never say only “latest.”
• Then retest that pair.

There is no UX researcher on the team, and the flow matches the specification exactly.

How do you raise a usability problem?

The strongest answer: With evidence rather than taste: where a first-time user hesitated or went back, how many steps the task took, what the error message told them to do next — filed as a usability finding with its cost

Why it works: Right — one or two people struggling, with the steps and the recovery path recorded, is evidence a team can argue with.

• Make usability observable.
• Watch a first-time user.
• Count steps and backtracks.
• Report the cost, not your taste.

How do you debug a flake that only happens in CI?

The strongest answer: Reproduce with the trace, clock, and seed: wait, shared data, time, and parallelism — I do not add sleep and close the ticket

Why it works: Exactly. Flakes have causes: time, data, waits, isolation. Traces exist so you stop guessing.

• Use the trace and the seed.
• Check waits, data, time, parallel.
• Do not timeout your way out.
• Do not outsource the cause.

What makes a bug “actionable” for a developer in this interview?

The strongest answer: They can start without a meeting: steps, expected, actual, build, env, and a hint at scope (one user / all users, one locale) — I do not make them play detective for an hour

Why it works: Exactly. Actionable means start now. Guessing their revert is not your job.

• All the fields, no meeting required.
• Scope the blast radius if you can.
• Attach evidence.
• Do not prescribe a revert you cannot defend.

You have automated the happy path for POST /orders. Which negative cases go in next, and why those?

The strongest answer: No token and a wrong-role token — 401 against 403 — a missing required field, a malformed body, and an unknown product id; each has its own status and an error code clients branch on

Why it works: Right — and separating 401 from 403 is the check teams most often skip.

• One negative case per rule.
• Separate 401 from 403.
• Assert the error code, not the prose.
• Skip the combinatorial explosion.

A junior’s bug has a great video and no steps. How do you coach the rewrite?

The strongest answer: Numbered steps a stranger can follow, expected, actual, env/build, and then the video — I do not praise the video as a substitute

Why it works: Exactly. Teach the template. Video last, not instead.

• Steps a stranger can run.
• Expected and actual.
• Env and build.
• Video as attachment.

Which attachment actually helps a developer?

The strongest answer: The har / log / correlation id around the failure, a redacted screenshot, and the build — not a 4K screen recording of my whole desktop

Why it works: Exactly. Tight evidence. Desktop tours are how tickets get muted.

• Logs and an id.
• Redacted shot.
• Build number.
• No desktop documentaries.

Unit, integration, system, acceptance — what does each level catch, and who owns it?

The strongest answer: Unit catches logic inside one piece of code and belongs to developers; integration catches the seams between components; system tests the assembled product against its requirements; acceptance asks whether the business can use it

Why it works: Right — each level has its own defects and its own cost, and a bug found late usually names the level that was missing.

• Four levels, four defect types.
• Unit: logic in one place.
• Integration: the seams between parts.
• System and acceptance: product and fitness.

A country dropdown has 180 values. How do you test it without 180 cases?

The strongest answer: Equivalence: one typical, the empty, a long name, a right-to-left locale, and any country that changes a rule (tax, shipping) — plus the boundary of “none selected”

Why it works: Exactly. Classes, then the ones that change a rule. That is the craft.

• Group equivalents.
• Add the rule-changers.
• Add empty and long / RTL.
• Automate the rule-changers if you can.

The fix is on staging and the bug is still there. How do you reopen?

The strongest answer: On the same ticket, with the new build, the same steps, and what still fails — I do not open a duplicate “for visibility”

Why it works: Exactly. Same ticket, new evidence. Duplicates destroy history.

• Reopen, do not duplicate.
• New build + same steps.
• Keep the history.
• Do not escalate by clone.

What is a consumer-driven contract test for?

The strongest answer: To prove the provider still speaks the shape the consumer coded against — without standing up the whole UI or the whole fleet

Why it works: Exactly. It is a cheap conversation between two services. It is not the whole integration story.

• Prove the shape the consumer needs.
• Keep a few real integrations.
• Not traffic generation.
• Not an uptime check.

Legal must fix a rare, ugly consent string this week. The crash-on-rare-screen waits. How do you record that?

The strongest answer: High priority, moderate severity for the string; high severity, lower priority for the rare crash — I write the why so nobody “corrects” the fields overnight

Why it works: Exactly. Disagreement is information. Write the why.

• Let the fields disagree.
• Write the reason.
• Do not P0 everything.
• Compliance bugs are bugs.

The UI pack is 70% of runtime and finds 10% of bugs. What do you do?

The strongest answer: Move cases down — API, contract, unit — and keep UI for journeys a lower layer cannot see; I do not ask for twice the runners first

Why it works: Exactly. Runtime vs bugs is the rebalance trigger. Hardware is the last lever.

• Move cases down the pyramid.
• Keep UI for true journeys.
• Runners last.
• Do not fashion-ban layers.

A payments provider swap lands in five days. What does your plan lead with?

The strongest answer: The risks we cannot hide (double charge, decline, refund, webhook late), the env gaps, and a go / no-go that is not “we ran 400 cases”

Why it works: Exactly. Risk, gaps, a real go/no-go. Case count is a footnote.

• Lead with money risks.
• Name env gaps.
• Write a go / no-go.
• Do not sell zero residual.

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.

A legacy admin has no spec and few tests. How do you explore it before a rewrite?

The strongest answer: Charters on the money and permission paths, notes that become characterisation, and bugs only when I have an oracle — I do not boil the ocean in a week

Why it works: Exactly. Learn the island, protect the money, characterise. A rewrite still needs that map.

• Charter the money and authz.
• Turn notes into characterisation.
• Need an oracle to file.
• Do not gold-plate the accidents.

Your developers are eight hours away. What changes in the bug?

The strongest answer: It must be solvable without a meeting: data, logs, timezone, and a recording — I do not write “call me” as step 1

Why it works: Exactly. Async-actionable is the bar. Call-me is a luxury they do not have tonight.

• No “call me” as the repro.
• Attach what they will need at 2 a.m.
• Name timezone and data.
• Write for a stranger on their side.

You review a junior’s bug that will start a fight. What do you edit?

The strongest answer: Tone and missing fields — I keep their name on the ticket and I do not rewrite it as a dunk on the developer

Why it works: Exactly. Coach the fields and the tone. Credit stays with them.

• Fix fields and tone.
• Keep their name.
• No dunking.
• The goal is a fix, not a win.

Which boundaries do you treat as famous, not optional?

The strongest answer: Money (0, 0.01, rounding), dates (DST, month-end, leap), and empty collections — I do not only test “Tuesday with one item”

Why it works: Exactly. Money, time, empty. Those are where products bleed.

• Money edges.
• Calendar edges.
• Empty lists.
• Do not trust the framework to care.

A provider broke a field the mobile app needs. Where should that have failed?

The strongest answer: On the provider pipeline, verifying consumer contracts, before the merge — not in the app store a week later

Why it works: Exactly. The provider gate is the cheap place. Store ratings are the expensive place.

• Fail on the provider PR.
• Contracts before the store.
• UI is a late witness.
• Breaking changes need a version, not a shrug.

A hiring manager describes an internal tool being rebuilt and asks which kinds of testing you would run on it.

How do you answer without reciting a list?

The strongest answer: Start from the product’s risks — the money path, the data migration, the users on old machines — then name the types that address each of them, and say which ones I would skip and why

Why it works: Exactly — risks first, types second, and the nerve to name what you would not do is what makes it a senior answer.

• Risks first, types second.
• Name the product’s real risks.
• Match a type to each risk.
• Say what you would skip.

Leadership wants “fewer bugs.” What do you show instead of a raw count?

The strongest answer: Escapes by severity, age of the pack, and whether we found them before the store / the customer — a count of tickets is how you punish reporting

Why it works: Exactly. Escapes and impact. Punishing volume is how you go blind.

• Show escapes, not filings.
• Keep severity on the escape.
• Do not reward silence.
• Do not set a “file less” target.

Business UAT keeps finding things QA already knew. What do you change?

The strongest answer: I show them the residual list before UAT and I take their new oracles seriously — I do not compete on bug count

Why it works: Exactly. Share residual, harvest oracles. UAT is a partner, not a rival.

• Share residual before UAT.
• Treat new oracles as gold.
• Do not compete on count.
• Do not hide knowns.

Prod is down for a subset of users. You are in the channel. What is QA’s job in the first hour?

The strongest answer: Scope: who, which build, which path, a reliable repro if we can, and I do not start a process argument about ticket fields

Why it works: Exactly. Scope and repro. Pedantry and “I told you so” wait.

• Who / build / path.
• Repro if you can.
• Help mitigate; do not lecture.
• Save the I-told-you-so.

You are asked for a 2-year quality strategy. What are the first three pages?

The strongest answer: The risks you owe (money, trust, store), the paved road (envs, data, smoke), and the gates — not a tool catalogue and not a headcount plea without outcomes

Why it works: Exactly. Risks, road, gates. Tools and reorgs are appendices.

• Name the risks you owe.
• Describe the paved road.
• Write the gates.
• Put tools in the back.

How do you defend a thin UI pack to a board that wants “what users see”?

The strongest answer: Users see outcomes; most bugs are cheaper in API and unit — I show late bugs we moved down and the minutes we gave back, not a lecture about ice-cream cones

Why it works: Exactly. Show converted bugs and time returned. Contempt and hiding lose the room.

• Show bugs moved down.
• Show minutes returned.
• Keep a thin honest UI pack.
• Do not insult or hide.

What must a senior QA still show besides “I found a lot of bugs”?

The strongest answer: Judgement: a risk call, a bug a developer could act on, and a time they said “we can ship with this residual” — volume is not a loop

Why it works: Exactly. Judgement and residual. A pile of bugs is a junior tell if that is all they have.

• Hear a risk call.
• Read a bug they wrote.
• Hear a residual they accepted.
• Do not hire on volume or a tool.

You are writing the rule that decides whether a new test runs on every pull request or only nightly. What is the rule?

The strongest answer: On the pull request if it is fast, deterministic and covers something we would block a merge for; nightly for the slow, the broad matrix and anything whose failure needs a person — and every nightly failure gets an owner by morning or the test leaves the pack

Why it works: Right — and the ownership clause is what stops nightly becoming a graveyard nobody reads.

• Block a merge only for blocking risk.
• Slow and broad runs on a train.
• Every nightly failure gets an owner.
• Never demote a test to hide a number.

A severity-1 escaped. How do you run the learning?

The strongest answer: What oracle was missing, where a cheaper test could have lived, and one change to the road — I do not run a blame circle or a 40-page novel

Why it works: Exactly. Oracle, cheaper layer, one road change. Blame is not learning.

• Find the missing oracle.
• Put a cheaper test on the road.
• One change, owned.
• No blame circle.

You inherit two thousand written test cases and nobody can say which of them still matter.

What do you do with them?

The strongest answer: Find what actually runs, keep the cases tied to real risk and current behaviour, archive the rest with a note saying why, and make ownership and review part of writing a case from now on

Why it works: Exactly — usage and risk decide what survives, and ownership is what stops the graveyard growing back.

• Cases are inventory, not treasure.
• Keep what runs and matters.
• Archive the rest with a note.
• Give every case an owner.

The tracker is full of zombies: dupes, missing builds, “works for me.” What programme do you run?

The strongest answer: A writing bar, a weekly hygiene, and coaching — I do not buy a new tracker to flee the mess, and I do not mass-close to “clean the board”

Why it works: Exactly. The system is the writing. Tools and mass-close are how you lose history.

• Teach the writing bar.
• Hygiene with a human.
• Do not flee to a new tool.
• Do not mass-close.

An end-to-end test fails in CI against a deployed environment. The report shows a 500 from the checkout call, and nobody can find the matching request in the service logs.

What do you ask for, and from whom?

The strongest answer: A correlation id the test sets on every request, propagated through the services into their logs and traces, and printed in the test report — so a failure links straight to the server-side story of that exact request

Why it works: Right — and asking for it as a platform capability, not a favour per incident, is what makes it stick.

• Join the test to the server story.
• Set an id per request; propagate it.
• Print it in the test report.
• Ask for it as a platform capability.

How do you decide what humans still hold when automation is mature?

The strongest answer: Humans hold new risk, oracles that are still taste or law, and the sessions that teach the pack — automation holds the known repeats

Why it works: Exactly. A portfolio. Known repeats to the machines; attention to the new.

• Machines: known repeats.
• Humans: new risk and living oracles.
• Do not double-run the suite.
• Do not exile humans from the product.

UAT has become a second, unplanned test team. What do you install?

The strongest answer: A charter for UAT (acceptance, not hunting), a residual they see in advance, and a path for their finds into the same tracker — I do not let two boards compete

Why it works: Exactly. Govern the partnership. Two boards is how things drop.

• Charter UAT as acceptance.
• Show residual first.
• One tracker.
• Do not cancel the business.

What do you probe in an automation engineer that is not “write a page object”?

The strongest answer: Signal vs flake, isolation of data, and what they refused to automate — a framework tour is table stakes

Why it works: Exactly. Taste about what not to automate, and how they keep signal. That is senior.

• Ask what they would not automate.
• Ask how they kill flakes.
• Ask how data stays isolated.
• Skip the framework war.

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.