Test design techniques

You can never test every input, so you need a reliable way to pick a small set of tests that still finds most defects. Test design techniques give you that. Interviewers like them because the answers have numbers you can check: how many partitions, which boundary values, how many rules. This article works through each technique with one example.

Equivalence partitioning

Split the possible values into groups, called partitions, that the system should handle the same way. If one value in a partition finds a defect, any other value in it should find the same defect, so one test per partition is enough.

Example: a quantity field accepts whole numbers from 1 to 10. There are three partitions: 0 or less (invalid), 1 to 10 (valid) and 11 or more (invalid). Three tests, such as -2, 5 and 15, cover them all. The two invalid sides are separate partitions because the code might check the lower limit and forget the upper one.

A business rule can split a valid range further. If orders from 1 to 10,000 rupees are accepted and orders of 500 or more ship free, the valid range splits at 500. That gives four partitions: 0 or less, 1 to 499, 500 to 10,000, and more than 10,000.

Boundary value analysis

Developers often get edges wrong: "<" written instead of "<=", or a limit that is off by one. Boundary value analysis (BVA) tests the smallest and largest value of each partition.

In 2-value BVA you test each boundary and its closest neighbour in the next partition. For 1 to 10 that is 0, 1, 10 and 11. In 3-value BVA you test each boundary and both of its neighbours, so 2 and 9 are added.

The extra value catches real bugs. Suppose "password length at least 8" is wrongly coded as "length equals 8". Lengths 7 and 8 both behave correctly, so 2-value BVA passes. Length 9 is wrongly rejected, and only 3-value BVA tries it.

Decision table testing

Use a decision table when the result depends on a combination of conditions. Each condition is a row, each combination is a column (a rule), and each rule has an expected result.

Rule	R1	R2	R3	R4
Member?	Yes	Yes	No	No
Order 1,000 or more?	Yes	No	Yes	No
Discount	15%	5%	5%	0%

Two yes-or-no conditions give 2 x 2 = 4 rules, so four tests. Three conditions give 2 x 2 x 2 = 8. You can drop impossible columns and merge columns where a condition does not change the result. A column nobody can fill in is a gap in the requirement, which is a question for the product owner (the person who decides what the product should do).

State transition testing

Use this for anything that moves between states: an order, a user account, a document. Draw the states and the events that move between them.

All states coverage visits every state at least once. Valid transitions coverage, also called 0-switch coverage, uses every valid transition at least once; here that means five transitions, and one long test can cover them in a row. Testers also try invalid transitions, events that should be refused in a state, such as approving a document that is still a draft. Try one invalid transition per test, so one failure cannot hide another.

Statement and branch coverage

White box coverage (white box testing is explained in test levels and test types) measures how much of the code your tests run. A statement is one instruction in the code, often one line. A branch is one outcome of a decision, such as the "true" and the "false" side of an IF. The code below is pseudo-code: plain steps written like code, not in any real language.

discount = 0
IF amount > 1000 THEN
    discount = 10
END IF
total = amount - discount

One test with amount 2000 runs every statement, so statement coverage is 100%. The "false" side of the IF never runs, so branch coverage is not complete; add a test with 1,000 or less. Full branch coverage always gives full statement coverage, but full statement coverage does not give full branch coverage.

Experience-based techniques

Error guessing uses your knowledge of common mistakes to guess where bugs hide: empty input, special characters, time zones, double clicks. Exploratory testing designs and runs tests at the same time, often in timed sessions with a charter (a one-line goal) and a debrief. Monkey testing sends random input with no product knowledge; it finds crashes but cannot tell whether behaviour is correct.

How to answer in an interview

Name the technique, give its rule in one sentence, then work an example aloud with real numbers: "For 18 to 60, the partitions are below 18, 18 to 60 and above 60; the 2-value boundaries are 17, 18, 60 and 61."

Common mistakes

• Counting one invalid partition when there are two.
• Adding 2 + 2 + 2 conditions instead of multiplying.
• Confusing the number of states with the number of transitions.

Recap

Partitions cut the inputs into groups, boundaries test their edges, decision tables cover combinations, and state transitions cover workflows. Practise the arithmetic until you can do it in your head.