Your checkout flow works perfectly in staging.
Then a user enters an expired promo code during a flash sale, the cart silently fails to update, and they abandon. You never see the error. Your team never filed the bug. That’s a test coverage problem, not a code problem.
Overview
Selenium automation guidance – the flows to script first and why raw Selenium breaks at scale.
Manual vs automated comparison – time, cost, and coverage across every testing dimension.
BotGauge AQaaS – how teams recover 20–30 engineering hours per sprint by automating the full suite.
A free template of the Amazon test cases, pre-built with every scenario from login to order confirmation, priority tags, status tracking.
This post gives you 75+ Amazon test cases across every module that touches revenue: login, search, cart, checkout, payment, order management, security, and performance. And how to automate all of it, so your team stops re-running the same flows before every release.
What Is a Test Plan for Amazon Website?
Before you write a single test case, you need a test plan. A test plan for an Amazon-like website defines:
- Scope – which modules are in scope (login, cart, payments, order history, etc.)
- Test types – functional, regression, security, performance, usability
- Priority – which flows block revenue if they break
- Environment – browsers, devices, operating systems
- Entry/exit criteria – when testing starts and when it’s done
- Automation strategy – which tests run manually vs. on every build
For any Amazon-like eCommerce platform, the minimum test scope looks like this:
| Module | Priority |
|---|---|
| Login & Registration | 🔴 Critical |
| Product Search & Filtering | 🔴 Critical |
| Product Detail Page | 🟡 High |
| Shopping Cart | 🔴 Critical |
| Checkout & Payment | 🔴 Critical |
| Order Management | 🟡 High |
| Security & Access Control | 🔴 Critical |
| Performance & Load | 🟡 High |
| Mobile & Cross-Browser | 🟡 High |
| Accessibility | 🟢 Medium |
Why Amazon-level Testing Is Harder Than It Looks
A few things make eCommerce platforms genuinely difficult to test well.
- Dynamic personalization – Recommendations, pricing, and offers change per user. Static test data doesn’t cover it.
- Third-party integrations – Payment gateways, logistics APIs, inventory systems. Each one is its own failure point.
- Continuous deployment – New features ship weekly. Every release risks breaking something that worked last sprint.
- Cross-device complexity: The same checkout flow must work on a 2019 Android phone and a 2026 MacBook running Safari.
- High-volume edge cases – Flash sales, coupon stacking, concurrent cart updates. These happen rarely in testing and constantly in production.
- One broken payment flow during a sale is a direct hit on revenue. A missed test case is what gets you there.
See how autonomous QA runs your eCommerce test suite in under 30 minutes
75+ Test Cases for Amazon Website
Testing an eCommerce platform like Amazon requires validating every step of the customer journey from product discovery to checkout, payments, order tracking, returns, and account management. The following 75+ test cases for the Amazon website cover the most critical functional, usability, security, and edge-case scenarios to help QA teams build comprehensive test coverage for Amazon-like shopping applications.
Amazon Login Page Test Cases
Login is the entry point to every authenticated flow. Bugs here lock users out or, worse, let the wrong user in.
Functional Login Test Cases
| TC ID | Test case | Input | Expected result |
|---|---|---|---|
| TC_LOGIN_01 | Login with valid credentials | Correct email + password | Dashboard loads, session starts |
| TC_LOGIN_02 | Login with wrong password | Correct email + wrong password | Generic error shown, no session |
| TC_LOGIN_03 | Login with unregistered email | Unknown email + any password | Generic error – no account hint |
| TC_LOGIN_04 | Login with empty email | Blank email field | Inline validation error |
| TC_LOGIN_05 | Login with empty password | Blank password field | Inline validation error |
| TC_LOGIN_06 | Login with both fields empty | Submit blank form | Both fields flagged |
| TC_LOGIN_07 | Forgot password – valid email | Registered email | Reset link or OTP sent |
| TC_LOGIN_08 | Forgot password – invalid email | Unregistered email | Generic message – no account disclosure |
| TC_LOGIN_09 | Account lockout after 5 failed attempts | 5 wrong passwords in sequence | Account temporarily locked |
| TC_LOGIN_10 | Login after lockout cooldown | Wait, then retry | Login succeeds with correct credentials |
| TC_LOGIN_11 | Session persistence – same browser | Login, close tab, reopen | Session active, no re-login needed |
| TC_LOGIN_12 | Session timeout on inactivity | Login, idle 20 minutes | Session expires, redirect to login |
| TC_LOGIN_13 | Password visibility toggle | Click eye icon | Characters revealed/hidden correctly |
| TC_LOGIN_14 | Password strength indicator | Type weak → strong password | Indicator updates in real-time |
| TC_LOGIN_15 | Email format validation | Enter “test@” or “user@domain” | Inline error, form not submitted |
Watch TC_LOGIN_03 closely. If the error says “email not found” instead of a generic message, you’ve disclosed account existence to anyone probing the login form. That’s a security gap, not a UX issue.
Registration Test Cases
| TC ID | Test case | Input | Expected result |
|---|---|---|---|
| TC_REG_01 | Register with all valid fields | Valid name, email, phone, strong password | Account created, OTP sent |
| TC_REG_02 | Register with duplicate email | Already-registered email | Error: “Account already exists” |
| TC_REG_03 | Register with weak password | “123” or “abc” | Strength error, form blocked |
| TC_REG_04 | OTP expiry check | Submit OTP after window closes | Rejected, prompt to resend |
| TC_REG_05 | OTP resend rate limiting | Click resend 5 times quickly | Throttled or blocked |
| TC_REG_06 | Register with invalid phone | Letters in phone field | Inline error, no submission |
| TC_REG_07 | Password reuse prevention | Reuse last password on reset | Error: can’t reuse recent passwords |
See BotGauge run your full eCommerce test suite, from login to order confirmation
Amazon Product Search & Filtering Test Cases
Search drives discovery. A filter that returns out-of-range products, or a search that breaks on a <script> tag, kills conversions before the cart is ever touched.
| TC ID | Test case | Input | Expected result |
|---|---|---|---|
| TC_SEARCH_01 | Search by exact product name | “Apple iPhone 15” | Matching product in results |
| TC_SEARCH_02 | Search with partial keyword | “iPhon” | Relevant results shown |
| TC_SEARCH_03 | Autocomplete suggestions | Type “sam” | Dropdown with matching suggestions |
| TC_SEARCH_04 | Search with blank input | Press Enter, empty field | Error or “enter a search term” |
| TC_SEARCH_05 | Search with special characters | “!@#$” or <script> | Input sanitized, no crash |
| TC_SEARCH_06 | Search with no results | “xyznonexistentproduct123” | “No results found” – page intact |
| TC_SEARCH_07 | Filter by price range | $50 – $100 | Only in-range products shown |
| TC_SEARCH_08 | Filter by brand | Select “Samsung” | Only Samsung products |
| TC_SEARCH_09 | Filter by rating | 4 ⭐️ and above | Sub-4 ⭐️ products excluded |
| TC_SEARCH_10 | Combine multiple filters | Brand + Rating + Price | All 3 applied simultaneously |
| TC_SEARCH_11 | Clear all filters | Click “Clear All” | Unfiltered results restored |
| TC_SEARCH_12 | Sort: price low to high | Apply sort | Ascending price order |
| TC_SEARCH_13 | Sort: price high to low | Apply sort | Descending price order |
| TC_SEARCH_14 | Sort: customer ratings | Apply sort | Highest-rated appear first |
| TC_SEARCH_15 | Pagination | Click page 2, then 3 | Correct products per page |
| TC_SEARCH_16 | Infinite scroll | Scroll to bottom | Next batch loads without reload |
| TC_SEARCH_17 | Filter persistence on sort change | Apply filter → change sort | Filter survives the sort change |
Amazon Shopping Cart Test Cases
The cart is where intent becomes a purchase. Every bug here is a revenue leak.
| TC ID | Test case | Input | Expected result |
|---|---|---|---|
| TC_CART_01 | Add single item | Click “Add to Cart” | Item in cart with correct price |
| TC_CART_02 | Add 3 different items | Add product A, B, C | All 3 appear in cart |
| TC_CART_03 | Add same item twice | Add product → add again | Quantity becomes 2 |
| TC_CART_04 | Increase quantity | Change quantity 1 → 3 | Subtotal updates correctly |
| TC_CART_05 | Decrease quantity | Change quantity 3 → 1 | Subtotal recalculates |
| TC_CART_06 | Decrease quantity below 1 | Set quantity to 0 | Item removed or quantity blocked at 1 |
| TC_CART_07 | Remove item | Click “Remove” | Item gone, total updates |
| TC_CART_08 | Empty cart state | Remove all items | “Your cart is empty” shown |
| TC_CART_09 | Add out-of-stock product | Try adding unavailable item | “Add to Cart” disabled |
| TC_CART_10 | Subtotal accuracy | Add items with known prices | Subtotal = sum of all items |
| TC_CART_11 | Apply valid promo code | Enter working coupon | Discount applied, new total shown |
| TC_CART_12 | Apply expired promo code | Enter expired code | “Code expired or invalid” |
| TC_CART_13 | Apply fake promo code | Random string | “Invalid code” |
| TC_CART_14 | Cart persistence – logged in | Add item → logout → login | Cart items retained |
| TC_CART_15 | Cart persistence – guest to login | Add as guest → log in | Cart merges with existing items |
| TC_CART_16 | Cart sync across devices | Add on desktop → open on mobile | Same cart on mobile |
| TC_CART_17 | Save for later | Move item to “Saved for Later” | Item leaves active cart |
| TC_CART_18 | Move saved item back | Click “Move to Cart” | Item back in active cart |
| TC_CART_19 | Tax accuracy in cart | Check total vs. expected | Tax correct by region |
| TC_CART_20 | Quantity exceeds stock | Set quantity above stock limit | Error or quantity capped |
Note: Test cases for Amazon website in Excel. Ready-to-use template
Download the free Amazon test case template, pre-built with every scenario from login to order confirmation, priority tags, and status tracking
Amazon Checkout & Payment Test Cases
Checkout is the most frequently broken module in any eCommerce platform. Test it harder than anything else.
Shipping Address Test Cases
| TC ID | Test case | Input | Expected result |
|---|---|---|---|
| TC_ADDR_01 | Add valid shipping address | Complete address form | Saved, proceed to payment |
| TC_ADDR_02 | Submit empty required fields | Leave name/pincode blank | Field-level errors, no progression |
| TC_ADDR_03 | Invalid pincode | 3-digit or alphabetic pincode | Inline validation error |
| TC_ADDR_04 | Select saved address | Choose from address book | Auto-fills correctly |
| TC_ADDR_05 | Add new address during checkout | Click “Add New Address” | Form opens, saves correctly |
| TC_ADDR_06 | Same billing and shipping | Check “Use same address” | Billing pre-filled |
| TC_ADDR_07 | Edit existing address | Change street name | Updated address saved |
| TC_ADDR_08 | Delete saved address | Remove from book | Removed, no orphan records |
Payment Test Cases
| TC ID | Test case | Input | Expected result |
|---|---|---|---|
| TC_PAY_01 | Pay with valid credit card | Correct card details | Order placed, confirmation shown |
| TC_PAY_02 | Pay with expired card | Past expiry date | Payment rejected, clear error |
| TC_PAY_03 | Pay with invalid card number | Random 16 digits | Validation error before gateway call |
| TC_PAY_04 | Pay with wrong CVV | Correct card, wrong CVV | Payment fails, no order created |
| TC_PAY_05 | Cash on delivery (COD) | Select COD | Order placed, COD confirmation shown |
| TC_PAY_06 | UPI payment | Valid UPI ID | Redirected to UPI app, payment completes |
| TC_PAY_07 | Payment gateway failure | Trigger test failure | Error shown, retry option offered |
| TC_PAY_08 | Cancel payment mid-process | Click Cancel at gateway | No order created, cart intact |
| TC_PAY_09 | Retry after failed payment | First fails → retry | Order placed on second attempt |
| TC_PAY_10 | Double-click “Place Order” | Rapid double-click on submit | Only 1 order created |
| TC_PAY_11 | Order confirmation screen | Complete payment | Order ID, summary, ETA displayed |
| TC_PAY_12 | Order confirmation email/SMS | Complete payment | Email and SMS within 2 minutes |
| TC_PAY_13 | Apply coupon at checkout | Valid code at payment step | Discount in final total |
| TC_PAY_14 | Final order summary accuracy | Review before payment | Items + tax + shipping = correct total |
| TC_PAY_15 | Saved payment method | Select stored card | Pre-filled, needs CVV only |
TC_PAY_10 is one of the most commonly skipped test cases. A double-click on “Place Order” on a slow network creates 2 orders – double charge, double fulfillment. It’s an ops nightmare that shows up after a sale weekend, not during testing.
Amazon App Test Cases (mobile-specific)
Statista report shows that mobile devices account for over 77% of eCommerce traffic. These scenarios are specific to app behavior – they won’t surface in desktop testing.
| TC ID | Test case | Expected result |
|---|---|---|
| TC_APP_01 | App launch time | Fully loaded within 3 seconds |
| TC_APP_02 | Portrait to landscape switch | Layout adjusts cleanly, nothing cut off |
| TC_APP_03 | Search via mobile keyboard | Native keyboard opens, input accepted |
| TC_APP_04 | Add to cart on mobile | Cart updates, mini-cart shown |
| TC_APP_05 | Checkout on 360px screen | All fields visible and tappable |
| TC_APP_06 | Payment on mobile | Gateway loads within app |
| TC_APP_07 | Push notification on order update | Notification delivered and tappable |
| TC_APP_08 | Low network behavior (2G) | Graceful loading or offline message |
| TC_APP_09 | WiFi to 4G switch mid-session | No crash, session maintained |
| TC_APP_10 | Biometric login | Fingerprint/FaceID succeeds |
| TC_APP_11 | Deep link to product | Product page loads correctly in app |
| TC_APP_12 | Back button in checkout | Returns to previous step, data intact |
Order Management Test Cases
| TC ID | Test case | Expected result |
|---|---|---|
| TC_ORD_01 | View order history | All past orders listed with status |
| TC_ORD_02 | View order details | Item, price, address, tracking visible |
| TC_ORD_03 | Cancel before dispatch | Cancellation accepted, refund triggered |
| TC_ORD_04 | Cancel after dispatch | Blocked or returns flow initiated |
| TC_ORD_05 | Track shipment | Real-time status, tracking number visible |
| TC_ORD_06 | Initiate return/refund | Form submits, RMA generated |
| TC_ORD_07 | Download invoice | PDF opens on all browsers |
| TC_ORD_08 | Reorder from history | Items added to cart from past order |
| TC_ORD_09 | Order status email updates | Shipped/delivered emails arrive correctly |
| TC_ORD_10 | Review after delivery | Review form accessible, submits correctly |
Security Test Cases for Amazon Website
Security bugs on eCommerce platforms aren’t just bugs – they’re legal exposure. These test cases run on every release, no exceptions.
| TC ID | Test case | Expected result |
|---|---|---|
| TC_SEC_01 | XSS in search bar | <script>alert(1)</script> – no execution |
| TC_SEC_02 | XSS in review/comment fields | Input stripped or rejected |
| TC_SEC_03 | SQL injection in login | ‘ OR 1=1 — – auth fails, no DB error exposed |
| TC_SEC_04 | Access another user’s account via URL | 403 or redirect to own dashboard |
| TC_SEC_05 | Access /admin as regular user | Access denied, redirect |
| TC_SEC_06 | HTTPS on all pages | Every URL uses HTTPS |
| TC_SEC_07 | Cookie security | Cookies flagged Secure + HttpOnly |
| TC_SEC_08 | Brute force on login | CAPTCHA or lockout after 10 attempts |
| TC_SEC_09 | CSRF on cart/order actions | Cross-origin POST rejected |
| TC_SEC_10 | Session invalidation on logout | Pasting previous URL → redirect to login |
| TC_SEC_11 | Sensitive data absent from URL | Card numbers, passwords not in query string |
| TC_SEC_12 | Password not in page source | DOM inspection shows no plain-text value |
Performance Test Cases
| TC ID | Test case | Pass criteria |
|---|---|---|
| TC_PERF_01 | Homepage load | Under 3 seconds |
| TC_PERF_02 | Search result response | Results within 1 second |
| TC_PERF_03 | Product page load | Under 2 seconds including images |
| TC_PERF_04 | Cart update response | Quantity/remove within 500ms |
| TC_PERF_05 | Checkout page load | Payment page under 3 seconds |
| TC_PERF_06 | 1,000 concurrent users | No crash |
| TC_PERF_07 | Flash sale: 5,000 users add same product simultaneously | No oversell, no crash |
| TC_PERF_08 | API response time | Backend calls under 200ms |
| TC_PERF_09 | Image loading | Lazy loading confirmed |
| TC_PERF_10 | 30-minute session | No memory leak, no UI degradation |
Selenium Test Cases for Amazon: What to Automate First
If you’re using Selenium for eCommerce automation, start with these 6 flows. They cover the highest revenue risk and give you the fastest payback on scripting time.
1. Login flow – Automate valid login, invalid credentials, lockout. Every authenticated test depends on this working.
2. Search and filter – Run the same search with hundreds of keyword inputs. Catch edge cases that manual testing misses by volume alone.
3. Add to cart + quantity update – Add a product, change quantity, verify subtotal. Core revenue flow – run it on every build.
4. Checkout end-to-end – Add item → address → payment → confirmation. This catches integration failures across every module at once.
5. Promo code validation – Valid, expired, fake codes. Coupon logic breaks silently. Automation catches it before a user does.
6. Order confirmation – Verify order ID, email dispatch, order in history. Confirms your back-end and email service are talking.
Recommended Selenium setup:
- Framework: Page Object Model (POM)
- Language: Java + TestNG or Python + pytest
- CI/CD: Jenkins or GitHub Actions
- Parallel runs across browsers and devices
One honest problem with raw Selenium: it’s brittle. A changed button ID, a renamed CSS class, a layout shift – your suite breaks. Maintaining it for a large eCommerce platform is practically a full-time role. BotGauge handles that maintenance automatically using a robust self-healing engine.
Your QA team shouldn't spend sprint week running cart and checkout tests by hand.
Manual Vs Automated Amazon Test Cases
| Criteria | Manual | BotGauge |
|---|---|---|
| Full run of 75 cases | 8-12 hours | Under 30 minutes |
| Human error rate | High – fatigue sets in around test 40 | Zero |
| Regression on every build | Not feasible | Runs by default |
| Cart + checkout combo tests | Skipped under deadline pressure | Always run |
| Mobile + cross-browser | Hours of parallel effort | Parallelized |
| After a UI change | Manual rework | Self-healing |
| Security test runs | Skipped in most manual cycles | Scripted, repeatable |
| CI/CD | Not possible | Native |
| Reporting | Spreadsheets | Automated pass/fail with coverage |
| Cost at scale | Grows every sprint | Fixed |
How to Test an Amazon Website: Step-by-Step
- Step 1 – Define scope
List every module. Rank by revenue impact: login → search → cart → checkout → payment.
- Step 2 – Write test cases per module
Cover positive, negative, and boundary scenarios. Use the tables above as your base.
- Step 3 – Set up your environment
Configure test accounts, sandbox payment gateways, mock inventory states: in-stock, out-of-stock, low-stock.
- Step 4 – Run functional tests first
Confirm the happy path works end-to-end before testing edge cases.
- Step 5 – Run negative and boundary tests
Invalid inputs, expired coupons, failed payments, concurrent cart updates.
- Step 6 – Run security tests
XSS, SQLi, session hijacking, HTTPS. Do this in staging – never production.
- Step 7 – Run cross-device tests
Chrome, Firefox, Safari, Edge. iOS and Android. At 360px, 768px, and 1440px.
- Step 8 – Run performance tests
Simulate load. Find bottlenecks before they become incidents.
- Step 9 – Automate what repeats
Everything in steps 4-7 that runs on every build should be automated. Manual testing stays for exploratory work and UX judgment calls.
- Step 10 – Connect to CI/CD
Every code push triggers the suite. Failing tests block the release.
How BotGauge Automates Amazon Test Cases
Manually creating and maintaining test cases for a complex shopping platform is slow and difficult to scale. BotGauge eliminates scripting by using AI agents to understand user flows, generate comprehensive test scenarios, execute them across critical shopping journeys, and adapt automatically as the application evolves. This helps engineering teams achieve faster, more reliable test coverage with minimal maintenance.
The Autonomous QA as a Solution model combines AI agents with domain-specialized QA experts to own your testing outcomes end-to-end. Our AI agents generate, execute, and maintain your test suite, while human QA experts validate coverage, refine edge cases, and continuously improve quality, eliminating manual test creation and maintenance without compromising reliability.
Here’s what that looks like:
- AI-generated test cases – Describe your login flow, cart behavior, or checkout steps in plain English. BotGauge writes the test cases and automation scripts.
- Autonomous execution – Tests run on every commit. No trigger, no scheduled runs, no missed cycles the day before a release.
- Self-healing – When your cart button changes or the checkout layout shifts, BotGauge updates the test. No broken backlog, no maintenance sprint.
- E2E coverage – Login → search → cart → checkout → payment → order confirmation. One suite, full journey.
- Dedicated FDE pod – Our domain-specialized QA experts review coverage, catch edge cases the AI misses, and validate security and UX scenarios.
- CI/CD ready – Plug BotGauge directly into your current DevOps and CI/CD pipeline.
80% test coverage guaranteed in 2 weeks. Zero setup. Zero scripting.
Conclusion
eCommerce bugs don’t announce themselves. A cart that silently drops a promo. A retry that creates 2 orders. A session that never expires. A filter that shows out-of-range prices. These show up in revenue dashboards and customer complaints – not in your error logs. BotGauge handles the repetitive work. Your team focuses on the testing that actually needs a human.
Frequently Asked Questions
What are Amazon test cases in software testing?
What are the most critical Amazon test cases?
How do you write Amazon login page test cases?
What are Amazon shopping cart test cases?
How do I automate Amazon test cases with Selenium?
What's the difference between web and app Amazon test cases?
