Boundary Values & Equivalence Partitioning as Automation Inputs

The idea, in one line

Group inputs the system treats the same, then test one from each group — plus the values right at the edges. The two names for these moves are equivalence partitioning and boundary value analysis.

Why the edges matter

Bugs love the edges. The most common slip is an off-by-one error — someone wrote 'less than' where they meant 'less than or equal to'. That hides right at the min and max. So for each edge, test the edge itself and the value just on either side of it.

• Low edge of 18: test 17, 18, 19.
• High edge of 65: test 64, 65, 66.
• Plus one plain valid value in the middle, like 40.

See it work

Each value becomes one row in a parametrized test — that just means one test function fed a table of inputs, so a short list drives many checks. Change the rule, edit the table, done.

import pytest

# Rule under test: age must be 18..65 inclusive
def is_eligible(age):
    return 18 <= age <= 65

# One value per bucket, plus the values around each edge
@pytest.mark.parametrize("age, expected", [
    (17, False),   # just below min  -> too young
    (18, True),    # the min edge itself
    (19, True),    # just above min
    (40, True),    # plain valid value
    (65, True),    # the max edge itself
    (66, False),   # just above max  -> too old
])
def test_eligibility_boundaries(age, expected):
    assert is_eligible(age) == expected

Read it top to bottom: one small rule, and a table that pokes at every bucket and every edge around it. That table is your whole test plan, written down.

Advanced — name the classes first

The real skill isn't writing the test — it's naming the buckets and edges before you touch code. Once you've listed 'too young / valid / too old' and marked each edge, the parametrize list almost writes itself. Do the thinking on paper, and the code becomes a formality.

Grounded in Guru99's Boundary Value Analysis & Equivalence Partitioning guide (aligned with ISTQB)