Before hiring an eCommerce QA provider, request a written scope covering shopping and checkout journeys, devices and browsers, integrations, evidence, exclusions and retesting. A useful proposal explains what will be checked, how failures will be reported and which questions will remain open at release.
This eCommerce website testing checklist helps store owners, product teams and digital agencies compare proposals before a launch, migration, promotion or checkout update. For delivery coverage, see Testers HUB’s eCommerce testing services. Use the questions below to turn a broad request for testing into an agreed plan.
1. Which shopping and checkout failures should we prioritize?
Start with failures that prevent customers from finding the right product, placing an accurate order or understanding whether payment succeeded. Prioritize recently changed journeys, important customer environments and dependencies that could affect several steps at once.
- Product discovery: search, filters, out-of-stock results and navigation back to a product.
- Product and cart accuracy: selected variants, quantities, prices and saved carts after signing in.
- Checkout rules: guest and account checkout, coupons, address validation, shipping eligibility and agreed tax calculations.
- Payment states: success, decline, cancellation, pending responses, interrupted redirects and safe retries.
- Order follow-through: confirmation pages, order emails, inventory updates and agreed downstream integrations.
- Mobile usability: keyboards, validation messages, overlays and checkout controls on priority screen sizes.
Ask the provider to explain the order of testing. A changed payment integration may need attention before an unchanged editorial page. A mobile promotion should include the actual banner and discount configuration, because testing an otherwise identical store without that content misses part of the release.
Cart abandonment alone does not prove a software defect. Shipping costs, delivery expectations and purchasing decisions can also affect completion. QA should document reproducible behavior and its impact rather than promise a particular conversion increase.
2. What should the testing proposal and checkout-risk matrix include?
A comparable proposal names the environment, build, workflows, device/browser combinations, integrations, test data, delivery dates and reporting format. It also states who supplies access, who fixes defects and how many test and retest cycles are included.
Use this compact matrix when discussing scope. These are illustrative checks to adapt to your store’s requirements, not results from a completed client project.
| Scenario | Agreed expected behavior | Evidence required | Retest checks |
|---|---|---|---|
| Change a product variant before checkout | The selected variant, price and quantity remain consistent through the order | Selection, cart and order records from the named build and device | Original variant path and related cart edits |
| Apply a coupon and change shipping address | Discount, shipping and tax follow the approved business rules | Test basket, eligibility rules and totals before and after the change | Eligible and ineligible baskets and relevant regions |
| Lose connectivity after submitting sandbox payment | The shopper receives an accurate state and a retry does not create an unintended duplicate order | Timeline, visible messages and permitted order/payment records | Original interruption point, retry and normal checkout |
| Open mobile checkout with a promotional banner | Required controls and validation messages remain usable | Recording with device, OS, browser and banner configuration | Affected screen size plus agreed neighboring layouts |
| Complete an order with an email or inventory integration | Confirmation and downstream state match the agreed workflow | Order reference and authorized integration evidence | Fixed integration path and adjacent order states |
Attach a separate device/browser list and name the owner of each retest. “Mobile tested” is insufficient: ask which real devices, OS versions and browsers will be used, and where emulation supplements that coverage. Record unavailable integrations or blocked access as limitations rather than passing those checks.
3. What evidence should an eCommerce QA provider deliver?
Request a sanitized sample defect report before selecting a provider. It should allow a developer to reproduce the issue and a release owner to understand the affected shopping journey.
- Context: build, environment, device, OS, browser, account state and necessary test data.
- Reproduction: prerequisites, numbered steps and whether the failure is consistent or intermittent.
- Comparison: expected behavior tied to an agreed requirement, alongside actual behavior.
- Evidence: relevant screenshots or recordings, with sensitive customer and payment data removed.
- Impact and status: affected workflow, severity rationale, developer response and retest result.
A screenshot of a confirmation page does not, by itself, establish that payment, inventory and order records agree. Confirm whether authorized backend or integration checks are included. If the team lacks that access, the report should say so.
The release summary should show passed, failed, blocked and untested scope, unresolved defects and remaining risks. The release owner decides whether those risks are acceptable. Testing completion does not guarantee a defect-free store.
Keep specialist work explicit. Functional payment testing is not penetration testing. Observing a slow page is not a load test. Accessibility, security and performance assessments need their own methods, acceptance criteria and confirmed scope; a general manual QA quotation should not imply that all are included.
4. When should we choose launch testing or ongoing QA?
Choose a defined launch engagement for a specific release with a stable scope and acceptance window. Consider recurring QA when themes, plugins, promotions or integrations change frequently and important shopping journeys need repeated checks.
- One-time launch testing: agree a build, coverage list, reporting deadline and separately defined fix-verification window.
- Campaign testing: focus on the actual offer rules, inventory states, banners, delivery restrictions and checkout configuration.
- Dedicated capacity: assign ongoing testing work from a prioritized backlog, with clear ownership and reporting. If that matches your needs, review how to hire website testers.
- Recurring regression: repeat a maintained set of important journeys after changes and expand it when new risks appear.
Compare proposals on the same assumptions. Device combinations, integrations, test-data preparation, build stability and additional cycles affect website testing cost. Use the testing pricing and engagement guide for budget planning, then request an estimate against your scope.
Fix verification checks whether a reported defect is resolved. Regression checks whether changes affected related behavior. Agree both explicitly; recurring capacity does not mean unlimited retesting, devices or releases.
5. How should we interpret a documented checkout defect and its retest?
Illustrative example: a customer selects a Medium product variant, but the cart displays Large. This example shows what to request in a report; it does not claim a new client finding or a verified business outcome.
- Record the conditions. Note the build, browser, device, product configuration, starting cart and exact selection steps.
- Separate observation from cause. Report the mismatch. Do not assume whether the cause is a theme, application or inventory integration before investigation.
- Explain the risk. If reproduced, the mismatch could lead to an incorrect order. Set severity using the affected scope and any workaround.
- Define the fix check. On the corrected build, repeat the original steps and confirm that the intended variant persists through the agreed order flow.
- Choose related regression. Include relevant variant changes, quantity edits, cart restoration and device combinations within the approved scope.
- Report the outcome precisely. Record the build and evidence for passed checks, plus any failures or limitations. Do not turn a successful retest into an unsupported revenue claim.
For a published project account, see our US fashion eCommerce website testing case study. When evaluating a provider, ask for approved, anonymized examples relevant to your own store and distinguish the public summary from the underlying test evidence.
6. Buyer FAQs: sandbox payments, devices, timing, exclusions and retesting
Can checkout payments be tested without real charges?
Many flows can be checked using a configured payment sandbox and supported test methods. Confirm which success, decline, cancellation and retry states the sandbox supports. Sandbox results do not prove every live configuration behaves identically; agree any production checks separately.
Which browsers and devices should the proposal include?
Start with customer analytics, supported platforms and known defects. Name priority desktop browsers and real mobile devices, including OS versions. Explain any coverage gaps and how emulation will be used, rather than promising every possible combination.
How long does pre-launch eCommerce testing take?
The timeline depends on scope, device coverage, integrations, access and build stability. Request an estimate after the provider reviews these inputs, and reserve time for developer fixes and agreed retesting. A fixed duration without those assumptions is difficult to compare.
What should be excluded or quoted separately?
Clarify specialist security, load and accessibility testing, automation development, production transactions, extra builds and additional device coverage. Include any unavailable third-party systems in the limitations. Exclusions should be visible before work starts.
Is retesting included in outsourced eCommerce testing?
Only assume the cycles and hours stated in the quotation. Ask which fixes will be verified, which related journeys will receive regression testing, when corrected builds are due and how additional work is priced.
What should we send when requesting a quotation?
Send your store URL, platform, release date, changed features, payment methods, integrations, priority devices and expected test environment. Explain the main launch risks and who can provide access and resolve questions.
