The automation ROI test

Not everything should be automated. Automation is an investment: you spend time writing and maintaining a test so it can pay you back every time it runs. A test that runs once never pays for itself. A test that runs on every commit for two years pays for itself hundreds of times over.

Three questions decide whether a check is worth automating:

1. How often will it run?

Regression checks that repeat every release are prime candidates. A smoke test for login runs thousands of times a year. A check for a one-off data migration runs once — do it by hand.

2. How stable is the feature?

Automating a screen that's redesigned every sprint means rewriting the test every sprint. Wait for the churn to settle. Stable core flows — login, checkout, search — are where automation shines.

3. What does a miss cost?

If a payment flow silently breaks, the business bleeds money. High-cost failures justify automation even when they're rare, because the machine never forgets to check.

The test pyramid — where UI automation fits

You'll hear about the test pyramid: lots of fast unit tests at the bottom (developers write these), a middle layer of API/integration tests, and a small top layer of end-to-end UI tests. UI tests are the slowest and most fragile kind, so teams keep them focused on critical journeys. As an automation engineer you'll work mostly in the top two layers — and knowing the pyramid explains why your team doesn't want 2,000 UI tests.

if (runsOften && featureIsStable && failureIsCostly) {
    automate();          // pays back many times
} else if (exploringNewFeature) {
    testManually();      // human judgment wins here
} else {
    reassessNextRelease();
}