Test design techniques

These techniques are not vocabulary words. They are tools you apply to a real input space, out loud, while the interviewer watches. The candidates who advance do not recite definitions. They walk through partitions, name boundaries, and catch the combinations that single tests miss.

Equivalence partitioning

Split the inputs into groups that should all behave the same way, then test one value from each group instead of every possible input. One value per group is enough, because if the code treats the group as one, a single representative proves it.

Take an age field that accepts 18 to 65:

Partition A: below 18    -> invalid   (test with 10)
Partition B: 18 to 65    -> valid     (test with 30)
Partition C: above 65    -> invalid   (test with 80)

Three tests, not sixty-five. That is the efficiency you are selling.

Boundary value analysis

Bugs cluster at the edges, because code uses <, <=, >, >= and off-by-one mistakes are everywhere. So test right at the boundaries of each partition.

For the same 18 to 65 field, you check the values on both sides of each edge:

Lower edge: 17 (invalid), 18 (valid)
Upper edge: 65 (valid), 66 (invalid)

Pair this with equivalence partitioning every time. Partitioning picks the groups, boundary analysis hardens the edges. Together they cut test count while maximizing the bugs you find.

Decision tables

When the output depends on a combination of conditions, a decision table lays out every combination so none slip through. This is where you find the bugs that single-axis tests miss.

Free shipping if the order is over fifty dollars OR the user is a member:

Four rows, four tests, and the "No / No" row is the one teams forget.

State transition testing

Some features behave differently depending on what state they are in. Model the states and the moves between them, then test the valid moves and, just as important, the invalid ones.

An order moves through states like this:

Cart -> Placed -> Shipped -> Delivered
              \-> Cancelled (only before Shipped)

The interesting tests are the illegal transitions: can you cancel an order that already shipped? Can you ship a delivered order? Those are where real bugs hide.

Error guessing

This one is experience, not a formula. You guess where things break because you have seen it before: empty fields, a zero, a negative number, a huge paste, an emoji, a leading space, a double-click on submit.

Error guessing fills the gaps the systematic techniques leave. It is not a substitute for them. It is the seasoning on top.

How to use them in an interview

When asked to design tests for something like a discount calculator, do not list techniques. Apply them in motion: "I would partition the order amounts, test the boundaries around the discount threshold, and build a decision table for the combinations of coupon and membership."

Naming the technique while you use it on their concrete example is the signal. It shows you have a repeatable method, not just memorized terms.