Skip to content
SDETRole
SDETRole

Practice / Test Design

Test Design Lab: Boundary Values, Partitions and Decision Tables

Anyone can write a test that passes. Test design is writing the tests that fail when the code is wrong. Here you get a specification, you write test cases for it, and the lab runs them against buggy copies of the implementation. You score by the bugs your tests expose.

Challenges
10
Beginner
3
Intermediate
5
Advanced
2
Solved
0

Challenges

  1. 01 Ticket prices at the age boundaries Design tests for a ticket price rule. Every bug hides exactly on an age boundary, and you only get credit for the bugs your tests expose.
  2. 02 Password rules: lengths and combinations A password check combines a length range with two character rules. Cover the boundaries and each rule on its own to catch every planted bug.
  3. 03 Username rules with text input A username has a length range and a character set. Choose strings that sit on each limit and each class of character.
  4. 04 Leap years in three tests The leap year rule has an exception to an exception. Catch five buggy implementations with at most three tests.
  5. 05 The triangle classifier Myers' classic exercise: classify a triangle from three sides. Each planted bug needs a specific test, and some are invisible to the obvious ones.
  6. 06 Order status state transitions An order moves through states. Test the transitions that must work and, more importantly, the ones that must be refused.
  7. 07 Shipping fee: a decision table Weight bands, regions and an express option interact. Combination bugs only show up in the right combination, so design tests for them.
  8. 08 Checkout combinations: pairwise in nine tests Nine hidden bugs each fire for one pair of settings. You cannot test all 27 combinations here, so cover every pair in nine.
  9. 09 Account lockout after failed sign-ins A lockout rule depends on two numbers, each with its own boundary. Test each edge while holding the other in the locking zone.
  10. 10 Discount rules that stack A minimum spend, a member discount and a coupon combine in non-obvious ways. Build the decision table, then test the cells.

Why test design is a skill, not a template

A test suite with 100% line coverage can still miss most bugs. Coverage tells you which code ran, not whether a wrong result would have been noticed. Mutation testing asks the harder question: if I plant a small bug in the code, does any test fail? Tests that cannot tell the difference between the correct code and a buggy copy are decoration.

This lab turns that idea into practice. You are not asked to write code, only the inputs and expected results. The specification is the oracle: your expected values are checked against it, so a test with a wrong expectation is reported as wrong instead of being counted as a catch.

A suggested order through the challenges

  • Start with ticket prices at the age boundaries: boundary value analysis, where bugs cluster at < versus <=.
  • Then password rules: independent conditions, where one failing condition at a time isolates the bug.
  • Try username rules, where text input needs both length boundaries and one example from every class of character.
  • Move to the leap year challenge, which caps the number of tests so you have to choose the most informative inputs.
  • Continue with the triangle classifier, where bugs hide in the position of the equal sides, and the order status transitions, where most bugs are actions that should have been refused.
  • Then the account lockout, where two boundaries only show when each is tested with the other condition satisfied, and the discount rules, a decision table where benefits stack.
  • Finish with the shipping fee decision table, where one bug appears only when two rules combine, and checkout combinations, where you must cover every pair of settings in nine tests.

Techniques used in the lab

  • **Equivalence partitioning** splits the inputs into classes that the code treats the same way, then tests one value per class.
  • **Boundary value analysis** adds the values on each side of every class edge, because off-by-one errors live there.
  • **Decision tables** list combinations of conditions and the outcome for each, which exposes rules that only fail when two conditions combine.
  • **State transition testing** checks which events each state accepts, and above all which it must refuse.
  • **Pairwise testing** covers every pair of settings with a small set of combinations, so a bug that needs two specific settings cannot hide.
  • **Mutation testing** measures the result: the share of planted bugs your tests catch.

Frequently asked questions

What is a mutant?

A copy of the correct implementation with one small, realistic bug, such as <= instead of < or a missing validation. A good test suite fails on it.

Why was my test marked wrong?

Your expected value does not match what the specification gives for that input. The lab shows the correct value. A test that fails on the correct code would also fail in your CI, so it cannot count as catching a bug.

Why is the number of tests limited in some challenges?

Choosing inputs that each reveal as much as possible is part of the skill. A suite that finds the same bugs with fewer tests is cheaper to run and to maintain.

Does this need AI?

No. Everything is checked by running the code in your browser.

Type to search across SDETRole.

Full-text search by Pagefind · runs in your browser Open search page →