Testing with Defined Inputs and Edge Cases

A program's behavior is defined by what it's supposed to do with every possible input, not just the easy ones. Bugs cluster at the edges of a range because that's where the code's logic has to make a decision: is 100 included or excluded, does -1 get rejected, what happens exactly at the cutoff. A programmer who writes a condition like score ≥ 0 instead of score > 0 won't notice the mistake by testing 50. They'll only notice at 0.

A proper test plan picks inputs on purpose rather than at random. It includes ordinary values comfortably inside the expected range, boundary values sitting exactly at the edges, and values just outside the range that should be rejected. Running the program on all of these and checking each output against what should happen is how you build confidence the program works everywhere, not just where you happened to look.

This connects directly to the three kinds of error a program can hit. Defined-input testing is mainly aimed at catching logic errors, where the program runs but gives a wrong answer for some input. It also connects forward to handling unexpected input: once a program might face a user who types 'ninety' into a score field instead of a number, the test plan has to grow beyond numeric edge cases to include malformed, wrong-type, or missing input.