> ## Content Index
> Fetch the complete content index at: https://williamboles.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Equivalence Partitioning and Boundary Value Analysis for Designing Test Cases
- URL: https://williamboles.com/boundary-value-analysis-and-equivalence-partitioning-partnership/
- Published: 2010-01-30T20:05:00.000Z
- Updated: 2026-09-26T09:12:11.000Z
- Description: Boundary Value Analysis and Equivalence Partitioning are essential tools in any QA's toolbox when designing testcases. Here, we look at what they are and how to use.
- Author: William Boles
- Tags: Testing

`Equivalence Partitioning` and `Boundary Value Analysis` are test case design strategies in [black-box testing](https://en.wikipedia.org/wiki/Black-box%5Ftesting?ref=williamboles.com). As with any mildly complex piece of software, it is impossible to test it exhaustively, so we must ensure that the tests we do perform are as efficient and effective as possible - the combination of `Equivalence Partitioning` and `Boundary Value Analysis` makes this possible. Let's see them in action with an example, take this validation rule around ID numbers:

```
An ID number must be between 12 and 24 characters long, inclusive.
```

First, we will use `Equivalence Partitioning`, then `Boundary Value Analysis` to generate our validation test cases.

## Equivalence Partitioning

`Equivalence Partitioning` is a software testing technique that divides input data into *logical groups* or *partitions* where the system is expected to behave similarly. Instead of testing every possible input, you test one representative value from each group - because if one passes, the rest are likely to pass too.

Why it's useful:

1. Reduces test cases while maintaining coverage.
2. Helps identify missing validation logic.

From the above rule, we have three logical groups:

| Group              | Range   |
| ------------------ | ------- |
| Valid              | 12...24 |
| Invalid (Too Low)  | < 12    |
| Invalid (Too High) | \> 24   |

## Boundary Value Analysis

`Boundary Value Analysis` is a software testing technique that focuses on the edges or boundaries of input domains where errors are most likely to occur. Instead of testing every possible input, `Boundary Value Analysis` targets the values just inside, on, and just outside the boundaries - because that's where systems often break.

Why it's useful:

1. Reveals off-by-one errors.
2. Exposes incorrect assumptions about inclusive/exclusive ranges.

Typically, `Boundary Value Analysis` takes two forms:

1. **Two-point** \- take the valid boundary as the first point and just outside of that valid boundary as the second point
2. **Three-point** \- take just inside the valid boundary as the first point, the valid boundary as the second point and just outside of that valid boundary as the third point

Whether you choose the `two-point` or `three-point` approach depends on your context - balance thoroughness against the cost of additional test cases.

Here I'm going to use the **three-point** form as it also shows the **two-point** form as well.

For the above rule, after `Equivalence Partitioning` was applied, we identified three logical groups; the boundaries of each group are:

| Boundaries                 | Value |
| -------------------------- | ----- |
| Just outside valid minimum | 11    |
| Valid minimum              | 12    |
| Just inside valid minimum  | 13    |
| Just inside valid maximum  | 23    |
| Valid maximum              | 24    |
| Just outside valid maximum | 25    |

> If `Equivalence Partitioning` had shown more than one valid group, this table would be larger, as the boundary of each group would need to be shown.

As each boundary generates **3** boundary checks, we have to write **6** test cases to cover the above validation rule fully.

## Working as a team

`Equivalence Partitioning` and `Boundary Value Analysis` are most potent when used together. `Equivalence Partitioning` identifies the logical groups of input data, while `Boundary Value Analysis` determines exactly which values to test within and around those groups.

This systematic approach transforms test case design from guesswork into a methodical process. Instead of wondering "what should I test?", you have a clear framework: partition your inputs logically, then focus your testing effort where bugs are most likely to hide - at the boundaries.