Testing Fundamentals interview questions
Testing Fundamentals questions a QA / manual tester can be asked, from first job to senior. Open one to see the strongest answer and why it works.
Walk me through the software development lifecycle and where testing belongs in it.
The strongest answer: Requirements, design, build, test, release, maintain — and testing starts at the first one: reviewing requirements for things nobody could test is far cheaper than finding them after the build
Why it works: Right — naming the phases and then saying quality work spans them is exactly what this question checks.
- Name the phases, then span them.
- Requirements, design, build, test, release.
- Review requirements for testability.
- The earliest defect is the cheapest.
What is a test plan for, in a room like this?
The strongest answer: To say what we will risk, what we will cover, what we will skip, and what “done” means — not a novel nobody reads
Why it works: Exactly. A plan is decisions: cover, skip, done. Length is not quality.
- Name the risk and the coverage.
- Name what you will skip.
- Define done.
- Keep it short enough to use.
The PM says “UAT will catch it, skip QA.” What do you say?
The strongest answer: UAT is the business accepting a flow; QA is whether the product is fit to offer them — they are not substitutes
Why it works: Exactly. Different questions, different people. Skipping QA dumps product risk on the business.
- QA = fit to offer.
- UAT = business accepts.
- Do not skip one and keep the signature.
- Say the risk out loud.
There is one day before release and 200 cases on the sheet. How do you choose?
The strongest answer: By risk: money, security, the change that actually landed, the paths users hit — I say out loud what I am skipping
Why it works: Exactly. Risk-based and honest about skips. Counts without risk are theatre.
- Pick by impact and by the diff.
- Say what you skipped.
- Do not optimise for case count.
- Do not fabricate completion.
What are the phases of the testing lifecycle, and what are entry and exit criteria for?
The strongest answer: Requirement analysis, planning, case design, environment and data setup, execution, closure — and entry and exit criteria say in advance what must be true to start a phase and to call it done
Why it works: Exactly — and agreed criteria are what stop “are we done?” becoming an argument on release night.
- Know the phases by name.
- Analyse, plan, design, set up.
- Execute, then close with a report.
- Agree entry and exit criteria first.
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.
When do you write a test plan versus an exploratory charter?
The strongest answer: A plan when the risk or the release needs a shared “cover / skip / done”; a charter when I am learning or hunting in a time box — I do not write a 20-page plan for a one-line copy change
Why it works: Exactly. Match the artefact to the risk. Both are professional.
- Plan = shared cover/skip/done.
- Charter = time-boxed learning.
- Scale the artefact to the risk.
- Do not file-only.
Staging has no payments provider; prod does. How do you talk about “tested”?
The strongest answer: I name the gap: we tested the stub, not the provider, and I say what that does and does not prove — I do not stamp “payments tested”
Why it works: Exactly. Parity gaps are part of the report. Honesty beats a fake stamp.
- Name what the env cannot prove.
- Do not stamp the missing layer.
- Push for a sandbox, not a shrug.
- Do not make prod the first payments test.
UAT signed off; you found a pay decline that leaves a pending charge. What do you do?
The strongest answer: I block or escalate with the impact — UAT sign-off does not retire a money defect — and I do not hide it because “the business already clicked”
Why it works: Exactly. UAT is acceptance, not a cloak. Money defects still gate.
- UAT ≠ a mute on QA.
- Money defects still escalate.
- Do not rewrite expected to pass.
- Say the residual risk if they override.
How do you show risk on a one-page plan so a PM can argue with it?
The strongest answer: A short heat: path × impact × uncertainty, with the skip list next to it — I invite the argument; I do not hide the skips in an appendix
Why it works: Exactly. Visible skips and a heat a human can fight with. That is the point.
- One page, paths and impact.
- Put skips on the page.
- Invite the argument.
- Do not hide residual risk.
QA, staging, and demo have three different feature flags. A bug is “fine in QA.” What is the lesson?
The strongest answer: Environments are part of the product; I compare flags and config before I close, and I say which world I tested
Why it works: Exactly. Config drift is a defect class. Name the world.
- Diff the flags.
- Name the env in the ticket.
- Treat drift as a bug.
- Do not close on the wrong world.
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.
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.
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.
A tiny diff touches tax calculation. The UI barely changes. Where do you spend the day?
The strongest answer: On the calculation, the boundaries, and the locales that change the rule — I do not spend the day on the unchanged chrome
Why it works: Exactly. Risk follows the diff and the money, not the pixels.
- Follow the diff.
- Money rules first.
- Smoke the chrome.
- Do not equate lines with risk.
Promoting a build QA → staging → prod keeps “losing” config. What do you insist on?
The strongest answer: The same artifact, config as data, and a diff you can read — I do not rebuild on each hop and I do not hand-edit staging to “make it work”
Why it works: Exactly. Same bits, declared config, a diff. Hand-edits are drift.
- One artifact.
- Config declared and diffable.
- No hand-edits to “make it work.”
- Automation should promote the same bits.
When is an environment “prod-like enough” to support a go?
The strongest answer: When it can prove the risks you claimed — same auth mode, a real-enough payment sandbox, the same flag defaults — not when the hostname feels similar
Why it works: Exactly. Enough means it can prove the claim. Wallpaper is not enough.
- Enough = can prove the risk.
- Auth and pay sandboxes matter.
- Flags must not lie.
- Do not make customers the env.
A PM asks you to delete the skip list so the plan “looks complete.” What do you do?
The strongest answer: I keep the skips visible and I offer a risk they can accept in writing — I do not make the plan look complete by lying
Why it works: Exactly. Visible residual is integrity. A pretty plan is how you get a surprise.
- Keep skips on the page.
- Offer a written accept.
- Do not pad.
- Do not sign a lie.
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.
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.
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.
A go/no-go meeting rubber-stamps every week. What do you change?
The strongest answer: A written residual, a named accepter, and the right to a no — I will not sit in a meeting that cannot say no
Why it works: Exactly. A gate that cannot fail is not a gate. Residual + a name + a no.
- Write residual.
- Name the accepter.
- Keep the right to no.
- Do not decorate a stamp.
How many environments does a company like this actually need?
The strongest answer: As many as have a job (dev, CI, staging, prod) with a named parity gap — I do not invent a seventh “QA2” because a squad was blocked once
Why it works: Exactly. Environments are expensive. Each needs a job and a named gap.
- Give each env a job.
- Name the parity gap.
- Do not breed QA2 without a job.
- Do not test only in prod.
Leadership wants a “quality score” out of 100. What do you refuse to invent?
The strongest answer: A single number that claims customers or hiring outcomes — I will give escape rate, flake budget, and residual, not a fake index
Why it works: Exactly. No invented percentiles, no fake index. Show the few numbers you can defend.
- Defendable numbers only.
- No fake 0–100 quality index.
- No invented industry percentiles.
- Do not edit the chart after the room.
When do you, personally, say “ship”?
The strongest answer: When the risks we named are proved or accepted in writing, the smoke is green on the artifact we will send, and I can say the residual in one sentence
Why it works: Exactly. Proved or accepted, right artifact, residual in one sentence. That is a senior yes.
- Proved or accepted.
- The real artifact.
- Residual in one sentence.
- A senior QA can say yes.
Give the one-sentence residual you would say in a go/no-go for a tax change.
The strongest answer: “We proved the rule countries we named on a sandbox; we did not prove a live filing, and legal accepted that gap.”
Why it works: Exactly. What you proved, what you did not, who accepted. That is residual.
- Proved / not proved / accepter.
- Name the gap.
- Do not say “quality is good.”
- Do not hide behind a count.