Before writing a single line of code, you need a test plan. Not a 50-page document. A clear, prioritized list of what to test and what to skip. The biggest mistake beginners make is trying to automate everything. The second biggest mistake is automating the wrong things first.
Not all tests are equal. A failing login test means nobody can use the app. A failing "sort products by price descending" test means a minor inconvenience. Prioritize by business impact.
P0 -- Critical Path: Login, core purchase flow, payment. If these break, the business loses money. Automate first. Run on every PR.
P1 -- High Impact: Search, filtering, cart management, account settings. Important features that most users touch. Automate second. Run on every PR.
P2 -- Medium Impact: Sort order, pagination, email notifications, reviews. Useful but not deal-breakers. Automate third. Run in nightly regression.
P3 -- Low Impact: Footer links, help pages, rarely-used settings. Nice to have. Automate last or skip entirely.
| Priority | Feature | Test Scenarios | Count |
|---|---|---|---|
| P0 | Authentication | Login success, login failure, logout, session persistence | 4 |
| P0 | Purchase Flow | Search → add to cart → checkout → order confirmation (happy path) | 1 |
| P1 | Product Search | Keyword search, filter by category, filter by price range, empty results | 4 |
| P1 | Shopping Cart | Add item, remove item, update quantity, empty cart, cart persistence across pages | 5 |
| P1 | Checkout | Valid shipping info, valid payment, missing required fields, invalid card | 4 |
| P2 | Product Details | Product info display, image gallery, quantity selector, out-of-stock handling | 4 |
| P2 | Order History | View past orders, order status, empty history | 3 |
| P3 | UI/Visual | Login page screenshot, product list screenshot, responsive mobile view | 3 |
That is 28 test scenarios. For a shopping portal, that is excellent coverage. Notice the P0 purchase flow test is a single, long end-to-end test that covers the entire critical path. Some people split this into 5 smaller tests but a single flow test catches integration issues between steps that isolated tests miss.
Never automate a real payment flow with real credit cards. Use test/sandbox payment modes. Stripe has test card numbers (4242 4242 4242 4242). PayPal has sandbox accounts. If your app does not have a test payment mode, mock the payment API.
Before writing page objects, list which pages your tests will touch. This tells you exactly which page objects to build.
| Page Object | Used By Tests | Key Actions |
|---|---|---|
| LoginPage | Auth tests, all authenticated tests | goto, login, expectError, expectLoggedIn |
| ProductListPage | Search tests, purchase flow | search, filterByCategory, filterByPrice, getProductCount, openProduct |
| ProductDetailPage | Detail tests, purchase flow | getProductName, getPrice, setQuantity, addToCart, goToCart |
| CartPage | Cart tests, purchase flow | getItemCount, removeItem, updateQuantity, getTotal, checkout |
| CheckoutPage | Checkout tests, purchase flow | fillShipping, fillPayment, placeOrder, expectConfirmation |
| OrderHistoryPage | Order history tests | getOrderCount, getOrderStatus, expectEmpty |
Q: How do you decide which test cases to automate and which to leave as manual tests?
A: I prioritize by business impact and repetition frequency. P0 tests (login, purchase flow, payment) are automated first because failure means lost revenue. Then P1 features (search, cart, account) that most users interact with. I skip automating third-party integrations I cannot control, rapidly-changing features, and one-time tasks. The rule of thumb: if a test will run more than 10 times and the scenario is stable, automate it. If it is exploratory or changes weekly, keep it manual. I also consider maintenance cost -- a complex visual test that breaks with every CSS change may cost more to maintain than it saves.
Key Point: Start with a prioritized test plan. Automate P0 (critical path) first, then P1 (high impact). Map test scenarios to page objects before writing any code. Skip third-party integrations and rapidly-changing features.
Key Point: Plan before you code -- prioritize by business impact, map tests to page objects, and skip tests that cost more to maintain than they save