Domain Testing (Boundary Value Analysis)
Generate exact boundary values for numeric ranges: below-min, at-min, min+1, max-1, at-max, above-max.
Age
What is boundary value analysis?
Boundary value analysis (BVA) is a test design technique that targets the values at and immediately around the edges of a valid input range. It exists because defects cluster at boundaries: off-by-one errors, a developer writing a greater-than where the spec said greater-than-or-equal, a validator that accepts the maximum but rejects the maximum minus one. Testing the middle of a range finds almost none of these; testing the edges finds most of them.
Equivalence partitioning is its companion technique. It splits the input space into groups that the system should treat identically, a valid range, everything below it, everything above it, so that one value per group stands in for all of them. BVA then picks that value from the edge of each partition rather than the middle, which is where the technique gets its leverage.
A worked example: an integer field accepting 1 to 100
A quantity field accepts whole numbers from 1 to 100 inclusive. Exhaustively testing it means 100 valid values plus an unbounded number of invalid ones. Enter the range above and the tool returns six values: the exact output:
| Value | Partition | Why it is in the set | Expected |
|---|---|---|---|
| 0 | Invalid low | Just below the minimum | Rejected |
| 1 | Valid | At the minimum | Accepted |
| 2 | Valid | Minimum plus one | Accepted |
| 99 | Valid | Maximum minus one | Accepted |
| 100 | Valid | At the maximum | Accepted |
| 101 | Invalid high | Just above the maximum | Rejected |
Six values instead of a hundred, and they catch the realistic failure modes. If the developer wrote a strict greater-than instead of greater-than-or-equal at the lower bound, value 1 fails. If the upper bound check used less-than instead of less-than-or-equal, value 100 fails. If the range was implemented one step wide in either direction, 0 or 101 is wrongly accepted. Values 2 and 99 confirm the interior of the range genuinely works rather than the boundary being special-cased.
Decimal ranges: the step size changes everything
Switch the type to float for a range of 0 to 10 and the tool returns −0.1, 0, 0.1, 9.9, 10 and 10.1. The structure is identical; only the step changed from 1 to 0.1. This matters more than it looks, because “just outside the boundary” is meaningless until you decide the precision the field actually uses.
A price field storing two decimals has a real boundary at 10.01, not 10.1, and if the backend stores a float while the UI rounds to two places, 10.004 is a test case that exposes the mismatch. Pick the step that matches the smallest change the system can represent, not the one that looks tidy.
Two-value versus three-value boundary analysis
There are two conventions, and test plans get reviewed badly when the author cannot name which one they used.
Two-value BVA tests the boundary and the value just outside it: for a minimum of 1, that is 0 and 1. Three-value BVA adds the value just inside, giving 0, 1 and 2. The two-value form is what ISTQB syllabuses now teach as the default and it is cheaper; the three-value form is stricter and catches a narrow class of defect where the boundary itself is special-cased but the adjacent interior value is not. This tool generates the three-value form at both ends, which is the superset: drop 2 and 99 if your standard is the two-value convention.
How to use this boundary value generator
- Enter the minimum and maximum of the valid range, taken from the specification rather than from the code.
- Pick integer or float so the step size matches what the field can actually represent.
- Generate. You get the valid boundary set and the invalid values just outside each edge.
- Turn each value into a test case with an explicit expected result: accepted or rejected, and with which message.
- Repeat per field. A form with five bounded inputs needs five runs, not one combined matrix.
Everything runs in your browser, so ranges from an unreleased spec never leave your machine.
When NOT to use boundary value analysis
The input has no ordered range
Country, payment method, user role: these have no minimum or maximum, so there is no boundary to analyse. Use equivalence partitioning to pick one representative per class, then combine classes with pairwise.
The real boundary is not the one in the spec
A field documented as 1 to 100 may also break at 2147483647, at the database column width, or at the length the API gateway truncates. BVA on the specified range will pass cleanly while the system still falls over. Treat technical limits as additional boundaries and test them explicitly.
The values interact
Start date and end date each have valid ranges, but the defect is usually that end precedes start. Single-field BVA never produces that pair. Add relational cases by hand, or model the relationship as a decision table.
Validation is client-side only
Typing 101 into a form that caps input at three characters proves nothing about the server. Send the out-of-range values directly to the API as well: boundary defects that matter for security live behind the UI, not in it.
The field is a string
Length has boundaries and this technique applies to those, but content does not. Empty, whitespace-only, Unicode, emoji, right-to-left text and injection payloads are a different checklist and BVA will not suggest any of them.
Boundary value tools and approaches, compared
| Approach | Cost | Handles decimals | Trade-off |
|---|---|---|---|
| AQAPro (this page) | Free, browser, no signup | Yes, 0.1 step | One numeric range at a time; no relational rules |
| By hand from the spec | Free | If you remember | The value people most often forget is max-minus-one |
| Property-based testing (Hypothesis, fast-check) | Free, code | Yes | Finds boundaries you did not know about; needs a test harness and a written property |
| Fuzzing | Free, code | Yes | Excellent for crashes and security, poor at asserting correct business behaviour |
| Test management SaaS | Paid | Varies | Traceability and workflow, at the price of a licence |
Honest summary: if you are writing code and can add a property-based test, that finds more than a fixed six-value set ever will. If you are writing a test plan and need defensible, reviewable values for a bounded field in the next minute, generate them above.
How BVA relates to the other test design techniques
Equivalence partitioning and boundary value analysis decide which values are worth using for a single input. A decision table decides which combinations of business conditions must be verified. Pairwise decides how to cut combinations down when several many-valued parameters meet. The normal order is to partition first, pick boundary values from each partition, and only then combine what remains: running pairwise over raw un-partitioned values is the most common way to build a large matrix that tests very little.
Frequently asked questions
How many test cases does boundary value analysis produce?
For one bounded input, six values in the three-value convention: below minimum, at minimum, minimum plus one, maximum minus one, at maximum, above maximum. In the two-value convention it is four. If minimum and maximum are the same, the set collapses to the single valid value plus one invalid value on each side.
What is the difference between equivalence partitioning and boundary value analysis?
Equivalence partitioning divides the input space into classes that should behave identically and tests one value per class. Boundary value analysis chooses that value from the edge of the class rather than the middle. They are normally applied together: partition to find the classes, then take boundaries from each.
Should I test the boundary of an open-ended range?
Yes. A field documented as “18 or older” still has a technical upper limit: the integer type, the column width, the validation library default. Test the specified lower boundary at 17, 18 and 19, and test the implicit upper boundary separately with the largest value the system can hold.
Does BVA apply to dates and strings?
To dates, directly: the boundary values are the day before the range starts, the first day, the last day and the day after, plus leap days and daylight-saving transitions as extra boundaries. To strings, only for length: the content dimension needs its own checklist.
Why test both the minimum and the minimum plus one?
Because they fail for different reasons. The minimum catches a wrong comparison operator at the edge. The minimum plus one catches a boundary that was special-cased correctly while the general path beyond it is broken. In the two-value convention you accept the risk of missing the second case.
Is boundary value analysis still relevant with automated tests?
Yes, and more so. Automation has to be told which values to use, and a parameterised test with six well-chosen boundary values is worth more than a hundred random ones in the middle of the range. The technique decides the data; automation only executes it.