Yesterday you wrote five test cases and chose the data in each step by feel. Today you choose it by technique, and this is the technique that finds money bugs.
The Tumble Kitchen sign-in promises a password of 8 to 64 characters. Lengths run from 1 to whatever a keyboard can produce, and you cannot test them all. You do not need to. Two classic techniques tell you exactly which values matter.
Equivalence partitioning: test the groups, not the values
Equivalence partitioning splits inputs into groups the system should treat the same:
- Too short: 1 to 7 characters, all rejected the same way.
- Valid: 8 to 64 characters, all accepted.
- Too long: 65 characters and up, all rejected the same way.
One value from each group represents the whole group. A 20-character password and a 40-character one are the same test wearing different clothes; running both proves nothing the first did not. Three groups, three values, and the middle of every group is covered.
Boundary value analysis: stand on the edges
The middles are safe. The edges are not, because the edge is where a developer writes “greater than” when the requirement said “greater than or equal”, and one character in a comparison changes who gets in. Boundary value analysis tests the exact edges of every group. For 8 to 64, six values:
- 7 characters: rejected, with the length message.
- 8 characters: accepted. The edge.
- 9 characters: accepted.
- 63 characters: accepted.
- 64 characters: accepted. The other edge.
- 65 characters: rejected, with the length message.
Read that list again and notice how little of it there is. Six values, chosen with intent, cover the rule more honestly than sixty typed at random, because every value is standing somewhere deliberate.
Workflow
- Split inputs into groups
- Pick one value per group
- Stand on every edge
Boundaries apply anywhere a requirement contains a number, and the House rules panel on the shop is full of them: the delivery fee that goes free at 15,000, the ten-per-dish limit, the card expiry at checkout. Every one is boundary practice waiting for you. Hold on to the discount rule especially. Tomorrow it pays off.
Feel the edge for yourself
Reading about boundaries is nothing like standing on one. Open Tumble Kitchen, go to the sign-in, enter demo@tumblekitchen.test as the email, type a 7-character password, and press Sign in. Read what the store says. Now add one character to the password and press Sign in again, and watch the behaviour change. That is the whole technique in one keystroke: the system treats 7 and 8 differently, and you chose to stand exactly where it happens.
Do this today
Fifteen minutes, two steps:
- Run all six boundary values against the real sign-in, pressing Sign in each time. Use demo@tumblekitchen.test as the email so only the password varies, and record each run in a small table: value, expected, actual, pass or fail. One thing to know before you judge the results: only 7 and 65 should show the length message. The four valid lengths show “Email or password is wrong” instead, and that message is a pass, because it proves the length rule let you through to the credentials check. That table is a real test artefact; keep it with your five cases from yesterday.
- Feed the rule “password must be 8 to 64 characters” into my Boundary & Equivalence Generator. It produces the full value set for any rule you describe. Compare its set against your six, and note anything it picked that you did not.
Tomorrow you take one of the store’s promises, stand on its boundary, and find out it is broken.