Designing test cases: boundaries, equivalence and negative tests

A quantity field accepts whole numbers from 1 to 10. How many values could a user type? Zero, negatives, decimals, text, a million, an empty box, emojis. The number is effectively endless, and you do not have time to try them all.

Test design is the skill of choosing a small set of tests that still finds most bugs. Weak testers try random things. Strong testers use a few simple techniques that tell them exactly which inputs matter. This lesson teaches those techniques with the Brew & Bean order API.

A test case is a specific input, the steps to run it, and the result you expect, decided before you run it. Writing the expected result first stops you from rationalising whatever the system happens to do.

Equivalence partitioning groups inputs that the system should treat the same way. If quantities 2, 3, 4 and 5 are all handled by the same code path, testing all four teaches you almost nothing extra. Test one value from each group.

For the quantity field (valid range 1 to 10), there are three groups:

Three tests instead of infinite ones. You can also partition non-numbers: type of input (number, text, empty, decimal) is another set of partitions. And partition other fields too. For the phone number: 10 digits starting with 6 to 9 (valid), starting with 0 to 5 (invalid), too short, too long, contains letters, empty.

Programmers make off-by-one mistakes constantly: writing < where <= was meant, or qty > 10 instead of qty >= 10. Bugs cluster at the edges of ranges. Boundary value analysis says: test exactly on each edge, and one step on either side.

Six tests cover the whole range better than twenty random ones. The rule is 'reject quantities above 10'. If the developer writes if qty >= 10: reject, then a valid order of exactly 10 is wrongly refused. Only a test on 10 reveals it. Random values like 5 or 7 pass either way.

Boundaries are everywhere, not only in numbers:

Positive tests check that valid input works. Negative tests check that invalid input is refused safely: with a clear error, a right status code and no side effects. Many production bugs hide here, because developers naturally think about how the feature should be used, not how it will be misused.

Ideas for negative tests on any input:

For every negative test, check three things: the status code is a 4xx (never 5xx), the message does not leak internals (no stack traces or database errors), and nothing was saved or changed.

When several conditions combine to decide an outcome, use a decision table. Say Brew & Bean adds a rule: a coupon FIRST10 gives 10% off, but only on orders of ₹200 or more, and only once per customer.

Every row is a test case. The table makes it obvious when you have forgotten a combination, and rule 4 exposes a question for the developer that nobody had thought of. Add boundary tests on top: totals of exactly ₹199 and ₹200.

Some things behave differently depending on their current state, like an order. Draw the allowed moves:

Then test every valid move, and several invalid ones such as received to ready, ready to cancelled, and anything out of picked_up. In this API, the invalid moves should return 409. For a table with 5 states there are 25 possible moves between states, so the table lets you check them all systematically.

Here is a compact plan for one endpoint, using the techniques above. Notice how few cases cover so much.

'How would you test a login page / a textbox that accepts ages 18 to 60 / a lift?' is one of the most common QA interview questions. Do not just list random ideas. Say: 'I would use equivalence partitioning and boundary value analysis.' Then give the partitions, the boundary values (17, 18, 19, 59, 60, 61), negative cases (empty, text, negative, decimal), and mention non-functional checks (speed, security). Structure shows skill.

I am a tester. Act as a QA lead and list test cases for [feature or endpoint, e.g. POST /orders].

Rules of the feature: [list the rules, e.g. qty 1 to 10, phone is a 10-digit Indian mobile number].

Give a table with columns: ID, title, input, expected result, technique (equivalence, boundary, negative, state, decision table). Cover boundaries exactly. Then list 5 risky areas the rules do not mention and that I should ask the developer about.

What to expect: Check that boundaries sit on the exact edge values, not near them. Remove duplicates that test the same partition. The 'questions to ask' list is often the most valuable part. Run a few cases for real before trusting the table.