Ecommerce Test Cases: 70 Scenarios for a Complete Purchase Journey

A customer clicks Place order. The payment provider captures $81.75, but the browser times out before confirmation appears. No order is visible in the account, so the customer tries again.

Now the system may contain:

Two payment attempts
One incomplete inventory reservation
No visible order
An uncertain customer

A test that checks only for an Order confirmed heading cannot explain this failure.

Useful ecommerce test cases should examine three things:

1. What the customer saw and submitted.
2. What the application persisted.
3. What happened after delay, failure, retry, or duplicate delivery.

The complete purchase boundary is:

Product discovery
→ product selection
→ cart
→ checkout
→ payment
→ order creation
→ inventory update
→ confirmation
→ post-purchase state

This guide contains 70 positive, negative, boundary, end-to-end, and recovery test cases for ecommerce applications.

For release-level checks without detailed scenarios, use the Ecommerce Website Testing Checklist.

For the strategy behind purchase states, business invariants, and evidence layers, see Ecommerce Testing.

Download the Ecommerce Test Cases Spreadsheet

The complete test-case library is also available as a downloadable XLSX workbook.

It includes all 70 scenarios from this guide, together with editable fields for:

• priority and functional area;
• expected result and required evidence;
• suggested automation layer;
• automation and execution status;
• owner and last execution date;
• defect reference and test notes.

The workbook also contains controlled product and customer fixtures, payment outcomes, priority definitions, and detailed versions of four critical P0 scenarios.

Use it as a starting point for Excel, Google Sheets, TestRail, Zephyr, Xray, or another test-management workflow.

Download the Ecommerce Test Cases XLSX

What an Ecommerce Test Case Should Contain

A title such as Verify successful checkout is rarely enough to reproduce a transaction defect.

Critical cases should record:

Use consistent priorities:

A failed P0 case should normally block release.

Not every store reserves stock at the same stage. Some reserve it when checkout begins; others wait until payment authorisation. The expected result should enforce the product’s actual policy rather than assume one universal ecommerce flow.

Recommended Test Data

A reusable test suite needs controlled business states rather than random products from a shared catalogue.

Prepare:

• one standard in-stock product;
• one product with several variants;
• one last-unit product;
• one out-of-stock product;
• one promotion-eligible product;
• one promotion-excluded product;
• taxable and non-taxable products;
• supported and unsupported shipping addresses;
• guest and registered customers;
• different customer groups or tenants where applicable;
• controlled payment success, decline, pending, and required-action outcomes;
• a safe way to cancel orders, release reservations, and reset inventory.

Example product fixture:

{
  "sku": "SHOES-BLUE-42",
  "slug": "running-shoes",
  "currency": "USD",
  "unitPrice": 8000,
  "availableQuantity": 3,
  "promotionEligible": true,
  "shippingClass": "standard",
  "expectedTaxRegion": "US-CA"
}

Example purchase fixture:

{
  "customer": "[email protected]",
  "sku": "SHOES-BLUE-42",
  "quantity": 1,
  "coupon": "SAVE10",
  "subtotal": 8000,
  "discount": 1000,
  "shipping": 500,
  "tax": 675,
  "expectedTotal": 8175,
  "paymentOutcome": "success"
}

Represent money in minor units where the application contract uses them. This avoids accidental comparisons against values such as 81.749999.

70 Test Cases for an Ecommerce Website

Test Environment and Data

Catalogue, Navigation, Search, and Filters

Search relevance, autocomplete, facets, and index freshness require deeper coverage in a dedicated search and filter testing guide.

Product Pages, Variants, and Availability

Last-unit concurrency should not be proven through browser automation alone. The browser can show each customer’s journey, but the decisive evidence belongs to the inventory reservation and order records.

Cart, Pricing, and Promotions

Use the following calculation as an explicit contract:

Subtotal
− item discounts
− order discounts
− credits
+ shipping
+ tax
=
final payable total

Detailed cart scenarios belong in Shopping Cart Testing.

Checkout, Address, Shipping, and Tax

Detailed form and recovery coverage belongs in a dedicated checkout testing guide.

Payment, Order Creation, and Inventory

Detailed provider and callback scenarios belong in a dedicated payment gateway testing guide.

Customer Account and Order Access

Cancellation, Returns, and Refunds

Mobile, Accessibility, and Resilience

Analytics, Notifications, and Production Cleanup

Detailed Critical Test Cases

The matrix works well for coverage planning and importing into a test-management system. The following four cases show how to document the highest-risk transaction boundaries in a reproducible form.

ECOM-036: Checkout Total Changes Before Payment

Priority: P0 Area: Checkout, pricing, inventory

Preconditions

• Product SHOES-BLUE-42 is in the cart.
• Initial checkout total is $81.75.
• The test can change price, promotion, tax, or inventory after checkout begins.
• No payment has been submitted.

Test data

{
  "initialTotal": 8175,
  "changedTotal": 9175,
  "changeReason": "promotion expired"
}

Steps

1. Add the controlled product to the cart.
2. Start checkout and record the displayed calculation.
3. Expire the promotion or update the authoritative price.
4. Continue to the final order review.
5. Inspect the total and customer message.
6. Attempt to submit payment without accepting the changed result where acknowledgement is required.
7. Accept the new total and continue.

Expected result

• Checkout detects the authoritative change.
• The old total is not sent silently to payment.
• The customer sees the new amount and the affected calculation component.
• Payment uses only the final accepted total.
• The stored order matches the amount accepted by the customer.

Evidence

• Initial and final checkout responses.
• Visible change message.
• Payment-provider amount.
• Persisted order total.

Automation

Browser journey with pricing or checkout API control.

ECOM-044: Retry After a Lost Payment Response

Priority: P0 Area: Payment and idempotency

Preconditions

• A controlled payment method can complete successfully.
• The browser response or application connection can be interrupted.
• Payment, purchase intent, and order records expose correlation identifiers.

Steps

1. Create a checkout and record the purchase intent ID.
2. Submit payment.
3. Allow the provider to complete the payment.
4. Interrupt the browser or application response before confirmation loads.
5. Repeat the final action or reopen the checkout.
6. Inspect provider charges, internal payment records, orders, inventory, notifications, and analytics.

Expected result

• The customer is not charged again.
• One logical payment remains associated with the purchase intent.
• One order is created.
• Inventory changes once.
• Reopening or retrying reveals the authoritative transaction state.
• Notifications and analytics are not duplicated unexpectedly.

Evidence

Purchase intent ID
Idempotency key
Provider payment ID
Order ID
Inventory transaction ID
Purchase event ID

Automation

Browser journey with provider sandbox and internal API verification.

ECOM-048: Payment Captured but Order Creation Fails

Priority: P0 Area: Payment-to-order recovery

Preconditions

• Payment can complete successfully.
• Order persistence or the order-processing worker can be made temporarily unavailable.
• The application has a recovery queue, reconciliation process, or operational exception state.

Steps

1. Prepare a controlled product and checkout.
2. Make the order persistence boundary unavailable.
3. Complete payment successfully.
4. Observe the browser result.
5. Restore the order service.
6. Run or wait for the documented recovery mechanism.
7. Search by payment ID and purchase intent.
8. Compare payment, order, inventory, notification, and analytics state.

Expected result

One of two documented outcomes should occur.

Recoverable path

• Payment remains linked to a pending order transaction.
• Recovery creates one correct order.
• Inventory is reconciled once.
• The customer receives an updated, truthful result.

Operational exception path

• The captured payment is visible to operations.
• No false confirmed order is shown.
• The transaction can be repaired or refunded without another charge.
• The exception cannot disappear silently.

Evidence

• Provider capture.
• Internal payment state.
• Recovery job or operational exception.
• Final order.
• Inventory history.
• Customer message.

Automation

Integration test supported by a browser journey.

ECOM-054: Another Customer Attempts to Access the Order

Priority: P0 Area: Ownership and authorisation

Preconditions

• User A owns ORD-20418.
• User B is authenticated but does not own the order.
• Browser and API order routes are known.

Steps

1. Confirm that User A can view the order.
2. Authenticate as User B.
3. Request the order through the visible order route.
4. Change an accessible order identifier to ORD-20418.
5. Request the order through the API.
6. Try related invoice, receipt, shipment, cancellation, and refund routes.
7. Repeat the checks from another tenant where the application is multi-tenant.

Expected result

• User B cannot read or modify the order.
• Sensitive information is not returned in the error response.
• Related endpoints enforce the same ownership boundary.
• Another tenant receives no order data.
• The attempt is recorded when required by the security policy.

Evidence

• HTTP responses.
• Browser state.
• Response body inspection.
• Audit or security event.

Automation

API authorisation coverage with one browser access check.

Automating Ecommerce Test Cases with Playwright

Browser automation should reproduce the customer journey. Backend assertions should confirm the business result.

Playwright locators are most stable when they follow user-facing roles, labels, and explicit test contracts rather than fragile DOM structure.

A representative flow can:

Prepare controlled product
→ discover it through the storefront
→ select the intended variant
→ add it to the cart
→ validate the final total
→ complete a controlled payment
→ wait for the terminal order state
→ inspect the order
→ reconcile inventory
→ clean generated data

Example:

import { test, expect } from '@playwright/test';

test('successful purchase creates one order and updates stock once', async ({
  page,
  request,
}) => {
  const fixtureResponse = await request.post('/test-support/products', {
    data: {
      fixture: 'standard-in-stock',
      price: 8000,
      quantity: 3,
    },
  });

  expect(fixtureResponse.ok()).toBeTruthy();

  const product = await fixtureResponse.json();

  await page.goto(`/products/${product.slug}`);

  await page
    .getByRole('button', { name: 'Blue, size 42' })
    .click();

  await page
    .getByRole('button', { name: 'Add to cart' })
    .click();

  await page
    .getByRole('link', { name: 'Cart' })
    .click();

  await expect(page.getByTestId('cart-sku'))
    .toHaveText(product.sku);

  await expect(page.getByTestId('cart-total'))
    .toHaveText('$80.00');

  await page
    .getByRole('button', { name: 'Checkout' })
    .click();

  await page
    .getByLabel('Email')
    .fill('[email protected]');

  await page
    .getByLabel('Address')
    .fill('100 Test Street');

  await page
    .getByLabel('City')
    .fill('San Francisco');

  await page
    .getByLabel('Postal code')
    .fill('94105');

  await page
    .getByRole('button', { name: 'Continue to payment' })
    .click();

  await page
    .getByTestId('test-payment-method')
    .selectOption('success');

  await page
    .getByRole('button', { name: 'Place order' })
    .click();

  await expect(
    page.getByRole('heading', { name: 'Order confirmed' }),
  ).toBeVisible();

  const orderId = await page
    .getByTestId('order-id')
    .textContent();

  expect(orderId).toBeTruthy();

  await expect
    .poll(
      async () => {
        const response = await request.get(`/api/orders/${orderId}`);

        if (!response.ok()) {
          return `http-${response.status()}`;
        }

        return (await response.json()).status;
      },
      {
        message: 'order should reach the paid state',
        timeout: 30_000,
      },
    )
    .toBe('paid');

  const orderResponse = await request.get(`/api/orders/${orderId}`);

  expect(orderResponse.ok()).toBeTruthy();

  const order = await orderResponse.json();

  expect(order.total).toBe(8000);

  expect(order.lines).toEqual([
    expect.objectContaining({
      sku: product.sku,
      quantity: 1,
      unitPrice: 8000,
    }),
  ]);

  const inventoryResponse = await request.get(
    `/api/inventory/${product.sku}`,
  );

  expect(inventoryResponse.ok()).toBeTruthy();

  const inventory = await inventoryResponse.json();

  expect(inventory.availableQuantity).toBe(2);
});

Endpoints, selectors, currency representation, and payment controls are application-specific. The evidence pattern is not:

Browser action
→ visible assertion
→ test passed

It is:

Browser action
→ authoritative terminal state
→ persisted order
→ reconciled inventory

Enable traces for failed CI runs so actions, DOM snapshots, requests, timing, and visible state can be inspected together.

Organising and Automating the Test Library

Do not push every case into the browser suite.

Good browser automation candidates include:

• product discovery;
• variant selection;
• cart behaviour;
• checkout forms;
• visible totals;
• payment interaction;
• confirmation;
• order access;
• responsive behaviour.

Prefer API, service, or integration tests for:

• promotion formulas;
• tax calculation;
• callback deduplication;
• inventory concurrency;
• order persistence;
• refund reconciliation;
• analytics events;
• queue processing.

Keep manual or exploratory coverage for:

• confusing product information;
• unexpected combinations;
• physical devices;
• assistive technologies;
• provider-specific customer experiences;
• visual merchandising;
• trust and usability.

The relevant question is not simply whether a case can be automated. It is whether automation at that layer produces reliable evidence at a reasonable maintenance cost.

The 70 cases can be transferred into an XLSX file or test-management system using these columns:

Test Case ID
Area
Title
Priority
Preconditions
Test Data
Steps
Expected Result
Evidence Required
Automation Layer
Automation Status
Owner
Last Result
Defect ID
Notes

For data-driven automation, add:

Customer Type
SKU
Variant
Quantity
Promotion
Currency
Address Region
Shipping Method
Payment Outcome
Expected Payment State
Expected Order State
Expected Inventory Change

One reusable purchase flow can then run several data combinations without duplicating browser steps.

Where WrightTest Fits

WrightTest provides a visual interface around Playwright for recording, editing, running, scheduling, and debugging browser checks.

One recorded purchase journey can use variables for:

Customer type
Product
Variant
Quantity
Promotion
Address
Shipping method
Payment result
Expected visible result

The same journey can cover guest purchases, returning customers, last-unit products, expired promotions, declined payments, required-action payments, unsupported delivery regions, and mobile checkout.

Each run can retain its inputs, failed step, screenshots, and Playwright trace.

WrightTest covers the repeatable browser layer. Payment settlement, persisted orders, inventory, notifications, analytics, and concurrency still need appropriate API, integration, administrative, or database evidence.

Final Acceptance Rule

A successful ecommerce test case should not end with:

The customer saw an order confirmation.

For a completed purchase, the stronger expected result is:

The intended customer accepted the authoritative total, completed the required payment state, created one accurate order, changed inventory once, received a truthful confirmation, and could not repeat or access the transaction outside the documented rules.

That is the boundary these test cases are designed to verify.

Technical References

• Playwright: Locators
• Playwright: API Testing
• Playwright: Tracing
• Stripe: Payment Intents
• Stripe: Payment Status Updates
• Stripe: Idempotent Requests
• Stripe: Handle Payment Events with Webhooks
• OWASP API Security: Broken Object Level Authorization
• W3C: Error Identification
• W3C: User Notifications in Forms