Equivalence partitioning and boundary values

Equivalence partitioning (EP) is a black-box test technique that divides the data of a test object into partitions whose elements are expected to be processed in the same way, and derives test cases so that each partition is exercised at least once. Boundary value analysis (BVA) is a black-box test technique that derives test cases from the minimum and maximum values of ordered partitions, where defects in comparisons and limits are typically located. The two techniques are used together: partitioning defines the classes, boundary value analysis chooses the values at their edges.

Both techniques are described in The Art of Software Testing by Glenford Myers, first published in 1979; according to a review of that book on AgileConnection, it presented them together with cause-effect graphing and error guessing. Today they are defined in the international standard ISO/IEC/IEEE 29119-4:2021, Software testing, Part 4: Test techniques (clauses 5.2.1 and 5.2.3), and in the ISTQB Certified Tester Foundation Level syllabus, version 4.0.1 (sections 4.2.1 and 4.2.2).

History

The table lists the milestones in the description of the techniques.

The problem the techniques solve

Exhaustive testing is impossible for almost any real input. A quantity field that accepts integers has billions of possible values, and a form combines several fields. Values chosen at random give no argument that the important cases were checked.

Equivalence partitioning replaces the set of all values with a small set of classes. If all values of a class are processed in the same way, a test with one of them says as much about the class as a test with any other.

Partitioning alone does not say which value of a class to take. A requirement "from 1 to 99" can be implemented as quantity < 99 instead of quantity <= 99. Every value in the middle of the class passes, only 99 fails. The ISTQB syllabus names this the typical defect found by boundary value analysis: an implemented boundary placed above or below its intended position, or missing.

Equivalence partitions

An equivalence partition, or equivalence class, is a subset of the possible values of a data element for which the test object is expected to behave in the same way. ISO/IEC/IEEE 29119-4 applies the term to both inputs and outputs.

Valid and invalid partitions

A partition of values that the test object should accept is a valid partition. A partition of values that it should reject is an invalid partition. The ISTQB syllabus notes that teams and organizations may define valid and invalid values differently. The definition used in a project is therefore stated before the partitions are counted.

Rules for partitions

Partitions can be identified for any data element related to the test object: inputs, outputs, configuration items, internal values, time-related values and interface parameters. Two rules apply to every set of partitions:

• No overlap. A value belongs to exactly one partition.
• No empty partitions. Each partition contains at least one value. A partition may contain a single value, such as an empty string.

Output partitions are found the same way: a tax calculation with three rates has three output partitions.

Coverage and test cases

In equivalence partitioning the coverage items are the partitions, including the invalid ones. Coverage is the number of partitions exercised by at least one test case, divided by the total number of identified partitions, expressed as a percentage. One test case per partition is enough for 100 percent coverage.

The Art of Software Testing gives a rule for invalid partitions: each test case covers one invalid partition only. The reason is masking: when a test case is invalid in two ways, the first check that rejects it hides the second. Valid partitions can be combined in one test case.

Several parameters and Each Choice coverage

A test object with several parameters has a set of partitions for each of them. The ISTQB syllabus defines Each Choice coverage for this case: each partition of each set is exercised by at least one test case. Combinations of partitions are not taken into account.

The example below has two parameters: the quantity in an order with three partitions, and the payment method with three partitions.

Each Choice coverage needs at least three test cases, as many as the largest set has partitions. Three test cases, however, put two invalid values into one case. Under the rule of one invalid partition per test case, the set grows to five: two test cases combine the valid partitions, three contain one invalid value each.

Combinations of partitions are the subject of other techniques: decision table testing when the outcome depends on the combination, and pairwise testing when the number of parameters is large.

Boundary value analysis

A boundary value is the minimum or maximum value of an ordered partition. Boundary value analysis can only be used for ordered partitions: numbers, lengths, dates and times. A payment method or a country has no order, so it has no boundaries.

Two-value boundary value analysis

In 2-value boundary value analysis, each boundary value has two coverage items: the boundary value itself and its closest neighbor in the adjacent partition. For the valid partition 1 to 99 of integer quantities, the boundary values are 1 and 99, and the boundaries of the adjacent invalid partitions are 0 and 100. 2-value BVA gives four test values: 0, 1, 99 and 100.

Three-value boundary value analysis

In 3-value boundary value analysis, each boundary value has three coverage items: the boundary value and both of its neighbors. For the boundary 1 the items are 0, 1 and 2; for the boundary 99 they are 98, 99 and 100.

The syllabus calls 3-value BVA more rigorous and illustrates it with a defect. The requirement x <= 10 is implemented as x = 10. The 2-value test values 10 and 11 give the same results for both versions: 10 is accepted and 11 rejected. The value 9, which only 3-value BVA adds, is accepted by the requirement and rejected by the implementation.

Coverage formulas

The table shows the coverage items and the coverage measure of each technique as the ISTQB syllabus v4.0.1 defines them.

Coverage is expressed as a percentage of the identified items: a partition that nobody identified does not lower it.

Numbers

Integer range

The requirement is: the quantity of an item in an order is an integer from 1 to 99. The input field also receives values that are not integers.

P1 to P3 are ordered and have boundaries; P4 and P5 have none. The table shows the test values of each technique.

The values 0 and 100 are boundaries of the invalid partitions P1 and P3. Their neighbors -1 and 101 appear in 3-value BVA. In pytest the values become a parameter list, and the test function runs once for each:

import pytest

from shop.cart import validate_quantity


@pytest.mark.parametrize(
    ("quantity", "valid"),
    [(-1, False), (0, False), (1, True), (2, True),
     (98, True), (99, True), (100, False), (101, False)],
)
def test_quantity_boundaries(quantity, valid):
    assert validate_quantity(quantity) is valid

Parameterized test cases are described in the article Test case.

Decimal amount

The requirement is: a transfer amount from 0.01 to 10000.00 with at most two decimal places. The step between neighboring values is the smallest unit of the amount, 0.01. Without a step, a decimal partition has no closest neighbor, so the step is taken from the specification.

2-value BVA gives 0.00, 0.01, 10000.00 and 10000.01. 3-value BVA adds -0.01, 0.02, 9999.99 and 10000.02. The number of decimal places is a second parameter with its own partitions: up to two places (valid) and more than two places, such as 10.005 (invalid). It is a separate parameter: 10.005 lies inside P2 by value, and partitions of one set must not overlap.

The type of the value matters. The Python documentation notes that numbers like 1.1 and 2.2 have no exact representation in binary floating point, unlike a decimal type. A comparison of a binary floating-point amount at the boundary can give an unexpected result.

Strings

The requirement is: a user name is 3 to 20 characters long and contains Latin letters, digits and underscores. A string has two independent sets of partitions: by length and by characters.

The empty string is a separate partition when the system processes it differently, for example with the message that the field is required. Length is ordered, so the length partitions have boundaries. 2-value BVA gives strings of lengths 0, 1, 2, 3, 20 and 21. 3-value BVA adds lengths 4, 19 and 22; a length of -1 does not exist, so the boundary 0 has only one neighbor. Characters have no order, and their partitions are covered by equivalence partitioning only.

The unit of length is part of the boundary. The JSON Schema keywords minLength and maxLength count characters as defined by RFC 8259. The JavaScript property length and the HTML attribute maxlength count UTF-16 code units, so an emoji has a length of 2. A Python str is a sequence of Unicode code points, and len() returns 1 for the same emoji. A user name of 20 characters with one emoji is therefore 20 long for one component and 21 for another. Input schemas of MCP tools use the same JSON Schema keywords; they are described in the article Tools in MCP.

Dates

Dates are ordered. The step is one day, or smaller when time is part of the value.

Date range

The requirement is: a delivery can be booked from tomorrow up to 90 days ahead. With the current date 3 November 2026, the partitions are:

2-value BVA gives 2026-11-03, 2026-11-04, 2027-02-01 and 2027-02-02. 3-value BVA adds 2026-11-02, 2026-11-05, 2027-01-31 and 2027-02-03. The boundaries depend on the current date, and the current date depends on the time zone. Tests of such a requirement fix the clock and the time zone of the test object; otherwise the same data fall into different partitions on different days.

Leap years and end of month

The valid days of a month depend on the month and, for February, on the year. In the Gregorian calendar a year is a leap year if it is divisible by 4, except years divisible by 100 that are not divisible by 400. The year therefore has four partitions, one for each branch of the rule:

For each month the last valid day is a boundary, and the next day is its neighbor in the invalid partition. The Python calendar module uses the proleptic Gregorian calendar, and calendar.monthrange() returns the number of days in a month. The script prints the pairs for 2-value BVA:

import calendar

for year, month in [(2027, 2), (2028, 2), (2100, 2), (2026, 4), (2026, 12)]:
    last_day = calendar.monthrange(year, month)[1]
    print(year, month, "valid:", last_day, "invalid:", last_day + 1)

The output gives 28 and 29 for February 2027 and 2100, 29 and 30 for February 2028, 30 and 31 for April, 31 and 32 for December. The lower boundary is the same for every month: day 1 is valid, day 0 is not.

Combination with decision tables

Equivalence partitioning and boundary value analysis treat parameters one at a time. When the outcome depends on a combination of conditions, a decision table describes the combinations. Its conditions are often partitions, for example "order total: below 100.00, 100.00 and above". Each rule of the table is then a combination of partitions, the values of its test case are taken from them, and boundary values add test cases at the edges of each condition. The tables are described in the article Decision table testing.

Where the techniques do not help

The techniques assume that all values of a partition are processed in the same way. When the assumption is wrong, the chosen values say nothing about the rest of the class. Several situations fall outside their scope:

• Unordered data. Payment methods, countries and file types have partitions but no boundaries.
• Combinations. A defect that appears only for a certain pair of values is not found by varying one parameter at a time.
• Behavior that depends on history. The same input can be valid in one state and invalid in another: the subject of state transition testing.
• Sequences of actions. Scenarios with alternative flows are the subject of use case testing.
• Boundaries not in the specification. A 32-bit signed integer has a maximum of 2147483647. Such limits come from the implementation, and the specification does not reveal them.

The partitions are only as correct as the specification they come from. A missing requirement leaves no partition, and no test checks it.

Equivalence partitioning and related techniques

The table compares the techniques of this article with the other black-box techniques with which they are combined.

Equivalence partitioning is the basis of the others: boundary value analysis refines it inside ordered partitions, decision tables and pairwise testing use partitions as values and add combinations.

ISO/IEC/IEEE 29119-4 also lists the classification tree method among the specification-based techniques. The choice depends on whether the outcome depends on single values, on edges or on combinations.

Terms

Sources

• ISTQB Certified Tester Foundation Level Syllabus v4.0.1, sections 4.2.1 and 4.2.2, ISTQB, 2024(opens in a new tab)
• ISTQB Glossary(opens in a new tab)
• ISTQB Glossary mirror: equivalence partitioning, imbus(opens in a new tab)
• ISTQB Glossary mirror: boundary value, imbus(opens in a new tab)
• ISO/IEC/IEEE 29119-4:2021, Software testing, Part 4: Test techniques, ISO(opens in a new tab)
• The Art of Software Testing, 3rd Edition, Glenford J. Myers, Tom Badgett, Corey Sandler, Wiley, 2011(opens in a new tab)
• Review of The Art of Software Testing, AgileConnection(opens in a new tab)
• JSON Schema Validation, draft 2020-12, sections 6.2 and 6.3(opens in a new tab)
• String: length, MDN Web Docs(opens in a new tab)
• HTML attribute: maxlength, MDN Web Docs(opens in a new tab)
• calendar, Python documentation(opens in a new tab)
• decimal, Python documentation(opens in a new tab)
• How to parametrize fixtures and test functions, pytest documentation(opens in a new tab)