Test order form: check the total before it ships

An order form holds the order in the browser until the last step, and every change to a row has to update both the total and the list that the review shows. Each edit is a chance for one of them to fall behind. A size change can skip a surcharge that a quantity change includes. A new row can appear on screen without reaching the list that gets sent. A delivery date can be offered after the cutoff time the owner set, because that rule lives in the settings and not in the picker. The visitor sees a total that looks plausible.

• Change a quantity, then a size, then the quantity again. Does the total follow each change?
• Add a second row, remove the first, and read the review. Are both lines still there, with the right values?
• Pick the earliest delivery date. Does the form state the cutoff time, and does the date list change after it?
• Compare the total on the review with the total in the confirmation. Any difference is a stop, even a small one.

A total on an order form is computed in at least two places: the browser, which shows it while the visitor types, and the server, which sets the amount of the order. When both use the same rules, the numbers match. When a surcharge for a large size, a bulk discount or a delivery fee lives in only one of them, the two drift. The visitor sees the browser's number, reads it as the price, and the server records another.

Measure the drift at three points, in order: after the item is added, on the review and in the confirmation. Write down the value at each point. The first step where the number changes without a reason you can name is the stop, and the rule that caused it is the one to fix. Keep the screenshot of each point, so the numbers stay on record when you change the code.

Multi-item orders break in a quieter way. A form that tracks each row by its position in the list can lose data when a row above it is removed, because the values shift up and the wrong row keeps the change. The screen looks fine until the review, where one line is missing or carries the quantity of another. A visitor who goes back a step to change something can lose a row the same way.

Check this by counting. Add three lines, remove the middle one, then count the lines on the review and read each value against what you typed. In the Network tab, the request that places the order should list every line that the review shows. Any line missing from the request is a row the form forgot, and it will not appear in the owner's order record.

Some rules that shape an order never appear on the page: a cutoff time after which same-day delivery moves to the next day, a list of delivery areas, or a minimum quantity for one product. The picker shows only the dates the form was given, and the visitor trusts that list. If the form allows a date the owner cannot ship on, the order is accepted, and the problem arrives later as a complaint about a delivery that was promised.

Pick the earliest date a visitor could choose, then try an order just after the cutoff. Check whether the list of dates changes, whether the form states the rule, and whether the server rejects the date with a message the visitor can read. Each of those answers tells you which of the three rules is missing. If weekends follow a different rule, run the same check on a weekend as well, since that is a rule of its own.

Each new product size, delivery area or cutoff rule adds another path through the order. Run the same order after each change, with the same items and dates, and again on every preview. On a protected preview, a paid run can use the site password you give it, so the order form stays reachable.