Test Design
You cannot check every possible input — there are infinitely many. Test design answers the question "which few checks will catch most of the defects". It is a set of black-box techniques that turn a vague "test the form" into a finite, justified list of cases, each closing its own risk.
The foundation is the test case itself as a unit (unambiguous, reproducible, independent) and two base techniques: equivalence partitioning compresses homogeneous inputs to a single representative, while boundary-value analysis finishes off the edges where defects cluster. Beyond that come decision tables for interacting conditions, checklists for a quick sweep of a screen, and the habit of questioning a requirement first and designing only afterward. The topic closes with worked "interview classics": a calculator, a search bar, email, negative API cases. The full map lives in the layers below.
Topic map
- Test-case structure — the mandatory fields and three properties: unambiguous, reproducible, independent.
- Equivalence partitioning — split inputs into classes and test one representative of each.
- Boundary-value analysis — check the edges of ranges where off-by-one defects cluster.
- Decision tables — cover combinations of interacting conditions, one column per rule.
- Checklist design — a grouped sweep of a screen from positive to negative and edge cases.
- Requirements gaps — question the spec first, find holes and overlaps, then test.
- Calculator test design — the classic task on boundaries, classes, and field limits.
- Verifying email validity — why a regex is necessary but not sufficient, and what confirmation proves.
- Search-bar test cases — positive, negative, and security in the right order.
- Negative API scenarios — the levels of an invalid request and the right 4xx code for each.
- Test design from an HTTP response — a server rule, an unexpected code, and load versus stress.
Common traps
| Mistake | Consequence |
|---|---|
| Omitting the explicit expected result in a case | The run is not reproducible — "pass/fail" comes down to guessing |
| Testing only the exact boundary, not values just inside/outside | Off-by-one defects at the edge go unnoticed |
| Defining only valid classes, forgetting the invalid ones | Half the coverage — error handling — drops out |
| Using a decision table for a single independent input | Extra complexity where equivalence classes suffice |
| Starting with negative or extreme values instead of positive | You have not proven the base function works at all |
| Designing before resolving the spec gaps | Tests cement an ambiguous or contradictory requirement |
| Thinking a regex proves email validity | A syntactically valid but undeliverable address is taken as valid |
| Expecting a 500 instead of a precise 4xx for invalid input | An error-handling defect masquerades as an "expected" failure |
Interview relevance
Test design is the core of a tester interview. You are almost always given a practical task: "design cases for an age field / a calculator / a search bar". What is checked is not memorized definitions but method — did you start by clarifying requirements, apply classes and boundaries, remember negative and security cases, state the expected result in every case.
Typical checks:
- Equivalence classes and boundary values on a concrete task, not in theory.
- The order of work — clarify requirements, positive, negative, boundaries, security.
- When a decision table is needed and when independent classes suffice.
- The ability to spot a gap or contradiction in a spec before writing any tests.
Common wrong answer: "I will test all possible values to be sure". Exhaustive enumeration is impossible and unnecessary — the power of test design is covering the same risk as an infinite sweep with a handful of representatives and boundaries, while explicitly naming the expected result of each check.