Test design: equivalence, boundary, decision tables

Test design techniques are systematic ways of choosing which inputs to test, out of the effectively infinite number available. They are also called black-box techniques, because they work from the specification rather than the code.

Three of them cover most everyday work:

• Equivalence partitioning. Split the inputs into groups the system should treat identically, then test one value from each group.
• Boundary value analysis. Test the edges of those groups, plus one value either side, because that is where off-by-one mistakes live.
• Decision tables. When several conditions combine, list the combinations so you can see which ones nobody considered.

The rest of this page is what each one looks like in practice.

Picture a laundry basket with two hundred items in it and a washing machine that takes thirty.

Nobody washes each item separately to be thorough. You sort into piles. Whites, colours, delicates, towels. Every item in a pile gets treated the same way, so washing one item from each pile tells you what you need to know about all of them.

Test design is that sorting, applied to inputs. A quantity field accepts a billion numbers, and you have an afternoon. The techniques below tell you which handful of numbers actually matter.

Sorting the laundry: equivalence partitioning

Take a quantity field on a basket that accepts 1 to 99.

The system does not treat 4 and 5 differently. Both are ordinary quantities, so they belong in the same pile. Here are the piles:

• Too low. 0 and anything negative.
• Valid. 1 to 99.
• Too high. 100 and above.
• Not a number. Letters, symbols, an empty field, a space.

Four piles, so four tests instead of a billion. Test 0, test 7, test 250, test "abc". If 7 works, 42 almost certainly works, and you have spent your afternoon elsewhere.

The edge of the diving board: boundary values

Bugs live at edges, because edges are where somebody wrote a comparison and had to choose between "less than" and "less than or equal to".

So for each boundary, test three values: just below, the boundary itself, and just above.

For 1 to 99 that gives you 0, 1, 2 and 98, 99, 100. Six tests, and in practice they find more defects than any other six you could pick.

When conditions combine: decision tables

Some rules only make sense in combination. For example, free delivery might depend on the order total, whether the customer is a member, and whether the item is bulky.

Three conditions, each yes or no, gives eight combinations. A decision table lists them so you can see which ones nobody has thought about.

You do not always test all eight. You do always look at all eight, and that is where you find the combination the specification forgot.

How you use these on a real story

1. Read the acceptance criteria and list the inputs. Fields, options, states, roles. The same reading that produces a case somebody else can run.
2. Sort each input into piles. Valid, invalid, empty, too big, wrong type.
3. Find the boundaries and take three values each. This is where most of your defects will come from.
4. List combinations only where conditions interact. Do not build a decision table for independent fields.
5. Add one realistic case. A customer buying six books with a discount code, not just the single-item path.
6. Then stop. These techniques are a floor, not a ceiling. The interesting bugs come from exploring afterwards.

A worked example

Here is the gift-card amount field at Willow Books, designed in about ten minutes.

Both findings came out of the design step. That is the part people skip when they go straight to clicking, and it is the cheapest testing in this whole layer.

How to show you know it

• A design sheet like the one above for a real field, with the questions it raised.
• A boundary bug. The 50.00 free-delivery case, or its equivalent in your product. Everybody recognises it.
• A decision table with a gap in it. Finding the unspecified combination is more valuable than running all eight rows.
• Judgement about a generated suite. Being able to say "this suite has 200 cases and no boundary values" is a genuinely useful review skill, especially when reviewing AI-written tests.