Explain equivalence partitioning and boundary value analysis with an example.

Both are black-box test design techniques for reducing a huge input space to a small, meaningful set of tests. Equivalence partitioning (EP) splits inputs into partitions where the system should behave identically, so testing one value from each partition is representative. Boundary value analysis (BVA) focuses on the edges of those partitions, because defects such as < instead of <= live there.

Worked example

Requirement: “Age must be an integer from 18 to 60 inclusive.”

Partitions

Partition	Range	Representative
Invalid: too low	age < 18	10
Valid	18 to 60	35
Invalid: too high	age > 60	75

Boundaries (two-value BVA: each boundary and its nearest neighbour outside the partition)

• Lower edge: 17 (invalid), 18 (valid)
• Upper edge: 60 (valid), 61 (invalid)

Three-value BVA adds the value just inside each edge (19 and 59), which catches some extra faults, for example an off-by-one in a different comparison.

So a compact, strong set is: 17, 18, 35, 60, 61, plus the non-numeric partitions below.

Don’t forget the other partitions

Inputs have more dimensions than their numeric range:

• Type and format: "abc", 18.5, -1, " 18", very large numbers.
• Presence: empty, null, missing field in an API payload.
• For strings: length boundaries (0, 1, max, max+1), character sets, leading or trailing whitespace.
• For dates: end of month, leap day, time zones, daylight saving changes.
• Outputs can be partitioned too: for a shipping fee with tiers at 50 and 100, test totals of 49.99, 50.00, 99.99, 100.00.

Why it works

The assumption behind EP is that the implementation handles a partition through the same code path. That is a hypothesis, not a guarantee. If you know the code has special handling (for example a hard-coded discount for age 65), that value becomes its own partition. BVA works because developers express ranges with comparison operators and loops, and the most common slip is at the transition.

Automating it

These techniques map naturally to parameterised tests:

import { test, expect } from '@playwright/test';

const cases = [
  { age: 17, ok: false },
  { age: 18, ok: true },
  { age: 35, ok: true },
  { age: 60, ok: true },
  { age: 61, ok: false },
];

for (const { age, ok } of cases) {
  test(`age ${age} is ${ok ? 'accepted' : 'rejected'}`, async ({ request }) => {
    const res = await request.post('/api/signup', { data: { age } });
    expect(res.status()).toBe(ok ? 201 : 400);
  });
}

Testing validation rules like this at the API level is fast; the UI only needs a couple of tests showing the error is displayed.

What interviewers look for

• Correct boundary values, including both sides of each edge.
• Invalid partitions, not just the valid range.
• Thinking beyond the numeric range: type, empty, format.
• How you would combine with decision tables or pairwise testing when several inputs interact.