Testing, Validation & Quality Assurance

Test Case Design Techniques

18 min Lesson 4 of 10

Test Case Design Techniques

Writing test cases is a design activity, not a mechanical one. A naive approach — "test everything with every possible input" — is mathematically impossible even for modest systems. A clinic booking form with a date field, a time dropdown, and a patient-age field has billions of potential input combinations. The analyst's job is to select a minimal, representative set of inputs that gives maximum confidence with minimum effort. Three techniques make that selection principled rather than arbitrary: equivalence partitioning, boundary value analysis, and decision tables.

Equivalence Partitioning

Equivalence partitioning (EP) is built on a single insight: if the system handles one value in a group the same way it handles every other value in that group, you only need to test one representative from that group. Each group is called an equivalence class or equivalence partition.

For every input, you divide the value space into valid partitions (inputs the system should accept) and invalid partitions (inputs the system should reject). You then pick one test value from each partition.

Example — Online Store: Discount Code Field. A discount code must be exactly 8 alphanumeric characters. The partitions are:

Valid: exactly 8 alphanumeric characters (e.g., SAVE2024).
Invalid — too short: fewer than 8 characters (e.g., SAVE).
Invalid — too long: more than 8 characters (e.g., SAVE20244).
Invalid — special characters: contains symbols (e.g., SAVE#24!).

Instead of testing every possible 8-character string, you test one value per partition — four test cases cover the full logical space. The system either validates codes correctly or it does not; hundreds of valid-but-different codes all fall in the same partition and behave identically.

Tip: When identifying partitions, always ask: "Would the system process these two inputs through the same code path?" If yes, they belong in the same partition and you need only one test.

Boundary Value Analysis

Experience shows that defects cluster at the edges of equivalence partitions, not in the middle. An off-by-one error (> written instead of >=) will only be caught if you test the exact boundary. Boundary Value Analysis (BVA) extends EP by deliberately testing the values at and around partition boundaries.

The classic BVA rule tests three points at each boundary:

Just below the boundary (the last value in the lower partition).
At the boundary (the exact dividing value).
Just above the boundary (the first value in the upper partition).

Example — Logistics Firm: Parcel Weight. A courier system charges Standard rate for parcels 0.1–5.0 kg and Express rate for 5.1–20.0 kg. Parcels above 20.0 kg are rejected. BVA test points:

Standard/Express boundary: test 4.9 kg (Standard), 5.0 kg (Standard), 5.1 kg (Express).
Express/Reject boundary: test 19.9 kg (Express), 20.0 kg (Express), 20.1 kg (Reject).
Lower edge: test 0.0 kg (Reject — below minimum), 0.1 kg (Standard — minimum valid weight).

Nine carefully chosen values expose any boundary mis-coding. Random mid-range values (3 kg, 10 kg) would never find the bug hiding at exactly 5.0 vs 5.1 kg.

Boundary Value Analysis applied to parcel weight — test points cluster at every partition boundary, not randomly in the middle.

Decision Tables

Decision tables are the right tool when system behavior depends on combinations of conditions rather than a single input range. They force you to enumerate every logically distinct combination — revealing cases the requirements forgot to specify and exposing contradictions where two rules produce conflicting actions.

A decision table has four quadrants:

Condition stubs (top-left) — the list of input conditions.
Condition entries (top-right) — Y/N (or specific values) for each condition in each column/rule.
Action stubs (bottom-left) — the list of possible system actions.
Action entries (bottom-right) — a checkmark or X for which actions fire under each rule.

For n binary conditions you get at most 2ⁿ rules. Analysts then look for rules that can be merged (when one condition does not affect the action, it can be replaced with a dash "—") — this is called collapsing the table.

Example — Clinic Booking: Appointment Confirmation Logic. A clinic system must decide how to confirm an appointment based on three conditions: (1) the patient has a valid insurance policy, (2) the requested slot is available, and (3) the patient has no outstanding unpaid invoices.

Decision table for clinic appointment confirmation — 3 conditions yield 6 collapsed rules; each column is one executable test case.

Reading the table: R1 (insured, slot free, no debt) → Confirm booking. R2 (insured, slot free, has debt) → Payment alert. R3 (insured, slot full, no debt) → Waitlist. R4 (insured, slot full, has debt) → Payment alert. R5 and R6 collapse into a single rule: no insurance → always redirect to self-pay regardless of slot or invoice status (the dash "—" marks the irrelevant conditions). With three binary conditions the theoretical maximum is eight rules (2³), but collapsing reduces it to six distinct test cases.

Gap analysis: As you fill in a decision table, look for columns where no action is marked. These represent system states the requirements never specified — the developer will be forced to make an undocumented business decision. Surface those gaps before development begins, not during UAT.

Choosing the Right Technique

In practice, these three techniques complement each other. Use equivalence partitioning as the starting point — it defines the categories you need to cover. Apply boundary value analysis wherever a partition has a numeric or ordered boundary — it finds the off-by-one bugs EP misses. Reach for decision tables when a business rule combines two or more conditions — any time you hear the word "if … and … then" or "unless … or …" in a requirement, a decision table is almost certainly the right tool.

Efficiency rule: Each column of a complete decision table is a ready-to-execute test case. The table doubles as test documentation — you can hand it directly to a tester without rewriting anything.