Manual Testing & Test Cases

• Write a test case with all its parts (id, steps, expected, actual).
• Use equivalence partitioning to group inputs.
• Use boundary value analysis to test the edges.
• Cover happy paths AND error paths systematically.

A function takes an age (0-150). That's 151 valid values plus infinite invalid ones (-5, 1000, "abc", 3.7...). You can't test them all. But you don't need to — most behave identically. Test one representative from each group, plus the edges.

Anatomy of a test case

ID:        TC-007
Title:     Reject under-age signup
Pre:       signup form open
Steps:     1. enter age = 12
           2. submit
Expected:  "must be 13 or older" error; not registered
Actual:    (filled in when you run it)
Status:    pass / fail

Equivalence partitioning

Split inputs into groups the code treats identically. For "age must be 13-120":

partition       example   expected
too low (<13)     7       reject
valid (13-120)   30       accept
too high (>120) 200       reject
not a number    "abc"     reject
Test ONE from each partition → 4 tests cover the whole input space.

Boundary value analysis

Bugs cluster at the edges of partitions (the classic < vs <= mistake). Test just inside, on, and just outside each boundary:

boundary at 13:   12 (reject), 13 (accept), 14 (accept)
boundary at 120: 119 (accept), 120 (accept), 121 (reject)

Combine them

def can_signup(age):
    return 13 <= age <= 120

# one per partition + the boundaries
assert can_signup(7)   is False     # too low
assert can_signup(30)  is True      # valid
assert can_signup(200) is False     # too high
# boundaries — where off-by-one bugs hide
assert can_signup(12)  is False
assert can_signup(13)  is True
assert can_signup(120) is True
assert can_signup(121) is False
print("all boundary checks passed ✅")

Seven well-chosen tests prove the function across its entire input space — far better than 50 random ones.

Spec: orders over RM100 get 10% off; orders over RM500 get 20% off; otherwise no discount.

Partitions:   0-100 (none), 100.01-500 (10%), 500.01+ (20%)
Boundaries:   100, 500  (and the values just around them)

ID    input    expected pay    notes
TC1   50       50.00           none partition
TC2   100      100.00          boundary — "over 100" excludes 100
TC3   100.01   90.01           just into 10% partition
TC4   300      270.00          mid 10% partition
TC5   500      450.00          boundary — "over 500" excludes 500 → still 10%
TC6   500.01   400.01          just into 20% partition
TC7   1000     800.00          mid 20% partition

def total_due(amount):
    if amount > 500:
        return amount * 0.8
    if amount > 100:
        return amount * 0.9
    return amount

cases = [(50, 50), (100, 100), (100.01, 90.009), (300, 270),
         (500, 450), (500.01, 400.008), (1000, 800)]
for amount, expected in cases:
    got = round(total_due(amount), 3)
    assert got == round(expected, 3), f"{amount}: got {got}, want {expected}"
print("all 7 cases passed ✅")

Read the diff

The boundary cases TC2 and TC5 are the gold — they pin down whether the rule is "over 100" (strict >) or "100 or more" (>=). That single ambiguity causes endless real-world bugs; boundary testing forces you to decide and lock it in.

You can't test everything, so test smart: split inputs into equivalence partitions (groups treated the same), test one from each, then hammer the boundaries where off-by-one bugs live. A test case has an id, steps, expected and actual results. Design cases on paper first — it clarifies the spec before you write code. Next: turning these into real assert tests.