Cart Management Testing Checklist (2026)

March 23, 2026 · 18 min read · Testing Checklists

Cart Management Testing Checklist (2026) – Why It Matters

The Cart Management Testing Checklist (2026) gives engineers a concrete, step‑by‑step matrix for validating every facet of a shopping‑cart feature before it reaches production. Modern e‑commerce platforms expose carts to a wide variety of user behaviors, device contexts, and backend interactions; a single missed condition can lead to abandoned checkouts, revenue loss, or compliance violations. By treating the checklist as a living test suite—rather than a one‑off document—teams can catch regressions early, automate repetitive checks, and focus exploratory effort on the areas that truly need human judgment. The sections below break the checklist into discrete, measurable items, provide pass/fail criteria, show real‑world examples, and illustrate how an autonomous explorer such as SUSA can exercise most of these points in a single pass.

---

Happy Path Test Matrix

A reliable cart must first succeed under ideal conditions. The happy‑path matrix covers the core flow a typical user follows: discovering a product, adding it to the cart, reviewing the cart, adjusting quantities, applying discounts, and moving to checkout. Each item includes a clear pass criterion and a minimal manual test script, followed by an automated equivalent that can be dropped into a CI pipeline.

Add Item to Cart

Step	Action	Expected Result	Pass Criteria	Manual Test	Automated (Appium)
1	Navigate to product detail page (PDP) for SKU A	PDP loads, price displayed, “Add to Cart” button enabled	Page returns HTTP 200, button not disabled	Open PDP, verify button	`driver.findElement(By.id("add-to-cart")).click();`
2	Tap “Add to Cart”	Cart badge increments by 1, toast shows “Item added”	Badge = previous + 1, toast appears within 2 s	Observe badge, toast	`assertEquals(driver.findElement(By.id("cart-badge")).getText(), "1");`
3	Verify cart persistence	Item appears in cart list with correct name, price, quantity = 1	Cart DB row matches PDP data	Open cart, check line item	`List items = driver.findElements(By.className("cart-item")); assertEquals(items.size(), 1);`

View Cart Summary

Step	Action	Expected Result	Pass Criteria	Manual Test	Automated (Playwright)
1	Open cart page from header icon	Cart page loads, shows list of items, subtotal, tax, total	No 5xx errors, subtotal = Σ(price × qty)	Navigate, verify totals	`await page.goto('/cart'); await expect(page.locator('.subtotal')).toHaveText('$45.00');`
2	Verify empty state when no items	Message “Your cart is empty” displayed, CTA to shop	Message visible, primary button enabled	Remove all items, reload	`await expect(page.locator('.empty-cart')).toBeVisible();`

Update Quantity

Step	Action	Expected Result	Pass Criteria	Manual Test	Automated (Appium)
1	Increase quantity of SKU A to 3 using “+” button	Quantity field updates, line total reflects 3 × price, cart total adjusts	Quantity = 3, line total = 3 × unit price	Tap “+” twice, verify	`driver.findElement(By.id("qty-plus")).click(); driver.findElement(By.id("qty-plus")).click();`
2	Decrease quantity to 1 using “‑” button	Quantity returns to 1, line total recalculates	Quantity = 1	Tap “‑” twice	`driver.findElement(By.id("qty-minus")).click(); driver.findElement(By.id("qty-minus")).click();`
3	Set quantity to 0 via input field (if allowed)	Item removed, cart badge decrements, empty state shown if no other items	Item disappears, badge = 0 or previous‑1	Input 0, press Enter	`driver.findElement(By.id("qty-input")).clear(); driver.findElement(By.id("qty-input")).sendKeys("0"); driver.findElement(By.id("qty-input")).sendKeys(Keys.ENTER);`

Remove Item

Step	Action	Expected Result	Pass Criteria	Manual Test	Automated (Playwright)
1	Swipe left on cart item (mobile) or click “×” (web)	Item removed, cart updates instantly	Item no longer in DOM, badge reduced	Swipe/click, verify	`await page.locator('.cart-item').first().hover(); await page.click('.remove-btn');`
2	Verify undo toast appears (if implemented)	Toast with “Undo” action visible for 5 s, clicking restores item	Toast present, undo restores item	Wait for toast, click Undo	`await expect(page.locator('.undo-toast')).toBeVisible({timeout: 5000}); await page.click('.undo-toast button');`

Apply Promo / Coupon

Step	Action	Expected Result	Pass Criteria	Manual Test	Automated (Appium)
1	Open coupon field, enter valid code “SAVE10”	Discount applied, coupon line shows –10 %, total reduced accordingly	Discount field not empty, total = subtotal × 0.9	Enter code, apply	`driver.findElement(By.id("coupon-input")).sendKeys("SAVE10"); driver.findElement(By.id("apply-coupon")).click();`
2	Attempt invalid code “FAKE123”	Error message “Invalid coupon”, cart unchanged	Error visible, totals unchanged	Enter bad code	`assertTrue(driver.findElement(By.id("coupon-error")).isDisplayed());`
3	Remove coupon via “×”	Discount line disappears, totals revert to pre‑coupon state	No discount line, total = original subtotal	Click remove	`driver.findElement(By.id("remove-coupon")).click();`

Proceed to Checkout

Step	Action	Expected Result	Pass Criteria	Manual Test	Automated (Playwright)
1	Click “Checkout” button	Navigation to checkout page, cart data passed via URL or state	Checkout page loads, cart summary matches cart page	Click, verify URL	`await page.click('#checkout-btn'); await expect(page).toHaveURL(/.*checkout/);`
2	Verify cart immutability during navigation	No background requests modify cart while in checkout	Cart GET returns same items as before navigation	DevTools network, verify	`await page.route('**/api/cart', route => { const req = request(); return req.method() === 'GET' ? route.fulfill({json: expectedCart}) : route.continue(); });`

Each happy‑path row can be copied into a test case management tool (e.g., TestRail) with the manual steps as the “test case” and the automated snippet as the “automation script”. When the feature is stable, the automated scripts become the regression gate.

---

Error Handling and Validation

Even a flawless happy path fails if the system does not react correctly to invalid input, unexpected states, or external perturbations. This section enumerates validation checks that guard against data corruption, user frustration, and downstream failures.

Invalid Quantity Inputs

Test ID	Input	Expected System Reaction	Pass Criteria
QTY‑01	Negative number (‑2)	Field rejects, shows “Quantity must be ≥ 1”	Error message appears, cart unchanged
QTY‑02	Non‑numeric text (“abc”)	Input ignored or cleared, validation error	No change to quantity, error visible
QTY‑03	Decimal (1.5) when only whole numbers allowed	Rounded down to 1 or rejected per business rule	System follows defined rule, consistent message
QTY‑04	Exceeds max allowed (e.g., 999)	Either capped at max or error “Maximum quantity exceeded”	Behavior matches spec, no overflow

*Manual*: Open quantity input, type each value, press Enter or click away, observe feedback.

*Automated*: Parameterized test feeding each value, asserting presence of error element and unchanged cart total.

Price Modification During Session

Scenario	Trigger	Expected Result	Pass Criteria
PRICE‑01	Backend price drops 20 % while item in cart	Cart shows stale price until refreshed; optional “Price updated” banner	No silent overcharge; user sees discrepancy or update notice
PRICE‑02	Tax rate changes mid‑session	Subtotal unchanged, tax line reflects new rate on next page load	Tax calculation uses latest rate at checkout
PRICE‑03	Currency switch (USD → EUR) while item in cart	Cart converts using latest FX rate, shows conversion notice	Conversion uses service rate, rounding to 2 dp

*Manual*: Use a proxy (e.g., Charles) to modify API responses, verify UI response.

*Automated*: Mock the price endpoint in test harness, assert UI shows either original price with banner or updated price per spec.

Stock‑out While Item in Cart

Condition	Action	Expected Result	Pass Criteria
STOCK‑01	Inventory goes to 0 after add	Cart displays “Item out of stock”, remove‑only button enabled	User cannot increase quantity, can remove
STOCK‑02	Partial stock (e.g., only 2 left, cart has 3)	Cart auto‑reduces quantity to available stock, shows warning	Quantity adjusted, warning visible
STOCK‑03	Item becomes unavailable (deleted)	Cart removes line item, shows “Item no longer available”	Line item gone, cart total updated

*Manual*: Adjust inventory via admin API, refresh cart, observe.

*Automated*: In test, call inventory‑decrement endpoint, then assert cart DOM changes.

Session Timeout / Cookie Loss

Test	Action	Expected Result	Pass Criteria
SESS‑01	Leave cart idle longer than server session timeout (e.g., 30 min)	Upon next action, redirected to login or cart restored via persistent token	No loss of cart data if persistent storage used; otherwise, else graceful redirect
SESS‑02	Clear browser cookies mid‑session	Cart disappears if relying solely on cookies; if using server‑side cart, data persists	Verify storage mechanism matches design
SESS‑03	Incognito tab → add item → close tab → reopen incognito	Cart empty (if session‑only) or restored (if using localStorage)	Behavior matches spec

*Manual*: Use browser dev tools to clear cookies, wait, attempt checkout.

*Automated*: Set cookie expiration via Selenium driver.manage().deleteCookieNamed("JSESSIONID"), then attempt navigation and assert redirect or cart state.

Network Failure Mid‑Operation

Test	Action	Expected Result	Pass Criteria
NET‑01	Simulate loss of connectivity after “Add to Cart” but before server ACK	Client shows optimistic UI update, then error toast when timeout occurs, option to retry	UI does not permanently show false success; retry restores correct state
NET‑02	Intermittent 500 errors on cart‑update endpoint	Client queues request, retries with exponential backoff, shows “Updating…” spinner	Eventually succeeds or shows persistent error after max retries
NET‑03	Slow response (>10 s) on cart‑load	Loading spinner displayed, fallback to cached cart if available	User sees indication of wait, not a frozen UI

*Manual*: Use Chrome DevTools → Network → Throttle → Offline or custom latency.

*Automated*: With Playwright, await page.route('**/api/cart', route => route.abort()); then check for error handling.

---

Edge and Boundary Cases

Boundary testing pushes the cart to its limits, uncovering issues that rarely appear in functional tests but can cause catastrophic failures under load or unusual user patterns.

Maximum Cart Size

Limit	Test	Expected Result	Pass Criteria
MAX‑ITEMS	Add items until cart holds 500 distinct SKUs (or platform‑defined max)	Cart loads, scrollable, performance stays within 2 s for initial render	No UI freeze, memory usage < 150 MB
MAX‑QTY‑PER‑SKU	Set quantity of a single SKU to 999 999 (if allowed)	Cart calculates total correctly, no integer overflow	Total uses 64‑bit arithmetic, displays correctly formatted number
TOTAL‑VALUE‑CAP	Add high‑priced items to exceed $1 000 000 subtotal	System either blocks with “Order value exceeds limit” or allows with fraud‑check flag	Behavior matches financial‑risk policy

*Manual*: Use a script to add items via API, then verify UI via browser.

*Automated*: Loop via API calls, then assert cart endpoint returns correct counts and totals.

Concurrent Modifications

Scenario	Actors	Expected Result	Pass Criteria
CONC‑01	Two tabs of same user, each adds different item simultaneously	Final cart contains both items, quantities correct	No lost updates, final state = union of actions
CONC‑02	One user adds item, another admin deletes the SKU from catalog	Cart shows item removed or marked unavailable, with warning	Graceful degradation, not a 500 error
CONC‑03	User applies coupon while another user (same account) removes item from cart on different device	Coupon remains valid only if cart still meets coupon conditions; otherwise, coupon removed with notice	Conditional logic respects cart state at validation time

*Manual*: Open two browser windows, perform actions, refresh, verify.

*Automated*: Use Selenium Grid with two sessions targeting same user token, assert final cart via API.

Device Orientation & Form‑Factor Changes

Test	Action	Expected Result	Pass Criteria
ORIENT‑01	Start in portrait, add item, rotate to landscape	Cart page re‑flows, all controls accessible, no overlapping	Layout adapts, touch targets ≥ 48 dp
ORIENT‑02	Foldable device: switch from single screen to dual‑screen mode	Cart persists, no data loss, UI uses available screen real‑estate	State unchanged, UI renders correctly on both screens
ZOOM‑01	Pinch‑zoom to 200 % on cart page	Text scales, layout remains usable, no horizontal scroll unless intentional	WCAG 1.4.4 resize text compliance

*Manual*: Use device emulator or real device, rotate, fold, zoom.

*Automated*: Appium driver.rotate(ScreenOrientation.LANDSCAPE); then assert element visibility.

Internationalization & Localization

Test	Locale	Expected Result	Pass Criteria
I18N‑01	English (US) → German (DE)	All cart labels, placeholders, error messages translated, numbers use comma as decimal separator	Language files loaded, UI mirrors design
I18N‑02	Right‑to‑left (Arabic)	Cart layout mirrors, icons flipped appropriately, text aligns right	Directionality attributes (`dir="rtl"`) present
I18N‑03	Japanese (JP) with cart containing > 10 items	Line wrapping respects word‑break rules, no overflow	No clipped text, line-height adequate

*Manual*: Change device language, verify each string.

*Automated*: Use Playwright await page.context().setLocale('de-DE'); then assert text content matches translation file.

---

Accessibility Testing

Accessibility is not an afterthought; it expands market reach and satisfies legal obligations. The following items map to WCAG 2.2 AA (and where relevant, AAA) criteria, with concrete checks and pass criteria.

Screen Reader Compatibility

Check	Technique	Expected Result	Pass Criteria
SR‑01	Navigate cart with TalkBack (Android) or VoiceOver (iOS)	Each cart item announced as “Product name, price, quantity, remove button”	All meaningful content has accessible label or aria‑label
SR‑02	Activate “Add to Cart” via screen reader gesture	Announcement: “Add to Cart button, tapped” followed by success toast spoken	Feedback delivered via live region (`aria-live="polite"` )
SR‑03	Read coupon error message	Error announced immediately after input loses focus	Error message wrapped in

*Manual*: Enable TalkBack, swipe through cart, listen.

*Automated*: Use axe‑core with axe.run({rules: {screenreader: {enabled:true}}}) and assert no violations.

Keyboard Navigation

Check	Action	Expected Result	Pass Criteria
KB‑01	Tab through cart page	Focus moves logically: product name → quantity input → +/− buttons → remove → proceed	No focus traps, visible focus outline (≥ 2 px contrast)
KB‑02	Activate quantity input, use Arrow Up/Down	Quantity increments/decrements by 1 (or step defined)	Step behavior matches spec
KB‑03	Invoke cart page via shortcut (e.g., Alt + C)	Focus lands on cart header or first item	Custom shortcuts documented and functional

*Manual*: Keyboard only, no mouse.

*Automated*: Use Playwright await page.keyboard.press('Tab'); then await expect(page.locator(':focus')).toHaveAttribute('id', 'qty-input');.

Color Contrast & Visual Presentation

Check	Tool	Expected Result	Pass Criteria
CC‑01	Contrast ratio between cart item background and text	Minimum 4.5:1 for normal text, 3:1 for large text	Meets WCAG AA
CC‑02	Focus indicator contrast	Contrast ≥ 3:1 against adjacent colors	Visible for low‑vision users
CC‑03	Error message background vs. text	Contrast ≥ 4.5:1	Errors readable by all

*Manual*: Use Chrome DevTools → Contrast checker.

*Automated*: Run axe with color-contrast rule enabled.

Touch Target Size

Check	Measurement	Expected Result	Pass Criteria
TT‑01	Touch area of “Remove” button	≥ 48 × 48 dp (or 48 px)	No mis‑taps
TT‑02	Spacing between adjacent interactive elements	≥ 8 dp	Prevents accidental activation

*Manual*: Use UI‑Automatorviewer or Android Studio layout inspector.

*Automated*: Appium can retrieve element bounds and assert width/height ≥ 48.

Reduced Motion & Animation Preferences

Check	Action	Expected Result	Pass Criteria
RM‑01	Enable “Reduce Motion” in OS settings	Cart page animations (e.g., fade‑in of toast) either disabled or replaced with static fallback	Respects `prefers-reduced-media: reduce`
RM‑02	Animate quantity change	If reduce‑motion on, change is instant, no transition	No motion sickness triggers

*Manual*: Toggle OS setting, observe.

*Automated*: Use Playwright await page.evaluate(() => window.matchMedia('(prefers-reduced-media: reduce)').matches); then check for absence of CSS transitions.

---

Security and Privacy

Cart data often contains personally identifiable information (PII) and pricing details that, if exposed, enable fraud or regulatory penalties. This section outlines security‑focused tests that can be automated via OWASP ZAP, custom scripts, or integrated into the CI pipeline.

Data Exposure in Network Calls

Test	Method	Expected Result	Pass Criteria
SEC‑01	Sniff traffic (e.g., with mitmproxy) while adding item	Request/response contains only necessary fields (productId, quantity, token); no raw PII such as full name, email	Payload minimized
SEC‑02	Inspect cart GET response	Does not include user’s address, payment token, or order history	Only cart‑specific data returned
SEC‑03	Check for caching headers	`Cache-Control: private, no-store` for cart endpoints	Prevents proxy caching of sensitive data

*Manual*: Use proxy, view request/response bodies.

*Automated*: In test, assert that JSON schema does not contain disallowed fields (ajv.validate(schema, response.body)).

Cross‑Site Request Forgery (CSRF)

Test	Action	Expected Result	Pass Criteria
CSRF‑01	Submit a form to `/api/cart/add` from a different origin without token	Server rejects with 403 Forbidden	CSRF token validated
CSRF‑02	Attempt to reuse a valid token after session logout	Request fails, token invalidated	Token bound to session
CSRF‑03	Check SameSite attribute on session cookie	`SameSite=Strict` or `Lax`	Mitigates CSRF via cookie settings

*Manual*: Craft HTML form hosted on external domain, submit, observe response.

*Automated*: Use REST-assured to send request without header, assert 403.

Cross‑Site Scripting (XSS) via Cart‑Generated Content

Test	Vector	Expected Result	Pass Criteria
XSS‑01	Inject into product name via admin API (if allowed)	Cart page renders text escaped, script not executed	Output encoding applied
XSS‑02	Attempt to store script in coupon code field	Coupon rejected or escaped; no script execution	Input validation + output encoding
XSS‑03	Evaluate DOM after cart render for any