Online Checkout Test Checklist
Table of Contents
Introduction
Use this checklist before launching a store or releasing a material checkout change. Test the purchase journey customers will use, then verify the order, stock and notification records behind it.
Use the payment provider’s supported test mode or a suitable isolated environment. Do not place live charges just to test. Test settings can disrupt live trading or trigger downstream fulfillment and messages, so agree the environment and isolation plan first.
The saved checklist opens in Table because each row is one test scenario and device/browser combination. Record the tested build, inputs, expected and actual results, case status, evidence, order reference and retest history. The supplied cases are editable starters, with no recorded passes or test data prefilled.
| Task name | Tested build or configuration | Device/browser | Inputs and preconditions | Expected result | Actual result | Result | Evidence | Defect reference | Retest result and evidence | Test order reference | Tested at |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Test mobile successful purchase | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. Setup: Representative physical product and approved test payment. Run the approved journey and compare the actual result with this expectation: Correct variant/quantity/totals, usable checkout, one test order and correct confirmation. | |||||||||||
| Test desktop successful purchase | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. Setup: Same representative case on the agreed desktop browser. Run the approved journey and compare the actual result with this expectation: The same commercial result and complete order record. | |||||||||||
| Test cart quantity change before checkout | |||||||||||
Show noteSTARTER CASE: Use one approved test product, a starting quantity and one permitted changed quantity. Record the specific device/browser and inputs. Change the quantity in the cart, then enter checkout. Expected: item count, line total, discount eligibility and final total match the merchant-approved example and the changed quantity persists. Record observed totals; do not prefill a pass. | |||||||||||
| Test a required address field left blank | |||||||||||
Show noteSTARTER CASE: Use a shipping journey and omit one field that the merchant has explicitly made required, for example postal code for a supported destination. Record which field and rule. Expected: a clear validation message, entered non-sensitive values retained and no unintended order. Duplicate for materially different validation rules. Remove if the selected journey does not require an address. | |||||||||||
| Test guest checkout | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. Setup: Signed out, if guest purchase is supported. Run the approved journey and compare the actual result with this expectation: Only required information collected; correct confirmation and order lookup behavior. | |||||||||||
| Test signed-in checkout | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. Setup: Approved test account, if offered. Run the approved journey and compare the actual result with this expectation: Correct permitted address/account behavior; no unrelated customer information. | |||||||||||
| Test valid discount | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. Setup: Approved qualifying products/quantities and test code. Run the approved journey and compare the actual result with this expectation: Correct eligibility, discount amount and total. | |||||||||||
| Test invalid or ineligible discount | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. Setup: Expired/invalid or non-qualifying case approved for testing. Run the approved journey and compare the actual result with this expectation: Clear rejection or non-application; no unexplained price change. | |||||||||||
| Test one supported shipping method | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. Setup: One named supported shipping method, approved product and eligible destination on the recorded device/browser. Expected: The correct method is available with its approved cost and delivery information. Create a separate row for each additional method that needs coverage. | |||||||||||
| Test pickup at one supported location | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. Setup: One named pickup location and eligible test product, if pickup is offered. Expected: The correct location, cost and pickup instructions appear and persist to the test order. Create a separate row for any additional location or rule that needs coverage. | |||||||||||
| Test one supported shipping destination | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. Setup: An approved test address representing one supported destination rule. Expected: The correct shipping options and approved rate are available. Repeat separately for other material destination rules. | |||||||||||
| Test one unsupported shipping destination | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. Setup: An approved test address that the store does not serve. Expected: Checkout clearly prevents the unsupported shipment or gives the approved alternative, with no unintended accepted order. | |||||||||||
| Test tax and total example | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. Setup: Merchant-approved expected calculation/display case. Run the approved journey and compare the actual result with this expectation: Implementation matches the approved example; no legal conclusion inferred. | |||||||||||
| Test unavailable product | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. Setup: An approved out-of-stock test product under a documented store stock rule. Expected: The customer sees the approved availability behavior and cannot create an unintended oversell. | |||||||||||
| Test quantity above the permitted limit | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. Setup: An approved product with a defined quantity limit; enter a quantity above that limit. Expected: The store applies its documented limit, clearly explains the result and carries the permitted quantity into totals and the order. | |||||||||||
| Test a simulated failed payment | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. Use a provider-documented failure simulation. Expected: A clear failure message and the documented failed or pending order/payment state, with no real charge. Record the provider case and actual state. | |||||||||||
| Test recovery after a failed payment | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. From the agreed simulated failure state, use the approved retry path. Expected: A successful permitted retry creates only the intended order and simulated payment, without an unintended duplicate. | |||||||||||
| Verify the simulated order record | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. After a completed simulated purchase, inspect the order in the approved system. Expected: Exactly one intended order with the correct items, quantities, totals and test-payment state. | |||||||||||
| Verify the test inventory effect | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. For one completed simulated order, compare the recorded stock change with the approved platform test behavior. Expected: The documented reservation, decrement or no-change result; fulfillment remains within the isolated test scope. | |||||||||||
| Verify permitted test confirmations | |||||||||||
Show noteSTARTER CASE: Tailor to one actual scenario and device/browser. Rename or duplicate for separate configurations; remove cases outside the agreed scope with the scope decision retained in run notes. Check the customer confirmation page and approved test notifications. Expected: Correct order reference, amount and delivery information sent only to the designated test destinations. Record any unintended downstream message. | |||||||||||
Download or Print this Online Checkout Test Checklist
Get a printable version of this checklist in your preferred format: PDF, Word, Excel, or print directly from your browser.
Presented by:
Checklist.com
Stats
Views
18
Views: 18
Uses
0
Uses: 0
Tasks
20
Tasks: 20
Details
Define expected results before testing
Use operator-approved examples for product prices, discounts, shipping and tax display. This checklist checks the implementation against those examples; it does not determine tax law or decide the merchant’s commercial terms.
Cover success, failure and the record after checkout
A successful payment screen is only part of the journey. Confirm the intended order exists once, its items and totals are correct and inventory/fulfillment/notifications behave as expected. A failed test should leave the expected status and let the customer recover appropriately without duplicate orders.
Keep useful defect evidence
For each failure, record environment, device/browser, inputs, steps, expected versus actual result and sanitized evidence. After a fix, repeat the failed case and relevant nearby cases.
Restore deliberately
Record test orders, discounts, accounts and settings created during the run. Archive, remove or retain them according to the operator’s policy, verify the intended final payment/settings state and obtain the authorized launch decision. This checklist does not launch the store automatically.
Who it's for
How to use
- Save a checklist for the test run. In the app use Table to compare cases or List to work through them; the public page presents the task list.
- Complete the run context in notes: environment, release owner, approved payment test procedure, test-data source, downstream isolation and cleanup plan. Verify these before running any case.
- Rename, duplicate or remove starter cases to cover one actual scenario/device/browser combination per row. Include quantity changes, required-field errors and the supported purchase, discount, delivery and failure paths relevant to the change.
- Record the tested build/configuration, inputs, expected result, actual observation, test time and evidence. Record a test order reference only where an order exists. Do not copy payment or customer secrets.
- Use Result as the case state. Link failures to owned defects and preserve the original result while adding dated retest evidence with the changed build.
- Reconcile test orders and downstream effects, verify intended final settings, and record the authorized launch decision in the run notes. A passed row or complete checklist does not launch the store.