Design boundary and equivalence tests for a quantity field.

Example Answer

I would partition the input into valid integers from 1 to 20, integers below the range, integers above it, and the explicitly rejected types or missing value. My boundary set is 0, 1, 2, 19, 20, and 21, with 10 as a typical valid interior value. This checks both sides of each inclusive limit.

I would separately test null, a numeric string, a boolean, a fractional number, and the missing key, because a range check alone can accidentally coerce or accept them. For every invalid case I would assert the validation error and that no order was created. For valid cases I would check the stored quantity, not just a success status.

These examples exercise the stated contract. They do not prove every parser or large-payload behavior; I would add such checks only when that boundary is in scope.

Worked test cases

What the interviewer is assessing

Core checks (1 point each):

• Tests valid 1/20 and invalid 0/21 with expected outcomes.
• Includes null, strings, booleans, fractions and omitted-value rejection.
• Checks invalid input creates no order using otherwise-valid fixtures.

Stronger (+1 after all core checks): Includes near-inside boundaries, verifies stored quantities, and notices that booleans may behave like integers in some implementations.

Acceptable alternatives: Separate cases or parameterization work if every class remains observable.

Red flags: Treats the range as exclusive, accepts a numeric string despite the contract, or checks only front-end validation.

Follow-up

Would you run this entire matrix through the browser?

Example response: I would exercise the API contract directly so I can send types the UI cannot create and obtain fast, precise failures. I would also keep a small browser check for field feedback and one successful order. The browser coverage complements the server validation rather than replacing it.