Boundary Value Analysis

Q: Is boundary value analysis the same as equivalence partitioning?

No. Equivalence partitioning divides inputs into groups that should behave the same and tests one value per group. Boundary value analysis then tests the edges of ordered groups, where the behaviour changes. They are normally used together.

Q: Should I use 2-value or 3-value BVA?

Use 2-value BVA by default; it finds most off-by-one defects with fewer tests. Use 3-value BVA for high-risk rules such as prices, limits and eligibility, or when the code treats boundaries specially.

Q: Does BVA work for dates and text?

Yes, whenever the values are ordered: dates and times, text length, file size, item counts and positions all have boundaries. It does not apply to unordered values such as colours or payment methods.

By the Mutqan Soft QA team · Updated 6 October 2026 · 16 min · Intermediate

Boundary value analysis (BVA) is a black-box test design technique that tests the values at the edges of equivalence partitions. A boundary value is the minimum or maximum value of an ordered partition: if a field accepts ages 18 to 65, the boundaries of the valid partition are 18 and 65, and the boundaries of the invalid partitions next to it are 17 and 66.

BVA builds directly on equivalence partitioning. Partitioning tells you which groups of inputs the system should treat the same way; BVA tells you where to look inside those groups, because the edges are where the logic changes and where mistakes cluster.

Why it matters

Developers implement rules such as "18 to 65" with comparisons: age >= 18 && age <= 65. Writing > instead of >=, or using the wrong limit from a misread requirement, produces a defect that only appears at one exact value. Typical values in the middle of a range, such as 30, pass whether the comparison is right or wrong.

Because each boundary needs only two or three test values, BVA finds this whole class of defects with a handful of tests. That makes it one of the cheapest and most productive techniques a tester has, and it applies far beyond numbers: lengths, dates, quantities, file sizes, prices and counts all have edges.

Boundaries exist only where values are ordered

BVA applies to partitions whose values have an order: numbers, dates, times, string lengths, sizes, positions in a list. "Payment method is card, cash or wallet" has partitions but no boundaries, because "cash" is not smaller or larger than "card". For unordered values you use equivalence partitioning alone.

Start by writing the partitions down, including the invalid ones. For an age field that accepts whole numbers from 18 to 65 you get three partitions: below 18 (invalid), 18 to 65 (valid) and above 65 (invalid). Each pair of adjacent partitions meets at a boundary.

Numbers: minimum and maximum, the step size (whole numbers, or 0.01 for money) decides the neighbour.
Lengths: a name of 2 to 50 characters has boundaries at 1|2 and 50|51 characters.
Dates and times: "valid until 31 March" has a boundary between 31 March 23:59:59 and 1 April 00:00:00 — in a stated time zone.
Counts and sizes: "up to 5 attachments, each at most 10 MB" gives boundaries at 5|6 files and at 10 MB and one byte above it.

2-value and 3-value boundary value analysis

The ISTQB Foundation syllabus defines two variants. In 2-value BVA, for every boundary you test the boundary value itself and its closest neighbour in the adjacent partition. In 3-value BVA you test the boundary value and both of its neighbours, one on each side.

For the age field (whole numbers, valid 18 to 65), 2-value BVA gives 17, 18, 65 and 66. 3-value BVA gives 17, 18, 19, 64, 65 and 66. The extra values 19 and 64 catch defects where a developer wrote the right operator but the wrong limit, for example age < 65 instead of age <= 65 — 65 would then be rejected, which 2-value also catches — or code that treats the boundary as a special case and breaks the value next to it.

Age field, valid 18–65: 2-value BVA tests 17, 18, 65 and 66; 3-value BVA adds 19 and 64 just inside the valid partition.

age: integer, valid 18..65

≤ 17Invalid: too young
18–65Valid partition
≥ 66Invalid: too old

117 lower neighbourrejectedFail
218 lower boundaryacceptedPass
319 inside neighbour3-value only · accepted
464 inside neighbour3-value only · accepted
565 upper boundaryacceptedPass
666 upper neighbourrejectedFail

Text version

Field: age, whole numbers, valid 18..65

Partitions:   [ ... 17 ] [ 18 ......... 65 ] [ 66 ... ]
                invalid         valid           invalid

2-value BVA:  17  18                    65  66
3-value BVA:  17  18  19            64  65  66

Expected:     17 rejected, 18 accepted, 19 accepted,
              64 accepted, 65 accepted, 66 rejected

Try it: Boundary Value Analysis Try it: Boundary Value Generator

Worked example: a delivery fee rule

Requirement: "Orders under 100.00 SAR pay a 15.00 SAR delivery fee. Orders from 100.00 to 299.99 SAR pay 7.50 SAR. Orders of 300.00 SAR or more ship free." Prices have two decimal places, so the step between neighbours is 0.01.

The partitions are: below 100.00, 100.00 to 299.99, and 300.00 and above. There are two boundaries between valid partitions here, and a third at the bottom: an order total cannot be zero or negative, so 0.00 and 0.01 matter too.

0.00 → rejected (no empty order); 0.01 → fee 15.00.
99.99 → fee 15.00; 100.00 → fee 7.50.
299.99 → fee 7.50; 300.00 → free delivery.
Add one typical value per partition (for example 50.00, 180.00, 750.00) to show the partition behaves as a whole — that is equivalence partitioning doing its part.

Try it: Boundary Number Dataset Generator

Hidden boundaries the requirement does not mention

Many boundaries are not written in the requirement but exist in the system: the maximum length of a database column, the largest number a data type can hold, the size limit of an upload, the last day of February, the moment a session expires. These implicit boundaries cause some of the most expensive production defects because nobody planned a test for them.

Ask the developer or read the API contract or schema for the technical limits, then apply the same technique: the limit, and the value just beyond it.

Text stored in a column of 100 characters: test 100 and 101 characters, and count characters the way the system does — an Arabic or Hindi string may be measured in bytes, not letters.
A 32-bit signed integer: 2147483647 and 2147483648.
Dates: 28/29 February in leap and non-leap years, and the change of day across time zones.

Try it: String Length Counter Try it: Date Test Data Generator

Common mistakes

Testing only the valid side of each boundary (18 and 65) and never the values that must be rejected (17 and 66).
Not settling whether a limit is inclusive: "between 18 and 65", "up to 65" and "under 65" mean different things. Ask, and write the answer into the test case.
Using the wrong step: for prices the neighbour of 100.00 is 99.99, not 99.
Applying BVA to unordered values such as payment methods or country codes, where it has no meaning.
Forgetting implicit boundaries such as field lengths, type limits and date edges.
Testing boundaries but skipping the partitions in between — BVA complements equivalence partitioning, it does not replace it.

The QA perspective

In practice BVA starts during requirements review: every number, length or date in a requirement is a question about inclusivity, units and step size. Raising "does 65 count as eligible?" before coding prevents the defect instead of finding it later.

When you write the test cases, give each boundary value its own case or its own row in a data-driven table, with the expected result stated explicitly. When one fails, the bug report should name the exact value, the expected result and the comparison you suspect — developers can then fix an off-by-one error in minutes.

Practice exercise

Find the boundary values for a password rule

Your task

A sign-up form says: "Password must be 12 to 64 characters long." Lengths are counted in characters. Identify the partitions, then list the 2-value and the 3-value boundary values with the expected result for each.

Then check the requirement for anything that is still unclear and write it down as a question for the product owner.

Steps

Write down the partitions of password length, including the invalid ones.
Mark the two boundaries between adjacent partitions.
List the 2-value set, then extend it to the 3-value set.
State the expected result (accepted or rejected) for every value.

Show the model answer

Model answer

Partitions: 0 to 11 characters (invalid), 12 to 64 (valid), 65 and more (invalid). Boundaries: 11|12 and 64|65.

2-value BVA: 11 (rejected), 12 (accepted), 64 (accepted), 65 (rejected). 3-value BVA adds 13 and 63 (both accepted).

Also worth testing: an empty password (0 characters), which is the lowest edge of the first partition and usually has its own error message.

Open questions: how are characters counted for emoji or Arabic letters with diacritics? Is the length checked before or after trimming spaces? Is there a separate maximum in the database or the hashing library?

Frequently asked questions

Is boundary value analysis the same as equivalence partitioning?