Browse the Knowledge Hub32 resources
Test cases
Cart test cases built around money and state
Twenty seven cases covering quantity rules, full recalculation after every change, stock and price movement while the cart sits open, coupon logic, the guest to account merge, request tampering and accessibility. Adding one item to an empty cart is the case that never fails.
All 27 test cases, ready to copy
Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.
Last updated
27 worked examples
Add a single item to an empty cart
TypeFunctionalPriorityHigh- Test data
- In stock item, quantity one
- Expected result
- Item appears with correct name, variant, unit price and line total. Cart badge count updates to one.
Add the same item again
TypeFunctionalPriorityHigh- Test data
- Same product and variant, added twice
- Expected result
- Quantity increments to two on one line rather than creating a duplicate line, unless duplicate lines are the documented behaviour.
Add two variants of the same product
TypeFunctionalPriorityHigh- Test data
- Same product in two sizes
- Expected result
- Two separate lines, each with its own price and stock position.
Update quantity and confirm every total recalculates
TypeFunctionalPriorityHigh- Test data
- Change quantity from one to three
- Expected result
- Line total, subtotal, tax, shipping and discount all recalculate together. A stale tax or shipping figure is the classic partial recalculation bug.
Enter an invalid quantity
TypeNegativePriorityHigh- Test data
- 0, -1, 1.5, abc, empty, 999999
- Expected result
- Rejected server side with a clear message. Zero either removes the line or is refused, never leaves a line priced at nothing.
Exceed the maximum quantity per order
TypeBoundaryPriorityHigh- Test data
- Limit, limit plus one
- Expected result
- Limit accepted, limit plus one refused with the rule stated, enforced on the server.
Remove a line from the cart
TypeFunctionalPriorityHigh- Test data
- Cart with three lines
- Expected result
- Line removed, totals recalculated, undo offered if that is the design. Removing the last line shows the empty cart state.
Add an out of stock item
TypeNegativePriorityHigh- Test data
- Item with zero available
- Expected result
- Blocked with a clear message, or added as a backorder if supported. The button state alone is not sufficient protection.
Request more than the available stock
TypeBoundaryPriorityHigh- Test data
- Available quantity is three, request five
- Expected result
- Capped at three with an explanation, or refused. Stock is checked again at checkout, since carts sit for hours.
Stock falls below the cart quantity while the cart is open
TypeStatePriorityHigh- Test data
- Reduce inventory in another session, then reload the cart
- Expected result
- The user is told before payment, with the quantity adjusted rather than silently reduced at the point of charge.
An item is withdrawn or unpublished while in the cart
TypeStatePriorityHigh- Test data
- Unpublish the product, then open the cart
- Expected result
- Line marked unavailable with a clear explanation and removal offered. Checkout is blocked while it remains.
Price changes while the item is in the cart
TypeStatePriorityHigh- Test data
- Change the price after adding, then view cart and proceed to checkout
- Expected result
- The documented policy is applied consistently, and the price change is disclosed before payment. Charging a different amount from the one displayed is the defect to prevent.
Apply a valid discount code
TypeFunctionalPriorityHigh- Test data
- Active percentage code and active fixed amount code
- Expected result
- Discount applied to the correct base, shown as its own line, and tax recalculated on the discounted amount where that is the rule.
Apply an expired, used or invalid code
TypeNegativePriorityHigh- Test data
- Expired code, single use code already redeemed, random string
- Expected result
- Rejected with a specific reason. Totals unchanged. Failed attempts are rate limited so codes cannot be discovered by brute force.
Attempt to stack multiple discount codes
TypeSecurityPriorityHigh- Test data
- Two codes applied in sequence, and the same code applied twice
- Expected result
- Stacking follows the documented rule and is enforced server side. Double application of one code is refused.
Discount below its minimum spend, then above it
TypeBoundaryPriorityHigh- Test data
- Cart one penny below the threshold, exactly at it, and above it
- Expected result
- Refused below, accepted at and above. Removing an item afterwards revokes the discount rather than leaving it applied.
Free shipping threshold behaviour
TypeBoundaryPriorityMedium- Test data
- Subtotal just below and just at the threshold, then a returns adjustment
- Expected result
- Shipping recalculates in both directions, including when the cart later falls back below the threshold.
Currency rounding across many lines
TypeBoundaryPriorityHigh- Test data
- Multiple lines with prices ending in fractions of a currency unit, plus a percentage discount
- Expected result
- Rounding is applied consistently and the displayed total equals the amount charged to the penny. Accumulated rounding error is a real defect in high volume carts.
Tamper with price or quantity in the request
TypeSecurityPriorityHigh- Test data
- Modified price field, negative quantity, altered discount amount
- Expected result
- Server recalculates from its own source of truth and ignores client supplied prices. This case has produced real losses in production systems.
Attempt to access another user cart
TypeSecurityPriorityHigh- Test data
- Substitute another cart identifier in the request
- Expected result
- Refused. Cart identifiers must be authorised against the session, not merely unguessable.
Merge a guest cart on sign in
TypeStatePriorityHigh- Test data
- Two items as a guest, three different items already saved in the account, then sign in
- Expected result
- Documented merge rule applied, nothing silently discarded, and overlapping items handled without doubling quantities. This case loses revenue when it is wrong.
Cart persistence across sessions and devices
TypeStatePriorityHigh- Test data
- Add items, close the browser, return later, then open on another device
- Expected result
- Signed in carts persist server side and appear on both devices. Guest carts persist per the stated retention period.
Update the same cart from two tabs
TypeStatePriorityHigh- Test data
- Change quantity in one tab, remove the line in the other, then refresh both
- Expected result
- Final state is consistent and explainable, with no negative quantity and no resurrected line. Last write wins is acceptable if it is deliberate.
Click add rapidly several times
TypeStatePriorityHigh- Test data
- Five clicks in under a second
- Expected result
- Quantity reflects the user intent, not the race. The request is idempotent or the control is disabled while in flight.
Cart with a large number of lines
TypePerformancePriorityMedium- Test data
- Fifty to one hundred lines
- Expected result
- Page renders and recalculates within the agreed target. Each quantity change should not trigger a full recalculation of every line if that breaks the budget.
Behaviour when the pricing or tax service is unavailable
TypeNegativePriorityHigh- Test data
- Tax or pricing dependency stubbed to fail
- Expected result
- Checkout is blocked with a clear message rather than proceeding on a stale or default rate. Charging the wrong tax is a compliance problem, not a cosmetic one.
Operate the cart by keyboard and screen reader
TypeAccessibilityPriorityHigh- Test data
- Keyboard only, then NVDA or VoiceOver
- Expected result
- Quantity steppers and remove controls are reachable and labelled, and totals changing are announced through a live region rather than only visually.
What goes in each field
ID
RequiredStable identifier, prefixed by module.
Test case
RequiredWhat is being verified, in one line.
Type
Functional, negative, boundary, security, state, performance, accessibility or compatibility. Use it to check coverage is spread rather than clustered on the happy path.
Priority
Risk based. Anything that can charge the wrong amount, oversell stock or lose a cart is High, because each one costs money directly or loses the sale.
Test data
The specific values, including the invalid and boundary ones.
Expected result
RequiredThe precise observable outcome, including message text where the wording itself is the requirement.
Change something behind the cart
A cart is a snapshot of a world that keeps moving. Almost every serious cart defect comes from that gap.
Move price and stock mid session
Add an item, change its price or inventory in another session, then reload and continue. Disclosure before payment is the requirement.
Tamper with the request
Send your own price and quantity. If the server trusts either, that is a direct financial loss, not a theoretical finding.
Merge a guest cart
Items as a guest plus different items in the account, then sign in. Silent discards here lose sales nobody attributes to a bug.
Check every total, every time
Subtotal, tax, shipping and discount must all move together. Partial recalculation is the most common cart bug we find.
Cart defects that cost real money
Client supplied prices are still trusted more often than anyone would expect, particularly in carts assembled from a mix of frontend state and API calls. Send a modified price or a negative quantity directly to the endpoint. The server must recalculate every figure from its own source of truth and treat the request as a statement of intent, not of value.
Partial recalculation is the everyday version of the same problem. Quantity changes, the line total updates, and tax or shipping keeps a value computed from the previous state. It is easy to miss because the number that is wrong is not the number you were looking at, so assert every total on every change.
The guest to account merge deserves a dedicated case with real data on both sides. The failure modes are all quiet: guest items discarded, account items replaced, or overlapping items doubled. None of them raise an error, and users abandon rather than report.
Coupon logic needs boundary cases rather than a happy path. Apply at one penny below the minimum spend, at exactly the minimum, then remove an item so the cart drops back below the threshold and confirm the discount is revoked. Discounts that survive the condition that justified them are a slow revenue leak.
Suggest an improvementTesting an ecommerce build?
QAble tests cart, checkout and payment as one flow across devices and payment methods, including the failure paths providers will not reproduce on demand.
E-commerce testing servicesMore test case sets
View allTest cases for a login page
Test cases25 cases across functional, negative, boundary, security, session and accessibility paths, including account enumeration and lockout.Test cases for a registration form
Test cases28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.Test cases for search functionality
Test cases28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.Test cases for checkout and payment
Test cases30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.Test cases for file upload
Test cases28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.Test cases for forgot password
Test cases26 cases on reset token expiry, single use enforcement, session invalidation and the enumeration and rate limit gaps that are routine here.Test cases for OTP verification
Test cases26 cases on expiry, resend throttling, attempt limits, code reuse, delivery failure and the brute force window teams forget to close.Test cases for user roles and permissions
Test cases26 cases on horizontal and vertical privilege checks, direct object access, role changes mid-session and permission inheritance.Test cases for form validation
Test cases27 rules-based cases on required fields, length and numeric boundaries, client and server parity, hidden field tampering and error accessibility.Test cases for a date picker
Test cases26 cases on timezone shifts, ambiguous day and month order, impossible dates, min and max limits, leap years and keyboard operation.Test cases for pagination
Test cases24 cases on ordering stability, records changing mid-session, page size caps, deep offset cost, permission-filtered totals and state restore.Test cases for push notifications
Test cases26 cases on app states, deep link routing, token release on sign out, lock screen privacy, preferences, provider failures and platform differences.Test cases for reports and data export
Test cases25 cases on permission filtering in the file, spreadsheet formula injection, encoding, typed numbers and dates, row limits and audit logging.Test cases for a chatbot
Test cases28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.Sources
- OWASP Web Security Testing Guide test procedures for enumeration, injection and authorisation.
- WCAG 2.2 the success criteria behind the accessibility cases.
Want the whole purchase flow covered properly?
QAble tests ecommerce journeys end to end with ISTQB-certified engineers. Start with a free QA audit of your store.