Automation isn't just writing scripts—it's making good decisions before you start typing.
Before you automate anything, stop and ask: What are we trying to achieve? Automation is a tool—not a goal. Its real power comes when it’s aligned with clear objectives.
There are many reasons to introduce test automation. Identifying your main goals helps you avoid waste, frustration, and overengineering.
Ask yourself:
- Do we need faster feedback during development and release?
- Are we aiming for more stability across repeated builds?
- Do we want reusability and scalability in testing?
- Will our automation be part of a CI/CD pipeline?
The Automation Pyramid (Unit → API → UI)
The automation pyramid is a widely accepted model for balancing different types of automated tests based on their cost, speed, and reliability. It builds up by unit, API (application programming interface) and UI (user interface) tests.
Base: Unit Tests: focuses on unit functions, fast and cheap tests, catches bugs in early state
- What: Small, low-level tests that check individual functions or classes.
- Why: They run in milliseconds and give immediate feedback when code breaks.
- Who: Typically written by developers as part of the development cycle.
Middle: Integration/API Tests: focuses on module interactions and busniess logic, medium speed and cost, validates real use cases
- What: Tests that validate how systems/modules talk to each other.
- Why: Ideal for checking workflows, API endpoints, and business rules without involving the UI.
- Who: Testers, automation engineers, or developers.
Top: UI Tests: focuses on visual behaviour and user paths, slow paced, and has high costs. Confirms full workflows
- What: Simulate actual user behavior—clicks, forms, navigation.
- Why: Validate the look and feel, and final user paths.
- Who: Automation testers using tools like Selenium, Playwright, etc.
Decide what to automate first:
Not everything that can be automated should be.
Start with high-value and low-risk candidates:
- Stable features that won’t change next sprint.
- Regression tests you run every release or sprint.
- Core user flows—things users always do (e.g. login, checkout, search).
- Data-driven tests with predictable, repeatable results.
Avoid automating:
- New, rapidly changing features.
- Visual/UI-heavy designs still in flux.
- Once-only scenarios or edge cases with low impact.