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.
Showing 20 of 20
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — | |
| — | — | — | — | — | — | — | — | — | — | — | — |
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
25
Views: 25
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.