Catalog
method#Quality Assurance#Software Engineering#Reliability

Equivalence Partitioning

A black-box test design technique that reduces test cases by grouping inputs into equivalent classes.

Equivalence partitioning is a test design technique that divides input domains into equivalent classes to reduce the number of test cases while maintaining coverage.
Established
Medium

Classification

  • Medium
  • Technical
  • Design
  • Foundation

Technical context

Test management tools (e.g. TestRail, Zephyr)Issue trackers (e.g. JIRA)Automation frameworks (e.g. JUnit, pytest)

Principles & goals

Systematically segment input domains into non-overlapping classes.Select at least one representative test case per class.Derive class definitions from rules, requirements and boundary conditions.
Build
Team, Domain

Use cases & scenarios

Compromises

  • Incorrect class definition may miss defects.
  • Clarity is lost with too many or overlapping classes.
  • Lack of domain knowledge reduces effectiveness.
  • Combine equivalence classes with boundary value analysis.
  • Document classes and decision rules clearly.
  • Prioritize classes by risk and usage frequency.

I/O & resources

  • Requirement and field specifications
  • Sample datasets and boundary definitions
  • Access to test environment and test data management
  • Representative test cases per equivalence class
  • Documentation of classes and mappings
  • Metrics for coverage and defect analysis

Description

Equivalence partitioning is a test design technique that divides input domains into equivalent classes to reduce the number of test cases while maintaining coverage. Selecting representative values from each class minimizes redundancy and effort. It supports efficient functional and black‑box testing but requires careful class definition for complex inputs.

✔

  • Reduces number of test cases while keeping efficacy.
  • Enables structured test planning and prioritization.
  • Improves repeatability and traceability of tests.

✖

  • Less effective for highly state-dependent systems.
  • Requires precise knowledge of input requirements.
  • Boundaries must also be checked with other techniques (e.g. BVA).

  • Number of equivalence classes

    Counts defined classes per input, indicates granularity of test coverage.

  • Test cases per class

    Average representative test cases per class to measure efficiency.

  • Defects per class

    Number of detected defects per class to evaluate class definitions.

Email field validation

Partitioning into valid, invalid and empty classes with one representative test value each.

Age restriction (18+)

Equivalence classes <18, =18 and >18 to cover allowed and blocked cases.

Product price validation

Classification into negative, zero, valid ranges and very high values to detect faults.

1

Identify requirements and input fields.

2

Derive equivalence classes for each input field.

3

Select representative values and develop tests.

4

Additionally perform boundary value analysis.

5

Execute tests, evaluate results and adjust classes.

⚠️ Technical debt & bottlenecks

  • Incomplete class definitions documented in tests
  • Automated tests that reflect outdated classes
  • Missing coverage for rare or combinatorial classes
Unclear requirements lead to incorrect classesHigh number of boundary cases increases effortRegulatory validations complicate classes
  • Only one test case for all numeric inputs without class distinctions.
  • Assuming similar defects inside a class are identical.
  • Omitting documentation of class assumptions.
  • Overlooked exceptions or special cases within a class.
  • Unclear rule base leads to inconsistent class assignment.
  • Requirement changes invalidate classes.
Test design and methodologyDomain knowledge for correct classificationAnalytical skills and risk assessment
Testability of input interfacesClarity of business rulesRepeatability of test execution
  • • Limited domain knowledge of testers
  • • Time pressure in release cycles
  • • Dependence on stable requirements