Equivalence Partitioning

// Definition

Dividing the input space into groups where the system should behave identically, then testing one representative value per group. Reduces redundant test cases dramatically without losing coverage.

// Why it matters

EP groups inputs that the system should treat identically, so you test one representative per group instead of every value — exhaustive coverage without exhaustive cases. Paired with BVA (which tests the edges of each partition), it's how QA gets broad coverage from a small, defensible set of tests.

// How to test

// Age field: invalid-low | valid | invalid-high are 3 classes.
// One representative each is enough — plus BVA at each boundary.
const representatives = [
  { age: -5,  valid: false }, // invalid-low class
  { age: 30,  valid: true  }, // valid class
  { age: 200, valid: false }, // invalid-high class
]
representatives.forEach(({ age, valid }) => {
  cy.request({ method: 'POST', url: '/api/register', body: { age }, failOnStatusCode: false })
    .its('status').should(valid ? 'eq' : 'not.eq', 200)
})

// Related terms

• Boundary Value Analysis

  Testing values immediately at and around boundaries (e.g., min, max, just-below, just-above). Bugs cluster at edges — this technique catches off-by-one errors that equivalence partitioning alone misses.

• Decision Table

  A truth-table-style testing technique that maps every combination of input conditions to expected outputs. Best for rule-based logic with multiple inputs — exposes missing rules and conflicts at design time.

• Test Case

  A single, executable specification: preconditions, steps, expected result, and pass/fail criteria for one verification.