Test design techniques (so you test smart, not endless)

Here's a problem. A simple age field accepts numbers from 0 to 120. How many values could you type? Whole numbers, decimals, negatives, gigantic numbers, letters, blanks, emoji. The combinations are effectively endless. You will never finish. So the real skill of a tester isn't running tests: it's choosing which handful of tests is worth running out of the infinite pile.

That's what test design techniques give you: small, proven recipes for picking representative cases that catch the most bugs for the least effort. These are all black-box techniques, meaning you design them from how the software is supposed to behave, without needing to see the code inside.

Equivalence partitioning: group, then test one of each

The idea is simple: if a bunch of inputs all should be treated the same way, you only need to test one of them. Sort your inputs into groups ("partitions") where everything in a group behaves alike, then pick one value from each group as your representative.

Take that age field accepting 0 to 120. The inputs fall into three partitions: too low (anything below 0), valid (0 through 120), and too high (above 120). Instead of testing hundreds of numbers, you test one from each group: maybe -5, 40, and 200. If the app handles those three correctly, it almost certainly handles every other value in the same group too.

Boundary value analysis: bugs love the edges

Here's a truth you can almost set your watch by: bugs cluster at the edges of a range, not in the comfortable middle. A developer writes if (age > 18) when they meant >= 18, and suddenly an 18-year-old is wrongly rejected. The middle of the range works fine; only the boundary breaks. So you test the boundaries deliberately.

The classic example: a form accepts ages from 18 to 60 inclusive. Boundary value analysis says test the values right on and right around each edge: the boundary itself, one below, and one above:

Six well-chosen values, and you've cornered nearly every off-by-one mistake a developer could make on this field. Pair this with equivalence partitioning and you get a tiny, deadly-effective set: a representative from each group, plus the edges between them.

Decision tables: when rules combine

Some behaviour depends on several conditions at once, and the rules tangle together. "Free shipping if the order is over $50 or the customer is a member." Now you have two conditions and four combinations. A decision table lays every combination out in a grid so you can't accidentally forget one.

Each row becomes one test case. The table makes gaps obvious: if you'd only thought to test "big order" and "member", you'd have missed the small-order-non-member row: the one that's supposed to charge shipping, and the one most likely to be wrong.

State transition: when order matters

Sometimes the software behaves differently depending on what state it's in, and the same action does different things at different times. Think of an ATM card: after three wrong PINs it gets blocked, and a fourth attempt (even with the right PIN) does nothing. The action ("enter PIN") isn't right or wrong on its own; it depends on the history.

State transition testing maps these states and the moves between them, then checks both the moves that should be allowed (a wrong PIN nudges you toward Blocked) and the ones that shouldn't (a correct PIN while Blocked must still refuse). The bugs hide in the transitions nobody drew on the diagram.