Manual to Automation: What to Automate First

Automate your regression tests first, starting with the handful of flows your team re-runs by hand before every single release: login and authentication, the primary money path (checkout, booking, order submission, payment), and the API endpoints those flows depend on. Those tests are executed constantly, they change slowly, and a failure in them blocks a release. Everything else on your manual suite can wait. The teams that stall on automation almost always stall because they tried to convert the whole suite instead of the twenty cases that actually earn back the setup time.

This guide covers how to pick those first cases with a scoring model instead of intuition, what to deliberately leave manual for the first year, why manual test cases should be rewritten instead of transcribed step-for-step, and how to keep the manual and automated halves of your suite visible in one place once both exist.

The short answer, in priority order

If you want a ranked list to start from on Monday morning, this is it. The order reflects value per hour of setup, not how impressive the test looks in a demo.

Notice that the full regression suite, which is what most teams reach for first because it is the biggest pile of manual work, sits at the bottom. Automating four hundred cases against an application you have not yet learned to automate reliably produces four hundred maintenance liabilities and a red pipeline nobody believes.

Why teams pick the wrong first tests

Three failure patterns show up again and again in QA teams making this transition.

Automating by suite, not by value. The manual regression suite is organized by feature area because that is how humans navigate it. Teams start at the top of the list and work down, which means the first thirty automated tests cover whatever feature happens to be alphabetically first. There is no reason that feature should be the one carrying the most release risk.

Starting with the hardest thing to prove the tool works. Someone picks the gnarliest multi-tab, file-upload, third-party-redirect scenario as a proof of concept. It takes three weeks, it is flaky when it finishes, and the team concludes automation does not work for their product. The proof of concept should be boring on purpose.

Automating features that are still being redesigned. A test written against a screen that changes next sprint is throwaway work. The rate of change of the feature matters more than the complexity of the test.

There is a fourth pattern that is subtler: the assumption that a manual test case converts one-to-one into an automated one. It does not, and that is worth its own section further down.

A scoring model you can actually run

Score the candidates instead of arguing about them. Four factors, each 1 to 5, and one of them subtracts.

Total the first four, subtract the fifth, and you get a number between -1 and 19. Anything scoring 13 or above belongs in your first sprint of automation work. Anything below 6 should stay manual until something changes.

Here is the model applied to a realistic set of candidates from a B2B SaaS product, so you can see how it separates cases that look similar on a manual test plan.

The interesting rows are the ones that fall out. The onboarding wizard is a high-traffic, high-impact flow, and every instinct says automate it. Its stability score of 1 kills it, because a test written this sprint gets rewritten next sprint. Come back when the redesign ships. The tablet chart rendering is a genuinely useful check that a human does in ninety seconds and a script does badly, because "renders correctly" is a judgement call unless you invest in visual comparison tooling.

Run this scoring exercise as a one-hour session with two people, one who knows the product risk and one who knows the automation stack. Do not do it alone, and do not do it in a spreadsheet you will lose. Score the cases where they live, in your test management system, so the scores stay attached to the cases and survive the next reorganization.

What to leave manual, deliberately

Deciding what stays manual is half the strategy, and it is the half most guides skip. These categories cost more to automate than they return, sometimes permanently.

• Exploratory testing. The value comes from a human forming and discarding hypotheses in real time. A script cannot be surprised.
• Usability and visual judgement. "Is this readable, is the hierarchy clear, does this error message make sense" has no assertion. Visual regression tools compare pixels against a baseline, which is a different question from whether the design works.
• One-off and low-frequency checks. A test run twice a year will never repay a day of scripting plus ongoing maintenance.
• Anything gated behind an external system you cannot control. Third-party services without a stable sandbox produce tests that fail for reasons unrelated to your code, which is the fastest way to teach a team to ignore red builds.
• Features under active redesign. Automate after the design settles, not during.
• Tests whose expected result is written as "verify it looks right." These are not automatable as written. Some of them become automatable once someone defines what "right" means as a checkable condition. Most do not.

That last category is larger than most teams expect. When you audit a mature manual suite, a real share of the cases turn out to be vague, duplicated, or both, and they were never a good specification even for a human. Clean that up before you script anything, or you will encode the mess. We wrote about that audit in detail in how to find duplicate and low-quality test cases.

Rewrite the test, do not transcribe it

A manual test case is written for a reader who has context, judgement, and eyes. An automated test is written for a machine that has none of those. Transcribing step-for-step produces long, brittle UI scripts that mimic a human clicking through the interface, which is the most expensive and least reliable way to check most things.

The advice to keep the purpose of a manual test and discard nearly everything else about its structure comes from Gojko Adzic, David Evans, and Tom Roden in Fifty Quick Ideas to Improve Your Tests, and it holds up. Take the intent, then ask where that intent can be verified most cheaply.

A worked example. The manual case reads:

• Log in as an admin
• Navigate to Users
• Click Invite User
• Enter an email address and select the role Editor
• Click Send
• Verify the confirmation message appears
• Verify the user shows in the list with status Pending
• Verify the invitation email arrives

Transcribed literally, that is one long UI test with eight failure points, an email inbox dependency, and a login step repeated in every other test in the suite. Rewritten by intent, it becomes three cheaper tests:

• An API test that posts an invitation and asserts the response plus the resulting user record and status. Runs in under a second, no selectors involved.
• A short UI test that fills the invite form and asserts the confirmation state, with the login handled by injecting a session instead of driving the login screen. This is the part that genuinely needs a browser.
• An integration check on the mail provider, run separately and less often, because email delivery is a different risk from invitation logic.

Same coverage, roughly a quarter of the runtime, and when it fails you know which layer broke. Splitting by layer this way is the practical version of the test pyramid that Mike Cohn described in Succeeding with Agile: push verification to the cheapest, fastest level that can answer the question, and reserve full end-to-end tests for the flows where the integration itself is the risk.

The first 90 days, sequenced

A rough timeline that works for a team of three to six QA engineers with no existing automation. Adjust the calendar, keep the order.

Weeks 1–2: audit and score

Inventory the manual suite. Delete or merge the duplicates. Score the survivors with the model above. Pick the 10–20 cases that will be your first automated suite, and mark them in your test management system so the selection is visible to everyone and not stuck in one person's head.

Weeks 3–4: choose the stack and prove it on something boring

Pick the framework, set up the project, and automate login plus one happy path. The goal of this phase is a green run in CI, not coverage. If your product is a web application, Playwright and Cypress are the default choices in 2026, and both have mature reporting stories. Decide now where results will be stored, because retrofitting that later is painful.

Weeks 5–8: build the smoke suite and wire it into CI

Get to 15–25 stable tests that run on every merge and finish fast enough that people wait for them. Any test that fails intermittently in this phase gets fixed or removed immediately. A smoke suite you cannot trust is worse than no smoke suite, because it trains the team to click re-run.

Weeks 9–12: expand into API regression and data-driven cases

This is where the volume comes cheaply. API tests are faster to write, faster to run, and far more stable than UI tests, and they cover the logic underneath several manual UI cases at once. By the end of this window you should have automation and manual execution reporting into the same place, so release readiness is one view instead of two spreadsheets and a Slack thread.

Metrics that tell you whether it is working

The 2026 State of Testing Report from PractiTest found that the dominant KPIs teams are measured on remain test coverage, cited by 56.4% of respondents, and automation coverage at 40.1%, while only 8.6% of teams are evaluated on business impact. Both of the popular metrics measure volume of work, not whether that work protects anything.

Track these instead, from the first week:

Escaped defects in automated areas is the one to watch hardest. A suite that runs green while bugs ship is a suite full of tests that navigate without asserting, and it is common enough that you should check for it deliberately.

Budget for flakiness before it happens

The cost that surprises teams six months into automation is not writing tests. It is maintaining them and chasing failures that were never real.

Google's testing team published data showing that around 84% of transitions from passing to failing in their continuous integration system came from flaky tests, not genuine regressions, and that roughly 16% of their tests exhibited some flakiness. Atlassian's engineering team reported losing over 150,000 developer hours a year to flaky test investigation. Slack's engineering blog described build failures caused by test jobs running at about 57%, brought down below 4% after they built dedicated detection and suppression. An industrial case study presented at ICST 2024 measured a team of roughly 30 developers spending 2.5% of productive time on flaky tests, with about half of that on repairs alone.

Two practical consequences for a team starting out. First, set a flakiness threshold from day one, investigate anything failing intermittently above 2%, and quarantine it while someone investigates. Second, make sure whatever stores your results can actually calculate that rate, because a rate you cannot see is a rate nobody manages. Retry counts buried in CI logs do not count.

The wider context from the World Quality Report 2025-26, published by Capgemini and Sogeti with OpenText, is that automation maturity remains hard to reach for reasons that have little to do with picking a framework: 60% of organizations report struggling with secure, scalable test data, and 58% cite difficulty adopting AI-powered tools. On the AI side, the same report found 43% of organizations experimenting with generative AI in QA while only 15% have scaled it enterprise-wide. Test data and infrastructure will slow your first automation project more than test-writing speed will.

Where the test management system fits

The transition from manual to automated testing creates a coordination problem that catches teams by surprise. Manual cases live in one system. Automated results live in CI. Nobody can answer "are we ready to release" without opening both and doing arithmetic by hand. This is the specific problem a test management system exists to solve, and it matters more during the transition than at either end of it, because the transition is the period when your coverage is genuinely split.

QAM Hub was built by QA Madness, a QA outsourcing company with roughly 150 engineers, which shaped what it prioritizes for teams in exactly this position. A few capabilities that apply directly to a first automation project:

• Automated results linked to manual cases. Adding a TC-<number> prefix to an automated test title links its results back to the corresponding manual case automatically. One automated test can cover several manual cases. As you automate, the manual suite visibly shrinks instead of quietly duplicating.
• Playwright and Cypress reporters, plus a generic XML reporter. Results push after each run through official npm packages, and any other framework can report through the generic XML path, so the choice of stack in week 3 does not lock you in later. Setup details are in the guides for Playwright and Cypress.
• Traces, video, and screenshots stored with each run. The artifacts you need to diagnose a failure sit next to the result and do not expire with the CI job.
• Flaky detection and Test Explorer analytics. Pass rate, stability score, flakiness rate, and average duration over a 7–90 day window, with regressions and chronic failures identified across runs. Admins can quarantine a flaky test so it stops poisoning the signal while someone fixes it.
• Coverage reporting across both halves. Manual and automated execution appear in the same coverage and release-readiness reports, which is the view that makes the release decision.
• Checklists. Column-based checklist suites cover the release-readiness and exploratory work that should stay manual, so it stays tracked instead of living in someone's notes.

Two honest limits. QAM Hub is a newer platform, so its community is smaller than tools that have been around for a decade. It integrates with Jira through a two-way connection, alongside GitHub Issues, GitLab, Asana, Linear, Redmine, and Trello, but tests do not live as Jira issues, so a team committed to a fully Jira-native workflow may prefer a Jira app. Pricing is two straightforward per-user plans with no separate charge for view-only stakeholders, which matters when managers want to read reports without adding licence cost.

Disclosure: QAM Hub is built by QA Madness, who published this guide. Details about other tools reflect current public information.

Whatever system you use, the requirement is the same: automated results and manual results have to land in one place, linked to the same cases, or your coverage picture stays fictional. There is more on the mechanics in managing automated test results in a TMS, and if you are still running the manual suite out of a spreadsheet, this is the point where spreadsheets break.

Where AI helps and where it does not

AI-assisted test generation has become a standard feature across the category, and it is genuinely useful during this transition for a narrow set of tasks: drafting test cases from a requirement or a screenshot, flagging duplicate and vague cases during the audit phase, and suggesting fixes for unclear expected results. That accelerates the cleanup work in weeks 1–2 considerably.

What AI does not do well yet is decide your automation strategy. Which twenty cases carry your release risk depends on knowledge of your product, your users, and your incident history that no model has. Treat generated output as a draft that a QA engineer reviews and owns, which is the human-in-the-loop position we take across the board. There is a fuller breakdown in what AI test management tools really do in 2026.

FAQ

What should you automate first when moving from manual testing?

Start with the smoke suite: login, core navigation, and one end-to-end happy path, followed by API regression on the endpoints those flows depend on. These run on every build, have objectively checkable outcomes, and change slowly. Full regression of the entire manual suite comes last, after the pipeline is stable enough that people trust a red build.

How many tests should be in a first automated suite?

Between 10 and 25. Small enough to keep green, large enough to catch a broken deployment. Teams that start with two hundred tests spend the following quarter fixing them instead of adding coverage. Expand only after the initial suite has run reliably for several weeks.

Should you automate UI tests or API tests first?

Automate a minimal UI smoke path first so you have an end-to-end signal, then move to API tests for volume. API tests run faster, break less, and verify business logic without depending on selectors. Many manual UI cases can be replaced by an API assertion plus a much shorter browser check.

What percentage of manual test cases should be automated?

There is no correct percentage, and chasing one leads to automating low-value tests to hit a number. A useful reframing: automate the cases you re-run every release, and measure the reduction in manual regression hours instead of the coverage percentage. Some suites reach 70% automation, others plateau near 30% and are perfectly healthy, particularly where the product depends on visual judgement or heavy exploratory work.

Can you automate exploratory testing?

No, and it should not be a goal. Exploratory testing works because a person forms hypotheses and follows unexpected behaviour, which a script cannot do. What you can automate is everything repetitive around it, which frees the hours that make exploratory testing possible. Checklists are a better fit than test cases for keeping that work structured.

How long before automation pays for itself?

For a well-chosen first suite, the smoke tests usually pay back within one to two release cycles because they catch broken builds that would otherwise consume manual hours. Broader regression automation takes longer, often six to twelve months, and the payback depends heavily on maintenance cost. A suite requiring constant repair can stay net negative indefinitely, which is why feature stability is a scoring factor.

Do manual testers need to learn to code?

Some coding ability helps, and the transition is a reasonable moment to build it. It is not a prerequisite for contributing. Test design, risk assessment, deciding what deserves automation, and reviewing generated test cases all move the needle more than writing selectors, and they draw on product knowledge that automation engineers usually lack. The strongest teams pair the two skill sets instead of converting everyone.

What is the biggest mistake teams make in this transition?

Transcribing manual test cases into automated scripts step by step. Manual cases are written for a reader with judgement and context. Rewriting by intent, and pushing verification to the cheapest layer that can answer the question, produces faster and far more stable tests than literal conversion.

The decision to make this week

Pick twenty cases, not two hundred. Score them on frequency, failure impact, determinism, and stability, subtract what they will cost to build and maintain, and take the top of the list regardless of which feature area they land in. Get those running green in CI, reporting into the same place as your manual results, before you write test twenty-one.

The teams that succeed at this are rarely the ones with the best framework. They are the ones who automated the right small set first, kept it trustworthy, and could still answer "what is covered and are we ready to ship" while half their suite was still being executed by hand. If you want to see how different tools handle that split, our comparison of test management tools in 2026 covers the options.