Quantity field test cases
A quantity field has two numbers in its rules, a minimum and a maximum. The values around them are the first test. The sections after the first follow a value past the field, into the total and into the request the server receives, which is where the limit is often missing.
Values around the edges
For a field that allows 1 to 10:
| Value | Expected | What it catches |
|---|---|---|
| 0 | Rejected | A missing minimum, or one written as "0 or more" |
| 1 | Accepted | A minimum written as "more than 1" |
| 2 | Accepted | A check that compares with == instead of >=: 1 passes, 2 fails |
| 10 | Accepted | A maximum written as "less than 10" |
| 11 | Rejected | A missing maximum, or one written as "11 or less" |
| 1000 | Rejected | A form with no maximum at all, which matters when seats or stock are limited |
The two ends are two separate lines of code, and either can be missing on its own. A form that rejects 11 can still take 0, so test 0 even after 11 came back with an error. An order of 0 tickets has a total of the fee alone, ₪5.00 in a form with a ₪5 fee, and that order may go all the way to payment.
Input that is a number only on paper
2.5. Expected: rejected. The quiet version of this bug turns 2.5 into 2 and charges for two tickets, ₪104.90 at ₪49.95 each plus the ₪5 fee, while the field still shows 2.5. Compare the number in the field with the number on the confirmation.-1. Expected: rejected. A negative quantity times a price is a negative total; with the ₪5 fee, -1 ticket comes to -₪44.95. Watch whether the form displays it.- An empty field. Expected: a message that the quantity is required. Code that converts the empty string to a number gets 0 in JavaScript, and from there the order goes the way of the 0 case above.
1e1and010. JavaScript'sNumber("1e1")is 10,parseInt("1e1")is 1; both read010as 10. Which function the form uses decides what you are charged for, and the field shows neither answer.12abc, or10with a space after it.Number("12abc")isNaN,parseInt("12abc")is 12. Expected: rejected, either as not a number or as 12 over the maximum. A total ofNaNon screen is a bug of its own.- A number far past the maximum, such as 22 digits. Expected: rejected like 11. JavaScript prints
a number that long as
1e+21, and a confirmation may show it that way.
The browser's own checks cover part of this. An <input type="number"> with
min and max stops the arrow buttons at the limits, but a typed value goes
through to the page's own check, and a value sent straight to the server skips both.
Past the field
Once a value is accepted, follow it.
- The total. Change the quantity and watch the total update. Then change it after calculating and place the order without calculating again. Is the order for the quantity you can see? The checkout total guide has a table of expected totals to compare against.
- The server. Open the browser's developer tools on the Network tab, place an order for 10, then edit that request and resend it with 11. An order in reply means the maximum lives only in the browser. The guide on what the server trusts shows how to resend a request.
Then the confirmation and the receipt: the quantity should appear there as you entered it, once, as a whole number.
Arrows, typing, paste
There are three ways to put 11 in the field: the arrow up from 10, typing, and paste. Browsers stop the arrow at the maximum and do nothing about the other two. A field that reformats what is typed, cutting it or changing it, does so in a key handler that a pasted value skips, so the two ways give different results. Use each way at least once. After an error, correct the value and check that the message goes away without another submit.
A short set
With five minutes for the field: 0, 1, 10, 11, 2.5, empty, and one order for 11 sent straight to the server.
Open the practice form
More guides: checkout totals · silent failures and stale screens · all guides