E-commerce Checkout Manual Testing

Manually test a realistic e-commerce checkout flow — cart management, shipping, payment edge cases, guest vs. registered paths, order-summary totals, and regression checklist — to production-QA standard.

Role

Manual QA engineer

Difficulty

Intermediate

Time limit

~2 hr

Scenario

You are a QA engineer preparing for the release of a redesigned checkout flow on an e-commerce platform. Your task is to manually test the complete checkout journey — from adding items to the cart through shipping, payment, and order confirmation — on Sauce Demo (saucedemo.com), a publicly accessible practice store. The store uses a pre-authenticated session (username: standard_user, password: secret_sauce). You will design test scenarios, execute the testable paths, document payment edge cases (designed but not executable on this demo store), file bug reports for any defects found, and produce a regression checklist that the team can use before every future release.

Requirements

1.Design and execute test scenarios covering the full checkout sequence: add items to cart → update cart (add more, remove one, verify totals) → proceed to checkout → enter shipping information → review order summary → complete checkout → verify order confirmation
2.Test at least 5 cart and checkout edge cases, including: empty-cart checkout attempt, boundary quantities (maximum items), cart total accuracy after item removal, and navigation back through checkout steps
3.Design at least 5 payment edge cases as written test cases — note that saucedemo.com does not have a real payment processor; document these as 'designed, not executed on this environment' with a clear note explaining the limitation
4.Test checkout form validation: attempt to proceed with each required field blank, with invalid input, and with whitespace-only values; document the actual validation message vs. the expected one
5.Verify the order summary totals at each step — subtotal, item tax, and final total must be mathematically consistent; flag any discrepancy as a defect regardless of magnitude
6.File one bug report per defect found, using the standard format: ID, title, steps to reproduce, actual result, expected result, severity, priority, and environment
7.Produce a regression checklist of 8–12 test cases that must pass before every release, ranked by risk (P1 = release-blocker, P2 = high-confidence regression coverage)

Starter data

›Practice store: saucedemo.com — login with username 'standard_user', password 'secret_sauce'
›Available items: Sauce Labs Backpack ($29.99), Sauce Labs Bike Light ($9.99), Sauce Labs Bolt T-Shirt ($15.99), Sauce Labs Fleece Jacket ($49.99), Sauce Labs Onesie ($7.99), Test.allTheThings() T-Shirt ($15.99)
›Checkout fields (step 1): First Name, Last Name, ZIP/Postal Code — all required; saucedemo.com shows a simplified checkout with no real payment step
›Known store limitation: saucedemo.com does not include a payment gateway — payment edge cases must be documented as designed test cases with a note that execution requires a store with a real payment integration (e.g. Stripe test mode)
›Guest vs. registered user context: saucedemo.com uses pre-authenticated sessions; for the guest path, note which checkout steps would differ on a real app (address pre-population skipped, no order history saved) and document the test cases as designed
›Other test users available: locked_out_user (blocked login), problem_user (UI defects injected), performance_glitch_user (slow responses) — use these for extension ideas

Expected deliverables

✓A test-scenario document covering all major checkout paths (happy path, negative, edge) with pass/fail results and a brief evidence note for each executed case
✓At least 5 designed payment-edge-case test cases (expired card, invalid card number, missing CVV, declined payment, correct payment) with a clear note that these are documented for a real payment integration, not executed on saucedemo.com
✓Guest vs. registered user checkout notes — key differences identified with test ideas for each
✓Cart-update test results: add multiple items, remove one, verify the cart badge, subtotal, and item count are all consistent
✓Bug reports for any defects found during execution (one per bug, all required fields completed)
✓A regression checklist of 8–12 test cases ranked P1 (release-blocker) and P2 (regression coverage), with a brief rationale for each P1 item

Evaluation rubric

Dimension	What reviewers look for
Coverage of the full checkout flow	Does the test suite follow the real checkout sequence without skipping intermediate steps? Are the intermediate states — cart updated, address entered, order reviewed — verified as distinct checkpoints, not just the final confirmation screen? A suite that only tests 'add item and complete checkout' in a single path has not verified the flow; it has verified one pass of the happy path.
Payment and edge-case thinking	Are payment edge cases technically specific and grounded in how real payment validation works? An expired card case must specify the expiry boundary (MM/YY = the current month vs. one month past). An invalid card number case must target the specific validation (Luhn check failure vs. unsupported card type). 'Test with a wrong card number' is not specific enough; 'Enter 4111111111111112 (fails Luhn check) and observe the validation message' is.
Risk prioritisation in the regression checklist	Is the regression checklist genuinely risk-based? P1 items must be the scenarios that would block a release if they failed: empty-cart handling, correct total calculation, order placement success, and login. Low-frequency edge cases belong in P2 or P3. A P1 list of 12 items means nothing is truly P1 — it is a list, not a priority ranking.
Bug report clarity	Do bug reports follow the one-bug-per-report rule? Are steps atomic, ordered, and reproducible? The actual result must be a specific, observable system response (e.g. 'cart badge shows 2 after removing the only item; expected: badge shows 0 or is hidden'). A bug whose actual result reads 'it doesn't work' cannot be reproduced or fixed.
Regression awareness	Does the regression checklist reflect what was learned during the test session? If a defect was found in the cart-total calculation, does the regression checklist include a specific check for cart totals? A regression checklist written before execution and never updated is a template, not a QA artefact.

Sample solution outline

›TC-001 (P1) Add single item → proceed to checkout → complete: login as standard_user → click 'Add to cart' on Sauce Labs Backpack → cart badge shows 1 → click cart icon → click 'Checkout' → enter First Name: Test, Last Name: User, ZIP: 12345 → click 'Continue' → order summary shows Sauce Labs Backpack $29.99, Tax $2.40, Total $32.39 → click 'Finish' → 'THANK YOU FOR YOUR ORDER' displayed: PASS
›TC-002 (P1) Cart total accuracy after adding multiple items: add Backpack ($29.99) + Bike Light ($9.99) → subtotal on cart page = $39.98 → proceed to checkout → order summary subtotal = $39.98, Tax = $3.20, Total = $43.18: verify arithmetic is correct (no rounding error): PASS
›TC-003 (P1) Remove item from cart: add Backpack + Bike Light → remove Bike Light from cart → cart badge shows 1, cart contains only Backpack, subtotal updates to $29.99: PASS on saucedemo; note: cart badge update and total recalculation are P1 regression items
›TC-004 (P1) Empty-cart checkout attempt: navigate directly to /cart.html with no items → click 'Checkout' → observe: button is available and proceeds to checkout step 1 with no items — DEFECT: checkout should not be reachable from an empty cart; file BUG-001
›TC-005 (P1) Checkout form validation — blank fields: on checkout step 1, click 'Continue' with all fields empty → 'Error: First Name is required' displayed: PASS; repeat with only First Name filled → 'Error: Last Name is required': PASS
›Payment edge cases (designed, not executed): PC-001 Expired card (month = current - 1, year = current) → expected: 'Card expired' validation message; PC-002 Invalid card number (not Luhn-valid: 4111111111111112) → expected: 'Invalid card number'; PC-003 Missing CVV → expected: 'Security code required'; PC-004 Declined card (use Stripe test card 4000000000000002) → expected: 'Payment declined' with retry option
›BUG-001: Checkout proceeds from empty cart without error | Steps: login → navigate to /cart.html (empty) → click Checkout | Actual: checkout step 1 loads with empty order | Expected: error message 'Your cart is empty' or redirect to product list | Sev: Medium / Pri: High | Component: Cart / Checkout
›Regression checklist P1: (1) happy-path checkout with 1 item, (2) cart total accuracy (2+ items), (3) cart-badge updates on add/remove, (4) checkout form validation (blank fields), (5) order confirmation page shown; P2: (6) maximum items in cart, (7) back-navigation from checkout step 1, (8) empty-cart checkout guard

Common mistakes

Testing only the happy path and ignoring cart manipulation — an e-commerce regression that misses 'remove item from cart' and 'verify total recalculates' has missed one of the highest-frequency failure modes in a real checkout flow
Filing vague bug reports such as 'checkout doesn't work' — without exact steps, test data, and the specific observed error message, a developer cannot reproduce the defect in under five minutes
Treating the payment step as untestable because the demo store lacks a real payment gateway — the correct approach is to document payment test cases with a stated limitation note and describe exactly what you would test with a real payment processor (Stripe test mode, PayPal sandbox)
Not verifying order summary totals mathematically — a subtotal or tax calculation error is one of the highest-severity defects in any e-commerce system; the tester must confirm that subtotal + tax = total, not just that a total is displayed
Writing a regression checklist that is simply all the test cases in a list — the regression checklist must be risk-ranked; P1 items are the ones that would block a release if they failed; if everything is P1, nothing is
Conflating 'guest checkout' with 'logged-in checkout' differences — on a real app these are distinct flows with different pre-fill behaviour, session handling, and post-order account association; the tester should document the key differences even if both are not executable on the practice store

Submission checklist

Test scenarios documented for all major checkout paths (add-to-cart, cart update, checkout, confirmation)
At least 5 payment edge-case test cases documented (even if noted as 'designed, not executed' due to practice-store limitation)
Guest vs. registered user path differences noted with test ideas for each
Cart-update tests executed: add, remove, and total-recalculation verified
All executed test cases have pass/fail results and a brief evidence note
Bug reports filed for any defects found (one per bug, full required fields)
Regression checklist contains 8–12 items with explicit P1 and P2 ranking
Practice-store limitations documented where test cases could not be executed

Extension ideas

+Re-run the same test scenarios logged in as problem_user (saucedemo.com) — this user has injected UI defects; identify the defects and file a bug report for each
+Add performance observations to your test notes using performance_glitch_user and note which pages feel slow — document this as a non-functional observation with a suggested performance test case
+Write a data-driven test case matrix for the checkout form validation covering: all blank, each field blank individually, boundary-length values (1 char, max chars), and special characters in each field