Boundary Value Analysis &
Equivalence Partitioning Generator
Enter the lowest and highest values a field should accept, and get the partitions, boundary values and expected results, ready to test.
Picture signing up for a gym that's open to anyone aged 18 to 65. You're 18, you enter your age, and the form tells you you're too young. Somewhere in the code, a developer has written "more than 18" instead of "18 or more". It's one of the most common defects in software, and it happens right at the edge of what's allowed.
This generator finds those edges for you. Enter the lowest and highest values a field should accept, and it works out the test values using two techniques: equivalence partitioning and boundary value analysis. Each test comes with the expected result, so you know whether the value should be accepted or rejected.
What is equivalence partitioning?
Equivalence partitioning splits all the possible inputs into groups, called partitions, where the software should treat every value the same way. A field that accepts ages 18 to 65 has three: below 18 (rejected), 18 to 65 (accepted) and above 65 (rejected).
If 30 is accepted, 40 almost certainly will be too. So one value from each partition stands in for the whole group, and you don't need to test them all.
What is boundary value analysis?
Boundary value analysis tests the edges of each partition, because that's where defects tend to sit. In the gym example, the edges are 17 and 18 at the bottom, and 65 and 66 at the top. Testing 30 won't catch the developer who wrote "more than 18", but testing 18 will.
There are two versions. 2-value boundary value analysis tests each boundary and the value just outside it: 17, 18, 65 and 66. 3-value boundary value analysis also tests the value just inside: 17, 18, 19, 64, 65 and 66. The 3-value version takes more tests, but it catches defects the 2-value version can miss. If a developer writes "equals 18" instead of "18 or more", 17 and 18 still behave correctly. Only 19 shows the problem.
Why not test every value?
Ages 18 to 65 give 48 valid values, which is manageable. A price from £0.01 to £999.99 gives 99,999. And there's no limit to the invalid values someone could type in. Testing every value is exhaustive testing, and for most fields it isn't practical. The exhaustive and pairwise testing calculator shows how quickly the numbers grow.
Who is it for?
- Students and anyone new to software testing can see how testers choose a handful of values instead of testing everything.
- Working testers get a ready-made set of test values with expected results for any field with a minimum and maximum, ready to download as a CSV file.
- Developers can check their validation rules against the same values a tester would use.
How to use the generator
- Choose one of the examples, or start from scratch.
- Enter the field name and the lowest and highest values it should accept.
- Choose whole numbers or decimal places. Add a unit, such as "characters", if it makes the values clearer.
- Choose 2-value or 3-value boundary value analysis.
- Tick "Include wrong types of input" to add tests for a blank field, letters and decimals.
- Use the test list on the page, or download it as a CSV file.
Generate your test values
Enter the rule for a field, and get the partitions, boundary values and expected results.
Things to know
- The generator treats the lowest and highest values as allowed. If the rule says "under 18", work out the highest value that's allowed first. For whole numbers, "under 18" means a highest value of 17.
- Expected results assume the field rejects anything outside the range. Check the requirements for exactly what should happen, such as which error message appears.
- A blank field is listed as rejected. If the field is optional, a blank should be accepted, so change the expected result for that test.
Understanding the results
The partitions table shows the groups the inputs fall into and whether each group should be accepted or rejected. The test values table lists every value to test, in order from lowest to highest, followed by any wrong types of input.
The technique column shows where each value comes from. Boundary values sit at the edges of the partitions. Equivalence partition values stand in for a whole group. Some values do both jobs, so they appear once with both techniques listed. The why column explains what each value checks, which helps when writing up test cases or explaining a defect.
Key points
- Equivalence partitioning groups inputs that the software should treat the same way, so one value can stand in for each group.
- Boundary value analysis tests the edges of each group, where defects are most likely.
- 2-value boundary value analysis tests each boundary and the value just outside it.
- 3-value boundary value analysis adds the value just inside each boundary and catches more defects.
- The two techniques work best together, giving a small set of tests that covers every group and every edge.
Frequently asked questions
2-value is quicker and is often enough for simple ranges. 3-value is worth the extra tests when a defect at the boundary would cause real problems, such as with payments, age checks or anything that affects who can use a service.
It works for anything with a lowest and highest value, including text length. For a password that must be 8 to 64 characters, the values are lengths, so you'd test passwords of 7, 8, 64 and 65 characters. The same idea works for dates: the day before, the first day, the last day and the day after.
Testing a few more middle values can feel safer, but they all go through the same part of the code. If 41 is accepted, 30 and 50 will almost certainly behave the same way. Extra tests are better spent at the boundaries, where defects are more likely.
A partition is a group of values, such as every age from 18 to 65. A boundary is the edge of that group, such as 18 and 65. Equivalence partitioning makes sure every group is tested, and boundary value analysis makes sure every edge is tested.
No. Both techniques work from the requirements, the rules a field should follow, not from the code. That's why they're among the first test design techniques new testers learn.