·
9 min
Equivalence Partitioning and Boundary Value Analysis: A Step-by-Step Guide
Roman Kirchmeier - Autemos
Equivalence partitioning and boundary value analysis derive test cases from the specification: you split possible values into partitions the system should treat the same way, test one representative per partition, then test the edges. ISTQB lists both as black-box test techniques, and boundary value analysis only works for ordered partitions. The running example is an e-banking transfer amount with 5 partitions, 4 test values in the 2-value version and 8 in the 3-value version. For the wider context, see our overview of functional testing.
TL;DR: Equivalence partitioning splits inputs into partitions the system should process the same way, so one test per partition is enough. Boundary value analysis adds tests at the edges of ordered partitions, in the 2-value or the more rigorous 3-value version defined in ISTQB CTFL v4.0.1. The illustrative e-banking example needs 5 representatives and 4 or 8 boundary test values.
Figure 1: Equivalence partitions and boundary values for a transfer amount (illustrative example)
What are equivalence partitioning and boundary value analysis?
Equivalence partitioning (EP) is a black-box test technique that divides data into partitions whose elements the test object should process in the same way. The syllabus concludes: “one test for each partition is sufficient”, and partitions “must not overlap and must be non-empty sets” (ISTQB CTFL v4.0.1, 2024).
Boundary value analysis (BVA) is a black-box test technique that tests the edges of those partitions. The syllabus states: “BVA can only be used for ordered partitions” (ISTQB CTFL v4.0.1, 2024).
The syllabus lists four black-box techniques: EP, BVA, decision table testing and state transition testing (ISTQB CTFL v4.0.1, 2024). Use case testing was on that list in version 3.1. Our black-box testing article compares them with white-box techniques.
Why do so many defects sit at boundaries?
Defects cluster at boundaries since every limit in code is a comparison, and a wrong operator only shows up at that exact point. ISTQB states that BVA focuses on the boundary values of the partitions, since “developers are more likely to make errors with these boundary values” (ISTQB CTFL v4.0.1, 2024).
The German Federal Office of Administration (Bundesverwaltungsamt) reaches the same conclusion in its QS-Baukasten: values at the boundaries of partitions are processed incorrectly more often than values inside them (Bundesverwaltungsamt, QS-Baukasten).
MITRE catalogues the pattern as CWE-193 Off-by-one Error, a maximum or minimum value “that is 1 more, or 1 less, than the correct value” (MITRE CWE-193, CWE 4.20).
Dobslaw, Feldt and Gomes de Oliveira Neto write: “Testing it on the boundaries between these sub-domains is critical to ensure high-quality software.” (Dobslaw et al., PeerJ Computer Science, 2023). We found no verified figure for the share of defects at boundaries.
How do you build equivalence partitions step by step?
You build partitions by splitting one condition from the requirement into valid and invalid partitions that don't overlap, finding the boundary values of ordered partitions and writing every value with its expected result into a table for one parameterized test. The process has eight steps:
Figure 2: Eight steps from requirement to test table
Pick one condition: an input or output condition from the requirement, such as the transfer amount.
Form partitions: valid and invalid, non-overlapping and non-empty.
Check the order: only ordered partitions go on to step 4.
Find boundary values: at the smallest meaningful step, CHF 0.01 for franc amounts.
Choose the BVA version: 2-value or 3-value, by risk.
Write coverage items: each value with its expected result.
Combine inputs: several parameters with Each Choice coverage, one invalid value per test (established practice, see below).
Store the values as a table: and bind it to one parameterized test.
The limits themselves belong in the requirement. If they sit in a user story's acceptance criteria, acceptance testing checks them from the business side.
How do you measure EP coverage?
EP coverage is the number of partitions exercised by at least one test case, divided by the total number of identified partitions, as a percentage. For 100%, test cases must “exercise all identified partitions (including invalid partitions)” (ISTQB CTFL v4.0.1, 2024). Testing 4 of 5 partitions gives 80%.
What is Each Choice coverage?
Each Choice coverage “requires test cases to exercise each partition from each set of partitions at least once” and ignores combinations (ISTQB CTFL v4.0.1, 2024). Add a currency with 3 partitions (CHF, EUR, invalid code) to the amount with 5, and 5 test cases are enough. All combinations would need 15.
What is the difference between 2-value and 3-value boundary value analysis?
2-value BVA uses two coverage items per boundary value, the boundary value and its closest neighbor in the adjacent partition; 3-value BVA uses three, the boundary value and both its neighbors (ISTQB CTFL v4.0.1, 2024). 3-value BVA is more rigorous. The syllabus shows this with “if (x ≤ 10)” implemented by mistake as “if (x = 10)”:
Figure 3: 2-value and 3-value BVA for the syllabus example x ≤ 10
Version | Test values for x ≤ 10 | Detects the faulty x = 10? |
|---|---|---|
2-value BVA | 10, 11 | No: 10 returns true, 11 returns false, both as expected |
3-value BVA | 9, 10, 11 | Likely: 9 should return true, the faulty condition returns false |
3-value BVA counts per boundary value, and between two adjacent partitions several coverage items coincide. So “three tests per boundary” rarely holds, as practitioner articles by trendig (2023) and Valamatsas (2025) show.
Our recommendation: 3-value where a limit triggers payments, approvals or fees, 2-value for fields where a missed defect does little damage.
What does a payment example look like?
An e-banking transfer amount allowed from CHF 0.01 to 10,000.00 produces 5 partitions, 4 test values with 2-value BVA and 8 distinct values with 3-value BVA. The example is illustrative, not a real bank rule, and valid amounts have at most two decimal places.
Partition (illustrative) | Range or rule | Ordered? | Representative | 2-value BVA | 3-value BVA |
|---|---|---|---|---|---|
P1 invalid: too small | ≤ 0.00 | yes | -50.00 | 0.00 | -0.01, 0.00 |
P2 valid | 0.01 to 10,000.00 | yes | 2,500.00 | 0.01, 10,000.00 | 0.01, 0.02, 9,999.99, 10,000.00 |
P3 invalid: too large | ≥ 10,000.01 | yes | 25,000.00 | 10,000.01 | 10,000.01, 10,000.02 |
P4 invalid: more than 2 decimals | e.g. 100.005 | no | 100.005 | n/a | n/a |
P5 invalid: not a number | “abc”, empty | no | “abc” | n/a | n/a |
P1 to P3 cover amounts with at most two decimals, so they don't overlap P4 and P5.
For 100% EP coverage, 5 test values are enough. 2-value BVA gives 4 values: 0.00, 0.01, 10,000.00 and 10,000.01. 3-value BVA produces 12 coverage items at those 4 boundary values, and only 8 are distinct: -0.01, 0.00, 0.01, 0.02, 9,999.99, 10,000.00, 10,000.01 and 10,000.02. If the form rejects -0.01, test it at the API level.
How do you automate equivalence partitions with parameterized tests?
You automate EP and BVA as a data table that one parameterized test runs row by row, with input value, partition and expected result in each row. A new boundary value then means a new row, and the test code stays the same.
Figure 4: The partition table drives one parameterized test (illustrative values)
Framework | Mechanism | Documentation |
|---|---|---|
JUnit 6 (Java) | @ParameterizedTest with @CsvSource, @CsvFileSource or @MethodSource; needs junit-jupiter-params | |
Playwright Test | Loop over the data and call test() per item with a unique name; CSV via csv-parse | |
pytest (Python) | The built-in pytest.mark.parametrize decorator | |
Autemos | Datasets from CSV, XLSX or JSON, runtime bindings as typed variables, a one-time-use flag |
JUnit's current release is 6.1.3 from 7 August 2026, with a Java 17 baseline (JUnit release notes, 2026), so guides built on JUnit 5.7.0 are out of date. pytest is at version 9.1.1 (pytest docs).
In Autemos, the AI-assisted test automation software from selementrix, the partition table becomes a dataset from a file, a REST API or a database. At runtime the columns become typed variables, scoped per run, project or tenant and configurable per environment. One-time-use data is flagged so parallel runs don't reuse it.
Exported tests run as Playwright or Appium code without Autemos. The partition analysis stays human test design: Autemos does not derive partitions on its own. For real customer data, read our guide to GDPR-compliant test data. Once built, the table runs with every change in your regression tests. Autemos doesn't measure code coverage; our test coverage article explains how it differs from partition coverage.
What mistakes do teams make with partitions and boundaries?
Gaps in partition and boundary tests typically come from six places: unordered partitions, decimals, time zones, unclear limits, combinations and masked failures.
Boundaries for unordered partitions: account types and currency codes have no “closest neighbor”. They get one representative each.
Money as floating point: Python's documentation notes that “most decimal fractions cannot be represented exactly as binary fractions” (Python docs). In Java, new BigDecimal(0.1) is not exactly 0.1, and equals() treats 2.0 and 2.00 as different (Oracle Java SE 21 API). Store expected amounts as text, read them into BigDecimal and compare with compareTo(), which treats 2.0 and 2.00 as equal.
Time zones and cut-off times: fix the zone in the test, in Playwright with test.use and timezoneId (Playwright docs), and test the minute before and after the cut-off.
Inclusive or exclusive: “up to 10,000” leaves open whether 10,000.00 is valid. That is where off-by-one errors per CWE-193 occur. Settle it in the requirement.
Missed combinations: when the outcome depends on several conditions at once, use decision table testing. ISTQB warns that “the number of rules grows exponentially with the number of conditions” (ISTQB CTFL v4.0.1, 2024).
Several invalid values in one test: a failing test with two invalid values doesn't show which check fired. The 2018 syllabus says invalid partitions “should be tested individually, i.e., not combined with other invalid equivalence partitions” (ISTQB CTFL 2018 v3.1, 2018). It is established practice, not part of the v4.0.1 EP section.
Frequently asked questions
How many test cases does EP need?
EP needs at least one test case per partition, invalid partitions included, for 100% coverage (ISTQB CTFL v4.0.1, 2024). The e-banking example needs 5.
When is 2-value boundary value analysis enough?
2-value BVA is enough when a missed boundary defect does little damage. It catches “<” written in place of “≤”, and it misses “x ≤ 10” implemented as “x = 10”, which only the third value exposes (ISTQB CTFL v4.0.1, 2024). For amounts, limits and fees we recommend 3-value BVA.
Can you do boundary value analysis without forming partitions first?
No, boundary values are the edges of partitions, so the partitions have to exist first. ISTQB allows BVA for ordered partitions only (ISTQB CTFL v4.0.1, 2024).
Is “min-1, min, min+1, nominal, max-1, max, max+1” part of the ISTQB standard?
No, the seven-value scheme with a nominal value is not in the ISTQB syllabus. The syllabus defines 2-value and 3-value BVA, each counted per boundary value, with no nominal coverage item.
Does Autemos generate partitions automatically?
No, Autemos does not derive partitions or boundary values; that analysis is test design work for your team. Autemos runs the finished value table as a dataset. AI-drafted test steps run only after your team approves each step.
Conclusion
Equivalence partitioning and boundary value analysis turn a requirement into a short list of test values you can justify. Partitions give one representative each; BVA tests the edges of ordered partitions in the 2-value or 3-value version. In the illustrative e-banking example that means 5 representatives and 4 or 8 boundary test values.
The result depends on details: exact decimals, clear inclusive or exclusive limits, a fixed time zone and one invalid value per test. Put the values in a table that a parameterized test runs in JUnit, Playwright or pytest, or in a dataset in Autemos test data handling. Your team designs the partitions, and automation repeats the runs.
Want to automate boundary tests for your payment flows? Talk to us.
