Designing test cases with boundary values and equivalence partitions

You can never test every possible input. Test design techniques help you choose a small number of values that are most likely to reveal defects. Screenings test two techniques far more than any other.

Equivalence partitioning

Divide inputs into groups that the system should treat the same way, then test one value from each group. For a quantity field that accepts 1 to 100:

• Invalid partition below the range: 0 or -5.
• Valid partition: any value such as 50.
• Invalid partition above the range: 101.

Three values cover three partitions. Also think about partitions that are not numeric ranges, such as letters, blank input or decimals like 2.5 in a whole-number field.

Boundary value analysis

Developers often make mistakes at the edges, for example writing age > 18 instead of age >= 18. Boundary value analysis tests the limits and the values just outside them. For an age field that accepts 18 to 60 inclusive:

17  -> rejected  (just below minimum)
18  -> accepted  (minimum)
60  -> accepted  (maximum)
61  -> rejected  (just above maximum)

Some teams also test 19 and 59, the values just inside each boundary. Read the requirement carefully: "between 18 and 60" may or may not include the end values, and that is a good question to ask before testing.

Writing the test case

A test case should let another tester run it without asking you anything. Common fields are:

1. ID and title: TC_REG_04, Age field rejects 17.
2. Preconditions: registration page is open.
3. Steps: enter 17 in Age, fill other fields with valid data, click Submit.
4. Test data: age 17.
5. Expected result: error message shown, form not submitted.

Keep one condition per test case where possible, so a failure points to a single cause.

Common mistakes

• Testing only valid values. Many defects are in how invalid input is handled.
• Choosing values in the middle of the range, which rarely reveal edge errors.
• Writing expected results like "works properly" instead of a specific outcome.

Habit to build: for every input field, write down its partitions and boundaries before you write any test steps.