Teams that stall with test automation rarely stall on the tool. They stall on choosing what to automate, automate the wrong things first, and lose confidence before the suite becomes useful.
The principle
Automate in order of what it would cost you if it broke silently, not in order of what is easiest to describe or what someone asked for first.
A test that proves customers can still pay you is worth fifty that check page headings.
Week one: prove the loop, on easy ground
Three to five tests, all of them boring on purpose:
- Does the application load and show real data? The simplest possible check, and it catches an astonishing share of deployment failures.
- Can a user sign in? If sign-in is broken, nothing else matters.
- Does the main list or dashboard populate? Not "is it pixel perfect" — does it contain the data it should.
- One read-only journey through the part of the product people use daily.
Choose flows that are read-only where you can. They need no cleanup, cannot corrupt data, and can run as often as you like. Every suite should start here.
Week two to four: the flows that make you money
Now the ones that matter:
- The transaction. Checkout, claim submission, application, booking — whatever your product exists to do.
- The permission boundary. That a user in role A cannot see or do what only role B should. These are rarely tested by hand and expensive when wrong.
- The negative cases. Invalid input is refused, a locked account cannot sign in, an expired item cannot be used. Happy paths get tested by humans daily; failure paths do not.
- The thing that broke last quarter. Go through your incident list. Anything that reached production once will try again.
That last one is the highest-value list in your organization and almost nobody uses it. Your defect history is your test plan.
What to leave alone, at least at first
| Anything with a rotating carousel or live feed | Asserting on content that legitimately changes produces failures nobody can act on. |
| Third-party widgets | Chat bubbles, payment iframes, map embeds. You cannot fix them and they will break your runs. |
| Pixel-level appearance | Unless visual regression is your explicit goal, assert on content and behavior. |
| Email and SMS round-trips | Possible, but a week-six problem. Do not let it block week one. |
| Flows only one person understands | If nobody can describe what "correct" means, a test cannot either. |
How to size a test
One test, one question. "Can a customer complete checkout?" is a test. "Checkout works and the confirmation email arrives and the order shows in admin and the stock decrements" is four, and when it goes red you will not know which part failed.
Long tests also fail more often for uninteresting reasons, and a suite that fails for uninteresting reasons gets ignored.
A sequencing worksheet
For each candidate flow, answer three questions:
- If this broke and nobody noticed for a day, what would it cost? Revenue, compliance, reputation, support load.
- How often does the code behind it change? Frequently changing code needs cover most.
- How hard is it to check by hand? Something checked manually in ten seconds is lower priority than something taking twenty minutes across three roles.
High cost, frequent change, expensive to check by hand — automate that first. Low on all three — it may never be worth automating, and saying so is a legitimate answer.
Coverage is not a percentage
Resist the urge to chase a number. A hundred tests that all check page headings is worse coverage than fifteen that prove your critical journeys, because the first suite gives false comfort and takes longer to run.
Ask instead: if every one of these tests passes, what do I now know is true? If the answer does not include "customers can do the thing we charge them for", the suite is not finished regardless of its size.
Growing coverage as the product changes
Once the critical set exists, the question changes from "what shall we automate" to "what
changed that we do not cover". The functionize-coverage skill exists for exactly this
— it reads change signals against your live suite and proposes ranked gaps. See
Functionize Skills.
When you already have a Selenium or Playwright suite
Do not hand-rewrite it, and do not port all of it. Much of an old suite is tests nobody trusts and flows that no longer exist.
Use the migration skills — functionize-playwright-migrate or
functionize-selenium-migrate — which bring a suite across in small batches you
review as they go. Treat migration as an opportunity to delete the tests that were never earning
their keep.
The one-page plan
- Week 1 — three to five read-only tests. Prove the loop.
- Weeks 2–4 — the money flow, permission boundaries, negative cases, and last quarter's incidents.
- Month 2 — group into orchestrations, schedule the smoke suite, name who reads it.
- Ongoing — add a test whenever a defect escapes. That is the discipline that compounds.