mediumConceptEntryMidSenior
Pick one input field from something you have worked on and design its tests with equivalence partitioning and boundary values.
5 min readUpdated 2026-08-15
Answer
Short answer
Split the input domain into classes the code should treat identically, then test each class once and probe every boundary at the smallest step the field allows. Exhaustive testing is ruled out by combinatorics, which is why a coverage number is a claim about your model rather than about correctness.
Was this answer helpful?
Likely follow-ups
- Two of your partitions turn out to share a code path. Does that change the test set, and how would you find out?
- How would you extend this to a form where three fields constrain each other?
- Where does a decision table or pairwise generation earn its keep over hand-picked partitions?
- The field is a free-text box rather than a number. What are its partitions?
Related questions
- A test that has passed for a year starts failing after a refactor that was supposed to change nothing. Is it a bug or a bad test?mediumAlso on test-design4 min
- Your test still reaches the network even though you patched the client. Talk me through fixture scope, parametrisation, and where a patch has to point.mediumAlso on coverage4 min
- A flex item with a long URL in it pushes past its container instead of shrinking. Why does flex-shrink not save you?mediumSame kind of round: concept4 min
- A third-party script in the head delays your first paint by a second. What do async, defer and type="module" each change about parsing and execution order?mediumSame kind of round: concept5 min