Test cases for checkout
Updated 2026-11-13 · 6 min read
Thirty cases for a physical-goods checkout from address entry to order confirmation. Covers quote changes, duplicate submissions and late payment after stock reservation expiry.
How to answer in an interview
Ask whether guest purchase is supported, when stock is reserved, what fixes the final price and which payment state allows fulfilment. Explain one complete order, then a failed payment and a retry. Keep address validation, order creation and payment confirmation separate so failures can be traced.
Scope and test data
Assume physical goods, guest or signed-in checkout and a server-calculated quote. The arithmetic fixture has ₹1,000 merchandise, a ₹100 discount, ₹40 shipping and ₹90 fixture tax, giving ₹1,030 payable. This is test arithmetic, not a tax rule. Use [email protected] and synthetic addresses in a stubbed serviceability dataset. Stock is reserved on order creation for a configured period; only a server-confirmed captured payment permits fulfilment. Payment-provider details belong in the separate gateway suite.
The 30 cases below are a test design, not an execution report. Replace the example rules with approved requirements before recording pass or fail. Performance budgets and supported device versions must be agreed before execution.
Identity, address and delivery
| ID | Category | Test case | Expected result |
|---|---|---|---|
| K01 | Functional | Complete guest checkout with a serviceable fixture address | One guest order records the supplied contact and delivery address |
| K02 | Functional | Choose a saved address while signed in | Review and order use the selected address snapshot |
| K03 | Negative | Leave a mandatory address field blank | Field-specific error prevents progression without losing other fields |
| K04 | Negative | Supply a postcode absent from the stub serviceability list | Delivery is refused with an actionable serviceability message |
| K05 | Functional | Use an apartment name with spaces and local-script text | Accepted text survives review and order storage without corruption |
| K06 | Functional | Change address after choosing shipping | Serviceability and shipping are recalculated before final confirmation |
| K07 | Functional | Choose a different billing address | Billing and shipping values remain distinct in the order |
| K08 | Negative | Delete the selected saved address in another tab | Checkout requests a valid selection rather than silently using another address |
Quote and stock
| ID | Category | Test case | Expected result |
|---|---|---|---|
| K09 | Functional | Review the stated arithmetic fixture | Payable total is ₹1,030 with all four components visible |
| K10 | Functional | Remove the ₹100 discount before confirming | Quote is recalculated and user sees the new amount before paying |
| K11 | Negative | Expire a coupon between review and confirmation | Stale discounted quote cannot create a payable order without updated review |
| K12 | Functional | Switch shipping to a ₹70 fixture | Total becomes ₹1,060 with the new method recorded |
| K13 | Security | Submit a lower total from the browser | Server rejects or replaces the tampered quote; no underpriced order is created |
| K14 | Negative | Make one item unavailable after review | Order creation is blocked with the affected item identified |
| K15 | Functional | Create an unpaid order with available stock | Exactly the ordered quantities are reserved for the configured duration |
| K16 | Boundary | Reach the reservation expiry with no confirmed payment | Reservation is released and an expired order cannot proceed using stale stock |
Submission and recovery
| ID | Category | Test case | Expected result |
|---|---|---|---|
| K17 | Functional | Confirm once and complete a captured sandbox payment | One order becomes paid and one fulfilment action is recorded |
| K18 | Functional | Double-click final confirmation | One logical submission creates one order and one payment attempt |
| K19 | Negative | Drop the response after order creation | Retry recovers the existing order instead of duplicating it |
| K20 | Negative | Receive a definitive payment failure | Order remains unpaid and retry is offered without claiming success |
| K21 | Functional | Retry payment after a definitive failure | New attempt links to the same order and only confirmed payment fulfils it |
| K22 | Negative | Close the browser after paying but before returning | Server confirmation updates the order; reopening shows its actual state |
| K23 | Security | Open another customer order-confirmation URL | Order details are denied to the unauthorised session |
| K24 | Functional | Refresh a successful confirmation page | Same order appears without another charge or fulfilment |
| K25 | Negative | Receive late payment success after reservation expiry | Order enters reconciliation; unavailable goods are not silently promised |
| K26 | Security | Change delivery address after payment without reauthorisation | Server blocks the change or applies an explicitly authorised amendment flow |
Accessibility and operational checks
| ID | Category | Test case | Expected result |
|---|---|---|---|
| K27 | UI | Submit an invalid form using only the keyboard | Error summary or field focus leads to the errors and entered data is retained |
| K28 | UI | Review totals on a narrow screen with zoom | Total, delivery choice and final payment action remain readable and reachable |
| K29 | Performance | Measure quote and order creation under agreed peak checkout load | Each meets its budget without overselling the last reserved item |
| K30 | Compatibility | Repeat guest checkout and Back navigation across supported devices | Values survive navigation and final order matches the reviewed values |
Evidence and prioritisation
Prioritise K09, K14, K18, K19 and K25. Store quote version, reservation expiry, order ID and payment attempt IDs as evidence. The usual mistake is treating a thank-you page as proof of a paid order; inspect the order state and fulfilment record too. The follow-up is what to do with late success: that is a reconciliation policy requiring product agreement, not an automatic second stock reservation.
Downloads
Quick answers
Is checkout testing the same as payment testing?
No. Checkout also covers identity, delivery, quote agreement, inventory and order creation.
Should a failed payment delete the cart?
Not in this example. Preserve enough state for recovery, and agree when cart contents should be cleared.
Sources
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.