Equivalence Partitioning: Choose Representative Test Inputs

An export form accepts a row limit from 1 to 1,000. You could test hundreds of numbers, or you could ask which kinds of inputs should produce different behavior.

Equivalence partitioning divides a domain into classes expected to receive the same relevant treatment. Testing a representative from each class makes input selection deliberate. It does not prove that every value in a class behaves correctly.

This is part 11 of Testing Methods in Practice. Our row-limit form is a fictional worked example with explicit parsing rules.

Describe the input domain and parser

The field is required and accepts whole decimal numbers from 1 through 1,000. For this example, leading and trailing spaces are trimmed; fractions, exponent notation, and other non-integer syntax are rejected. The server independently applies the same range and syntax policy to its request contract.

Define leading-zero behavior and whether the API receives a number or a string. A browser number input may prevent some characters or normalize them before submission. The raw API domain can therefore differ from the typed form domain.

Do not mark scientific notation invalid merely because this example does. It is a policy decision to confirm for your own feature.

Build partitions from behavior

Open full size

The final class is a normalization case. It might belong to the same semantic class as 250 after parsing, but keeping it separate tests a distinct input-processing behavior.

This method sits within ISTQB's Foundation Level testing techniques. The useful artifact is your partition map and the reasons its classes should behave alike.

Select representatives that isolate the rule

Use a valid account and valid export filters while varying only the row-limit input. If the account lacks export permission, a rejected request tells you nothing about numeric parsing.

For an accepted value, verify the normalized limit reaches the operation and constrains the exported rows under the documented rules. If the fixture contains fewer than 250 rows, it cannot demonstrate a 250-row cap. Choose enough eligible data or inspect the validated request at the appropriate layer.

For rejected values, check that no export is created and that the form remains correctable. Keep browser feedback checks and server-validation checks distinct when their input domains differ.

Split a class when its assumption stops holding

Suppose small exports run synchronously and large exports become background jobs. Then the original in-range class contains two relevant behaviors. Partition around the processing threshold and test each path.

Similarly, non-ASCII digits, locale-specific separators, and very long strings may exercise different parsing or storage paths. Add classes when there is a reason to expect different behavior; do not create a separate class for every random sample.

If invalid inputs receive the same message but fail at different layers, decide whether your test objective includes those layers. Surface similarity alone is not enough to establish equivalence.

Add boundary analysis after the partition map

A representative of the valid class such as 250 can miss off-by-one mistakes at 1 and 1,000. Add values around each threshold: 0/1/2 and 999/1000/1001 for the integer range.

Partitioning helps choose categories. Boundary value testing helps select sensitive values around ordered edges. They work together, with different coverage claims.

Do not confuse “one sample from each class” with exhaustive input validation. A malformed value that causes an unexpected server error is a reason to refine the model and add regression coverage.

Keep the map maintainable

When the maximum changes, update the policy, representatives, boundary fixtures, displayed guidance, and server expectations together. When the syntax policy changes, review all affected classes rather than only changing the passing example.

Your exercise: choose an input from your product, define its raw and normalized domains, and list classes with different expected treatment. Select one representative per class and explain what it establishes. Then choose two plausible values inside one class that might expose an assumption you overlooked.

Next in the series: Risk-based testing.