Why this matters
You can never test every possible input, so the question is which few tests will find the most bugs. Testers who choose well finish faster and catch more, and employers notice. A few simple techniques do most of the work, and you can apply all of them with a pen and paper.
Equivalence partitioning
Inputs can usually be split into groups (partitions) where the software should behave the same way for every value in the group. You then test one value from each group instead of hundreds.
Imagine a field where you send money, and the rule is: the amount must be between 1 and 5,000 cedis. The groups are:
- Below the range: less than 1 (for example 0 or a negative number). Should be rejected.
- Inside the range: 1 to 5,000. Should be accepted.
- Above the range: more than 5,000. Should be rejected.
- Not a number at all: letters or symbols. Should be rejected.
Four tests, one per group, already cover a lot.
Boundary value analysis
Bugs love edges. A developer might type "less than 5,000" when they meant "up to and including 5,000". So test the values right at and beside each boundary:
- Lower edge: 0, 1 and 2
- Upper edge: 4,999, 5,000 and 5,001
If 5,000 is rejected, you have found a classic boundary bug. Also think about decimal amounts like 0.50 cedis, if the rules allow pesewas.