Functional Testing interview questions
Functional Testing questions a QA / manual tester can be asked, from first job to senior. Open one to see the strongest answer and why it works.
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.
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.
A test fails one in five times. What do you do?
The strongest answer: Treat it as a defect in the test or the product — isolate, quarantine if I must, and do not hide it behind retries until the pipeline is green
Why it works: Exactly. A flake is unpaid debt. Quarantine is a bandage; retries as a strategy are a lie.
- A flake is a bug (test or product).
- Quarantine with an owner.
- Do not retry your way to green.
- Do not delete the only witness.
What is the difference between smoke testing and sanity testing?
The strongest answer: A smoke is a short fixed set of checks that the build is worth testing at all; a sanity check is a narrow look at whatever just changed, to see it behaves before going deeper
Why it works: Right — one asks “is this build testable?”, the other asks “did this change do what it claims?”.
- Two questions, not two tools.
- Smoke: is the build worth testing?
- Sanity: did this change behave?
- Smoke is fixed; sanity follows the diff.
The only written case is “user pays successfully.” What is missing?
The strongest answer: The misses: cancel, decline, timeout, back button, empty cart, the user who pays twice — a plan that is only the demo is not a plan
Why it works: Exactly. The product is the failures too. Interviewers listen for that.
- Write the failure paths.
- Include cancel, decline, timeout.
- Include navigation away mid-pay.
- A demo path is a start, not a plan.
The regression pack is 12 hours long. What do you do?
The strongest answer: Cut by risk and by what automation already owns; keep a short smoke humans run, and I do not keep dead cases “in case”
Why it works: Exactly. A pack that cannot run will not run. Slim it on purpose.
- Cut dead and low-risk cases.
- Let automation own the boring repeats.
- Keep a human smoke.
- Do not automate the pile without review.
A suite is 15% red from two flaky tests. The team wants CI green for a demo. What do you do?
The strongest answer: Quarantine those two with an owner and a ticket, keep the rest red-when-wrong, and I do not mute the whole job
Why it works: Exactly. Surgical quarantine. The pipeline must still be able to fail.
- Quarantine the offenders.
- Name an owner.
- Do not mute CI.
- Do not delete for a demo.
A one-line change to the tax rate lookup is ready. Running the whole regression pack takes most of a day.
How do you choose what to run?
The strongest answer: Follow what the change touches — everything that reads tax, the money paths around it, and the pack’s highest-risk cases — then write in the ticket what I ran and what I did not
Why it works: Exactly — impact-driven scope plus a written record of what was skipped is what makes a partial run defensible.
- Scope regression by impact.
- Trace what the change touches.
- Add the highest-risk money paths.
- Write down what you skipped.
A UI test fails when the suite is loaded. Alone it passes. What is your first hypothesis?
The strongest answer: Shared state or a race — leftover data, a leftover cookie, a navigation that did not settle — not “the grid is haunted”
Why it works: Exactly. Isolation and waits-for-conditions. Haunted grids are a shrug.
- Suspect shared state.
- Wait for a condition, not a clock.
- Do not blame the grid first.
- Do not sleep your way out.
Who owns the regression pack when every squad ships weekly?
The strongest answer: A platform owner for the paved smoke, and squads for their risk — a 12-hour shared novel nobody loves is not ownership
Why it works: Exactly. Shared smoke, local depth. A rotting novel is how weekly dies.
- Paved smoke, owned.
- Squads own their risk.
- Humans + automation.
- Do not leave a novel to “whoever.”
How do you talk about flakes with a team that wants “CI always green”?
The strongest answer: Green means signal; I will give a flake budget, quarantine with owners, and I will not sell always-green via retries
Why it works: Exactly. Signal over vanity green. A budget makes the trade visible.
- Define a flake budget.
- Owners on quarantines.
- Do not retry-to-green.
- Keep the signal.
Where does integration testing stop and end-to-end begin, and which defects does each catch?
The strongest answer: Integration joins two or three real components to test the seam — contract, mapping, error handling; end-to-end drives the whole assembled system as a user and catches broken journeys and bad configuration
Why it works: Right — different scope, different defect classes, and a very different cost per finding. That is what decides where a check belongs.
- Scope decides the defect class.
- Integration: seams and contracts.
- End-to-end: journeys and configuration.
- Put each check at its cheapest level.
A “flaky” test fails when two users check out the same SKU. What might it be?
The strongest answer: A real race in the product — I will try to reproduce outside the tool before I blame the harness
Why it works: Exactly. Some flakes are the product under concurrency. Prove it outside the tool.
- Reproduce without the harness if you can.
- Concurrency is a product class.
- Do not sleep the API as a strategy.
- Do not delete the witness.
You will treat pipeline signal like an SLO. What does that sound like?
The strongest answer: A max flake rate, a max time-to-quarantine, and a halt on adding UI tests while the budget is spent — I do not celebrate a green week we bought with retries
Why it works: Exactly. A budget and a brake. Vanity green is not an SLO.
- Set a flake rate.
- Time-box quarantine.
- Brake new UI tests when broke.
- Do not buy green with retries.
A vendor wants to replace your pack with their “AI test generator.” What is your bar?
The strongest answer: It must keep signal, own flakes, and leave artefacts humans can read — I do not swap a pack I can defend for a black box that asserts “looks good”
Why it works: Exactly. Signal and readable artefacts. Demos and slides are not a pack.
- Keep human-readable oracles.
- Measure signal, not a demo.
- Do not buy a black box on a slide.
- Do not refuse tools on principle.