Test Design interview questions
Test Design questions a QA / manual tester can be asked, from first job to senior. Open one to see the strongest answer and why it works.
A field accepts 1–100. Which values do you try first?
The strongest answer: 0, 1, 100, 101, and an empty / non-numeric — the edges and just outside, not 47 because it “feels typical”
Why it works: Exactly. Boundaries and just-outside catch the off-by-one. The middle is a later sample.
- Min, max, just inside, just outside.
- Empty and the wrong type.
- Do not start in the middle.
- Automation should encode those edges too.
You have an hour to explore a new checkout. How do you start?
The strongest answer: With a charter — what I will cover, what I will not, and how I will note findings — then I time-box and debrief, I do not click at random
Why it works: Exactly. Exploration is designed: charter, time, notes. Random clicking is not a method.
- Write a charter.
- Time-box and take notes.
- Exploration is a method, not chaos.
- Debrief what you covered and what you skipped.
A case reads “test the form.” How do you rewrite it?
The strongest answer: Given a signed-in user with an empty cart, when they submit without a postcode, then they see a field error and cannot pay — one behaviour, checkable
Why it works: Exactly. One behaviour, given / when / then, an oracle. That is a case.
- One behaviour per case.
- Name the setup.
- Name the check.
- Same shape helps automation later.
A candidate says “we automated everything, so we do not need exploratory.” What is wrong?
The strongest answer: Automation repeats what we already thought to ask; exploration finds the thing we did not encode — you need both
Why it works: Exactly. Scripts are memory. Exploration is attention. Neither replaces the other.
- Automation = known questions.
- Exploration = new questions.
- Keep both.
- A grid is not a strategy.
What is the difference between a test scenario, a test case and a checklist?
The strongest answer: A scenario names what you will test, a case spells out the data, the steps and the expected result so anyone can run it, and a checklist is a prompt for things you judge as you explore
Why it works: Right — and knowing which one you need saves writing fifty cases where a checklist and an hour would do.
- Three tools, three jobs.
- Scenario: what you will test.
- Case: data, steps, expected result.
- Checklist: prompts while exploring.
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.
How do you make exploratory work visible to a team that only trusts case counts?
The strongest answer: Session-based: charter, time, notes, and a debrief of bugs / questions / coverage — I report sessions, not “I clicked around”
Why it works: Exactly. Sessions are auditable without killing the method.
- Charter + time + notes.
- Debrief coverage and questions.
- Report sessions as the unit.
- Do not fake case counts.
The spec is silent. The screen looks “off.” How do you decide it is a bug?
The strongest answer: I name the oracle I used — last good build, a sister flow, the platform guideline, or a question to the PM — I do not file “I do not like it” as a defect
Why it works: Exactly. Oracles can be weak; they must be named. Taste is a question, not a defect by default.
- Name your oracle.
- Ask when the spec is silent.
- Taste → question, not automatic bug.
- Do not weaponise priority.
Shipping is free when the basket is over a threshold, or the customer is a member, or a promo code applies — and the rules interact.
How do you design the tests?
The strongest answer: Build a decision table — the conditions as rows, the combinations as columns, the expected outcome in every cell — test each column, and drop the combinations the business says cannot occur
Why it works: Exactly — a decision table makes the missing combination visible, and that is where this kind of rule always breaks.
- Rules that combine need a table.
- Conditions as rows.
- Allowed combinations as columns.
- Expected outcome in every cell.
An order moves through created, paid, shipped, delivered and cancelled.
How do you design the tests?
The strongest answer: Draw the states and the allowed moves, test each legal transition, then attack the illegal ones — cancelling a delivered order, paying twice, shipping something unpaid — because nobody implemented those
Why it works: Right — a state diagram turns “what else could happen” into a finite list, and the illegal moves are where the money bugs live.
- Draw the states and the moves.
- Test each legal transition.
- Attack the illegal ones.
- Include double and out-of-order events.
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.
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 feature uses on-device ML. Your pack has no cases. How do you start?
The strongest answer: A charter: what “wrong” looks like, privacy of the input, and a fallback when the model misses — I do not wait for a perfect golden set
Why it works: Exactly. New risk, new charter. Fallback and privacy are oracles you already have.
- Charter the miss and the fallback.
- Watch privacy of the input.
- Do not wait for a lab set.
- Do not P0 every miss.
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.
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.