Automating the wrong thing faster is still the wrong thing. Most disappointing automation projects were not badly coded; they automated the wrong cases. This is the rule Apex Automation Team applies before writing a single test.
1. The ranking rule
Score every candidate on three things and multiply them: how often it runs, how much it costs the business when it breaks, and how stable it has been. High on all three, automate now. Low on stability, leave it alone no matter how critical it is, because you will spend more time repairing the test than running it by hand.
A useful gate: automate a case only after it has passed manually across three consecutive releases without the steps needing a rewrite. If it keeps changing, the design has not settled.
2. The strong candidates
- Stable high-traffic paths: login, registration, search, cart, checkout, core account actions. These change slowly and every user touches them.
- Smoke and sanity checks that should run on every single build.
- Data-driven cases with many permutations: currencies, locales, tax rules, payload variations.
- Cross-browser and cross-device compatibility sweeps, which are pure repetition.
- API contract tests. Fast, stable, close to the logic and far cheaper to maintain than the equivalent through the interface.
3. The cases that should stay human
- Interfaces still under active design. Every sprint moves the markup and every move breaks the test.
- One-off checks with no repeat value.
- Anything that is a judgement: does this feel slow, is this copy confusing, does this layout look wrong. A script cannot tell you the button feels wrong. A person can.
- Features scheduled for removal.
- Scenarios that genuinely run once per release, where setting up automation costs more than running them.
4. Budget for maintenance before you start
A suite is a codebase and it decays. Plan for roughly a fifth of your testing effort going into suite hygiene rather than new tests: fixing selectors after redesigns, deleting tests for removed features, and hunting flakiness. Aiming for seventy to eighty per cent automated coverage of the repeatable cases, with the rest deliberately manual, is a healthier target than chasing a hundred per cent that nobody can keep green.
5. Run the right subset at the right moment
- On every pull request: smoke, under ten minutes, or developers will start ignoring it.
- On merge to main: the broader integration set.
- Nightly: the full cross-browser matrix.
- Before release: everything, including performance and the longer data-driven runs.
6. The real return
The number worth quoting is not tests written, it is regression time. Cutting a manual regression pass from three or four days to under one is what lets a team ship weekly instead of monthly. The moment the suite goes flaky that number stops being believed, which is why credibility, not coverage, is the measure that matters.
Most clients end up with both: a trained team on the moving parts and a suite guarding the settled ones. See software testing and QA or manual and automated testing compared.
Quick checklist
- Score candidates on frequency times business cost times stability
- Automate only after three consecutive releases with no rewrite
- Automate the money paths before anything else
- Prefer API contract tests over interface tests where possible
- Leave judgement, usability and unsettled interfaces to people
- Budget about a fifth of testing effort for suite maintenance
- Measure regression time saved, not the number of tests written
Frequently asked
Should we aim for a hundred per cent automation?
No. Seventy to eighty per cent of the repeatable cases, with the rest deliberately manual, is a healthier target. The last stretch usually costs more in maintenance than it ever returns.
We have no tests at all. Where do we start?
With a manual cycle on the critical journeys, so you learn what actually breaks. Automate those same journeys once they have been stable for a few releases.
Who maintains the suite afterwards?
You own it, so either team can. We hand it over documented in your repository and can keep maintaining it on a retainer or step back once your developers are comfortable.