Learner can derive equivalence classes and boundary values for a numeric/range requirement and pick a compact, high-value set of tests.
Equivalence partitioning and boundary value analysis
Why test smarter, not more
Exhaustive testing — running every possible input — is impossible in practice. Instead, testers use design techniques to choose a small set of tests that cover the most ground. Two of the most fundamental techniques are equivalence partitioning and boundary value analysis.
Equivalence partitioning (EP) works on the idea that inputs can be grouped into classes where the software is expected to behave the same way. If a test with value 25 finds no bug, testing 26, 27, and 28 from the same class adds little value. So we pick one representative from each class — one valid and one (or more) invalid. Consider an age field that accepts 18–65: class A is ages 17 and below (invalid), class B is 18–65 (valid), class C is 66 and above (invalid). Three classes → three representative tests cover all the logic.
Boundary value analysis (BVA) adds precision: bugs cluster at the edges of ranges, not the middle. So we always test the values just inside and just outside each boundary. For 18–65 the critical values are 17 (just below lower bound, invalid), 18 (lower bound, valid), 65 (upper bound, valid), and 66 (just above upper bound, invalid). Together, EP and BVA give us a compact, high-value test set — typically 4–6 tests can cover what would otherwise require thousands.
A practical workflow: (1) read the requirement and identify all distinct behaviors; (2) define one class per behavior; (3) add boundary values at each class edge; (4) pick one representative per class plus all boundary values. This is the standard approach recommended in ISTQB CTFL and directly addresses the second testing principle — exhaustive testing is impossible.
Lesson notes
Why test smarter, not more
Exhaustive testing — running every possible input — is impossible in practice. Instead, testers use design techniques to choose a small set of tests that cover the most ground. Two of the most fundamental techniques are equivalence partitioning and boundary value analysis.
Equivalence partitioning (EP) works on the idea that inputs can be grouped into classes where the software is expected to behave the same way. If a test with value 25 finds no bug, testing 26, 27, and 28 from the same class adds little value. So we pick one representative from each class — one valid and one (or more) invalid. Consider an age field that accepts 18–65: class A is ages 17 and below (invalid), class B is 18–65 (valid), class C is 66 and above (invalid). Three classes → three representative tests cover all the logic.
Boundary value analysis (BVA) adds precision: bugs cluster at the edges of ranges, not the middle. So we always test the values just inside and just outside each boundary. For 18–65 the critical values are 17 (just below lower bound, invalid), 18 (lower bound, valid), 65 (upper bound, valid), and 66 (just above upper bound, invalid). Together, EP and BVA give us a compact, high-value test set — typically 4–6 tests can cover what would otherwise require thousands.
A practical workflow: (1) read the requirement and identify all distinct behaviors; (2) define one class per behavior; (3) add boundary values at each class edge; (4) pick one representative per class plus all boundary values. This is the standard approach recommended in ISTQB CTFL and directly addresses the second testing principle — exhaustive testing is impossible.