Equivalence partitioning and boundary value analysis
A form accepts an age from 18 to 65. The test set contains 20, 40 and 60, so the happy path looks covered. Then a value of 17 is accepted and 66 behaves differently from the requirement. The missing evidence was not hidden in an endless list of numbers. It was at the boundary.
Equivalence partitioning and boundary value analysis help reduce a large input space without pretending that every value is identical. The useful work is deciding which groups should behave alike and where a small change can alter the result.
Equivalence partitioning and boundary value analysis start with the rule
Write the rule in a form that names the accepted and rejected regions. For an inclusive range from 18 to 65, the useful partitions include values below 18, values from 18 through 65 and values above 65. If the requirement is vague, do not hide that uncertainty inside a test table. Ask for the missing decision.
Choose representatives for each class
Pick a value that represents each meaningful partition. The representative is not a magic number. It is evidence that the system treats the class according to the rule. Add a second value when formatting, sign, precision or a related condition could change the behaviour.
Keep the reasoning beside the test selection. A reviewer should see why 40 was chosen and what it says about the values around it.
Put the boundary under deliberate pressure
For an inclusive range, check the lower boundary, the value just below it, the upper boundary and the value just above it. If the system accepts decimals, empty input or a transformed value, include the boundary representation that the application actually receives.
Boundary analysis is powerful because defects often live in comparisons, conversions and off-by-one decisions. It is not a substitute for understanding the rule.
Avoid the shortcuts that hide a different partition
- Do not assume the UI range is the same as the API or database range.
- Do not treat a blank value as just another number.
- Do not reuse one representative when permissions or state create a second rule.
- Do not test only accepted values when rejection is part of the contract.
When the layer changes, revisit the partitions. A front-end constraint and a service constraint can disagree without looking different to the user.
Explain what your small set actually covers
Record the rule, partitions, selected representatives and boundaries. State what was not checked, such as locale-specific formats or a database limit. This makes a compact set defensible and prevents it from being mistaken for universal proof.
The result is not a shorter list for its own sake. It is a test selection whose omissions and reasons can be discussed.
Equivalence partitioning and boundary value analysis: test one input rule
Choose one numeric, text-length or date rule. Write the accepted and rejected partitions before entering any values. Then select one representative and the nearest boundary values for each relevant region.
Run the smallest set and compare the observed behaviour with the written rule. If the UI, API and stored value use different representations, record that as a separate question rather than silently merging the layers.
Finish with one sentence about what the set does not prove. A bounded conclusion is more useful than a claim of complete coverage.
Questions before the next step
- What is the exact rule and is its boundary inclusive?
- Which values belong to the same partition?
- What changes immediately beside the boundary?
- Which layer or format remains untested?
ISTQB Quiz combines topic practice with explanations so you can review the reasoning behind each answer.
Explore ISTQB Quiz →