Automation strategy and the test pyramid
The test pyramid — the classic model of test distribution:
- Unit (base, most numerous): fast, cheap, precise localisation — written by developers
- Integration/API (middle): service contracts, business logic without UI
- E2E UI (top, fewest): critical user flows — slow, expensive, flaky-prone
Anti-pattern: the ice cream cone (inverted pyramid) — everything at UI level, the suite runs for hours and breaks constantly.
Rule: verify at the LOWEST possible level. For discount calculation write an API/unit test, not a UI test; the UI test should only check "the discount is visible on the page".
What to automate (ROI criteria):
- Frequently executed: regression, smoke, per-PR checks
- Stable functionality (settled specification)
- Critical business flows (payment, registration)
- Highly combinatorial (data-driven: 50 currency pairs)
- Tedious/error-prone for humans
What NOT to automate:
- One-off checks
- Fast-changing UI (rewritten every sprint)
- Visual/UX judgment (beauty, comfort)
- Exploratory testing — that's human work
A middle-interview favourite: "How do you justify automation ROI?" Know the simple formula: benefit = (manual execution time × frequency × period) − (writing time + maintenance time). Forgetting maintenance cost is the most common mistake.