11 QA Test Design Interview Questions and Answers

Short answer: Equivalence partitioning splits the input domain into groups where the system behaves identically, so testing one representative per group covers the whole group. For age 18–65 you take one valid class and three or four invalid ones.

In depth:

1. The idea — if 20 and 40 hit the same code path, one of them covers the whole class; enumerating every value is pointless.
2. Valid class — 18–65 (representative, e.g. 30).
3. Invalid classes — always several: too low, too high, not a number, empty.
4. Savings — instead of enumerating 48 valid values (and infinitely many invalid ones) you get 5 meaningful tests.

⚠️ Common mistake: naming only the valid class and forgetting the invalid ones — those are exactly where the interviewer wants you to recall "abc", the empty field, and the boundaries.

Short answer: Boundary value analysis (BVA) tests values at the edges of equivalence classes and just around them, because defects cluster at boundaries. BVA is a direct extension of equivalence partitioning: first split the domain into classes, then aim at their edges.

In depth:

1. Why edges — typical bugs live in >= vs > conditions, off-by-one errors, wrong range limits.
2. Three-point rule — for each boundary take the value just below it, on it, and just above.
3. For 18–65 — lower boundary: 17 / 18 / 19; upper: 64 / 65 / 66.
4. Link to EP — classes tell you which groups to test; BVA tells you where inside a group the error hides.

     invalid │ valid 18..65 │ invalid
   ──────────┼──────────────┼──────────
          17 │ 18        65 │ 66
         ↑no │ ↑yes   ↑yes  │ ↑no

⚠️ Common mistake: checking only one side of a boundary (just 18, not 17) or only the valid side — then an off-by-one on the upper bound sails straight into production.

Short answer: Pairwise testing is a technique where, instead of the full combinatorial product of parameters, you cover every pair of values. It solves combinatorial explosion: the full matrix grows multiplicatively, while most bugs are triggered by the interaction of no more than two parameters.

In depth:

1. The problem — 3 browsers × 3 OSes × 3 locales = 27 combinations; a fourth parameter makes it 81, a fifth — 243.
2. The hypothesis — empirically most defects depend on a single parameter or a pair, not a three-way coincidence.
3. The solution — a test set where every pair of values (e.g. Chrome+Windows, Chrome+macOS) appears at least once.
4. The result — 27 combinations shrink to ~9 while still covering all pairs (generated by tools like PICT/Allpairs).

⚠️ Common mistake: failing to name the trade-off. Pairwise saves effort but won't catch bugs that require three or more parameters to align — say that honestly to the interviewer.

Short answer: You use a decision table when the outcome depends on a combination of several independent conditions and you need to cover all their combinations systematically. It lays out conditions and expected actions as a matrix and catches missing business-rule combinations.

In depth:

1. When it fits — the requirements contain "if… AND… OR…" with several flags (loyalty, amount, promo code).
2. Structure — condition rows on top, action rows below; each column is one rule.
3. Completeness — N boolean conditions give 2^N combinations (here 2³ = 8); "don't care" (—) collapses them into fewer rules.
4. Value — you can visually see which combination the requirements never describe.

⚠️ Common mistake: testing conditions in isolation instead of their combinations — the bug usually lives at the intersection of rules ("Gold + promo code"). A staple question in banking and e-commerce rounds.

Short answer: State transition testing applies to systems where an object moves through a set of statuses and behavior depends on the current state. You test the valid transitions, the forbidden transitions, and the edge (initial/terminal) states.

In depth:

1. The model — an order lives along a chain: New → Paid → Shipped → Delivered.
2. Valid transitions — every allowed step must work (Paid → Shipped).
3. Forbidden transitions — the system must reject the impossible (Delivered → New, paying twice Paid → Paid).
4. Edge states — what happens in the initial (New, unpaid) and terminal (Delivered — nowhere further) states.

  New ──pay──► Paid ──ship──► Shipped ──deliver──► Delivered
   │                                                   │
   └── cancel ──► Cancelled            (Delivered ─X─► New) forbidden

⚠️ Common mistake: testing only the "happy" status path and never exercising forbidden transitions — the ability to illegally roll a status back (shipping an already-delivered order) is exactly where the hole usually is.

Short answer: A full test case with preconditions, steps, and expected result is needed where reproducibility and traceability matter: audit, compliance, complex multi-step flows. A lightweight checklist is enough for regression on stable features and exploratory sessions, where speed matters more.

In depth:

1. Test case — a formal document anyone can replay step by step; expensive to write and maintain.
2. Checklist — a list of what to verify, without detailed steps; fast to draft, flexible to use.
3. Selection criterion — maintenance cost versus the need for rigor and auditability.

⚠️ Common mistake: dragging heavy formal test cases into places where a checklist suffices and drowning in documentation upkeep instead of actual testing. The interviewer wants to hear you justify the choice under time pressure.

Short answer: A test strategy is a high-level, reusable approach to testing at the organization or product level (which kinds of testing, tools, standards). A test plan is a concrete document for a specific project or release: scope, timeline, resources, risks, exit criteria.

In depth:

1. Level — the strategy sets the principles of "how we test in general"; the plan grounds them in a specific release.
2. Lifespan — the strategy is stable and changes rarely; the plan lives from release to release.
3. Contents — strategy: approaches, test types, environments, standards; plan: what, who, when, with what, readiness criteria.

⚠️ Common mistake: using the terms interchangeably. Calling a plan a strategy in an interview instantly reads as shallow process knowledge.

Short answer: I use a risk-based approach: critical business paths and money first, then the most frequent scenarios, then recently changed and historically buggy code. The goal is to burn down the most risk in the time left, not to "test everything."

In depth (priority order):

1. Critical business paths — what the product can't earn without: login, checkout, payment.
2. Frequently used features — where most users are, a bug costs more.
3. Regulatory and payment flows — the cost of a mistake is not only money but fines.
4. Recently changed code — fresh edits = fresh defects; I look at the release diff.
5. Historically problematic areas — modules with past incidents in the bug tracker.
6. Everything else — if time remains; otherwise a conscious risk.

risk = probability of defect × impact
sort tests by descending risk ─► go top-down until the day runs out

⚠️ Common mistake: answering "I'll test everything important" with no framework. The interviewer wants the prioritization criterion (risk = probability × impact) and a deliberate call on what you will NOT test.

Short answer: Automate stable, repeatable, critical checks with high ROI — regression, smoke, API. Leave manual what's expensive or pointless to automate: fast-changing UI, one-off exploratory checks, and judging visual nuance and usability.

In depth:

1. Automation candidates — run often, stable interface, deterministic result, expensive to run by hand.
2. Keep manual — new or unstable UI (the test breaks before it pays off), exploratory, visual and UX.
3. The criterion — ROI: savings from repeated runs minus the cost of writing and maintaining the test.

⚠️ Common mistake: answering "automate everything" without weighing maintenance cost. A test against unstable UI breaks every sprint and eats more time than it saves — that's negative ROI.

Short answer: Positive tests verify the system works on valid data (the happy path). Negative tests verify the system handles invalid input correctly — it doesn't crash, doesn't let garbage through, and shows a clear error.

In depth:

1. Positive — valid input yields the expected result: user@mail.com is accepted.
2. Negative — invalid input is rejected with a clear error, not a 500: empty, missing @, injection.
3. Balance — there are usually more negative scenarios than positive: invalid states always outnumber valid ones.

⚠️ Common mistake: covering only the happy path and reporting "it works." Real bugs and vulnerabilities live in negative scenarios — empty input, special characters, injections.

Short answer: A use case describes how an actor achieves a goal while interacting with the system: the main flow plus alternative and exception flows. A test case is a concrete check with steps and an expected result. One use case spawns many test cases.

In depth:

1. Use case — requirements level: actor, preconditions, main flow, alternatives, exceptions. Answers "what the system should do."
2. Test case — verification level: concrete data, steps, expected result. Answers "how to confirm it works."
3. The link — one use case "Pay for order" yields test cases: successful payment, insufficient funds, expired card, gateway timeout.

   Use case "Pay for order"
            │
   ┌────────┼─────────┬──────────────┐
   ▼        ▼         ▼              ▼
 success  no funds  card expired  timeout
 (TC-1)   (TC-2)     (TC-3)       (TC-4)

⚠️ Common mistake: treating a use case and a test case as the same document under different names. A use case describes behavior, a test case verifies it; one scenario always fans out into a spread of checks, including negative ones.