Manual to Automated Testing Migration: 4 Phases

Start at the bottom of the pyramid, most guides say. Automate your units first, then integration, then end-to-end, because that's the cheapest and most stable layer to touch. It's fine generic advice, and it's wrong for a specific reader: a QA lead or engineering manager at a company that already runs a real manual regression suite on a DevOps release cadence, shipping several times a week, where somebody upstream just asked for a migration plan.

If that's you, and you're Series A through Series C rather than pre-seed with zero tests, and your problem isn't "are the AI-generated tests we already have even real" (a different question with its own answer), the honest starting point is that your unit tests are almost never where the manual hours go. They go into a person clicking through the same fifteen screens before every release. Any migration order that doesn't start by finding that person's hours is optimizing the wrong layer.

Where to start automating manual tests: find the bottleneck first

Before picking a phase, measure. Not a survey. A two-week tally.

For every flow currently tested by hand, checkout, signup, the admin dashboard, the CSV export nobody remembers is manual, track four numbers: how many times a person ran it in the last two weeks, how many minutes each run took, who ran it (an engineer pulled out of a sprint, or someone whose job is QA), and whether a release was ever held up waiting on it. Multiply sessions per week by minutes per session and you get a real figure: manual hours per flow, per week.

Sort that list. The flow at the top isn't automatically the one with the most business risk, and that's fine, risk comes in at phase two. Right now you're looking for repetition, because repetition is what an early automation phase pays back fastest. A flow run three times a week for twenty minutes each returns more reclaimed hours than a flow run once a quarter for two hours, even when the quarterly flow is the scarier one to get wrong.

This tally is also where you catch the assumption most templates ship with by default, the one inherited from Martin Fowler's test pyramid: that unit tests must be where the manual burden sits, because they're the cheapest layer to automate. For a team with a mature manual suite, the tally almost always shows the opposite. Nobody has been manually re-running unit-level checks, because unit tests were never a manual activity in the first place. The manual hours are concentrated entirely in end-to-end flows a person has to click through by hand. That's your real starting point, and it has nothing to do with pyramid shape. For the broader case on catching problems earlier in the cycle rather than later, shift left testing in a DevOps pipeline covers when to test; this article is about what to automate first once you already know you're behind. If you also need the cost side of this tally spelled out per hour, manual vs automated testing costs breaks down what each hour on that list is actually worth to convert.

The order

Four phases, run in this order, each with an exit condition that tells you when to move on rather than a checklist to power through. This order assumes you've already settled which cases are worth automating at all; the decision rule for that, plus the maintenance-cost arithmetic behind it, lives in test automation strategy for AI-written code. This piece picks up from there and covers the sequence and the transition.

Phase one: the release-blocking smoke path

Phase one is the release-blocking smoke path, the flows your tally just showed carry the highest weekly repetition: login, checkout, the handful of screens somebody clicks through before every deploy. It goes first for a boring reason: it's the highest-volume manual cost you have, and every hour you automate here comes back immediately, on the very next release. You're done with phase one when a release can ship without a human re-running that path by hand, not when every edge case in it is covered. It's also the only phase that puts automation testing in DevOps terms your pipeline can act on: once the smoke path runs in CI, the release gate stops being a person.

Phase two: top revenue and data-integrity flows

Phase two is the top revenue and data-integrity flows, chosen with an actual score rather than a gut call. This is where the risk-based testing scoring model earns its keep: likelihood times blast radius tells you which flows outrank the smoke path on consequence even though they don't outrank it on repetition. Don't rebuild that scoring exercise here, use it as the input and move to automating whatever comes out on top. Phase two is done when your highest-risk tier has real automated coverage, not just a plan to get there.

Phase three: the long tail, kept opportunistic

Phase three is the long tail, and it stays opportunistic on purpose. Every remaining manual test case gets automated when an engineer is already touching that part of the codebase, not as a scheduled project with its own headcount. Trying to formalize the long tail into a project is how migrations stall: there's no natural finish line, so it competes for priority against everything with a deadline and loses. Phase three is never "done" in the way the first two phases are; it just keeps shrinking as normal feature work touches more of the app.

Phase four: unit coverage, backfilled by the owning team

Phase four is unit coverage, backfilled by whichever team owns the module being changed. This is the phase most templates put first, and it belongs last for this reader specifically because it was never where the manual hours were. Put it under the owning engineering team as a normal code-quality expectation, not under QA as a deliverable. A QA-owned unit test backlog is a sign the ordering went wrong somewhere upstream.

Here's how the four phases of a manual to automated testing migration line up against the reason each one sits where it does, and what tells you it's time to move to the next:

Phase	What gets automated	Why here	Done when
1. Smoke path	Release-blocking login, checkout, core flows	Highest manual reps per week; blocks every release	Releases ship unattended, no manual re-run
2. Top-risk flows	Highest-scored revenue and data-integrity paths	Biggest consequence if wrong, per the risk score	Top-risk tier has real coverage, not just plans
3. Long tail	Any manual case, automated when it's touched	No project can justify its own headcount	Never fully done; it keeps shrinking
4. Unit backfill	Unit tests for the module being changed	Cheapest once you're already in the code	Owned by the team, not a QA task

How Autonoma shortens the first phase

Phase one usually takes a quarter, and the reason is rarely a decision problem. Most teams already know their smoke path is the right place to start; the tally above just confirms it. What eats the quarter is authoring time: someone has to sit down and write every test case for every flow in that path, then keep them working as the app changes underneath them.

That's the specific constraint Autonoma removes. Connect your repository, and our Planner agent reads the routes, components, and user flows that make up your codebase, including the login and checkout paths that just topped your tally, and drafts the test cases against a live preview environment. It also generates the endpoints needed to put your database in the right state for each test, which is normally its own slice of the authoring cost. As your team keeps shipping through phase one, the Diffs Agent runs on every pull request, updating and deprecating test cases from the code diff instead of leaving a QA lead to notice a smoke test has silently gone stale. The scarce resource in a migration used to be the time to write phase one by hand; with the authoring done for you, it becomes the attention needed to review what got generated, which is a smaller and more sustainable ask of your team than writing a quarter's worth of tests from scratch.

To be precise about scope: this covers phase one and phase two, the behavioral end-to-end layer. It has nothing to do with phase four. Unit coverage is still your engineering team's job, written in their own test runner, and Autonoma isn't trying to take it over.

What not to automate in year one

Two categories are worth explicitly skipping, and most migration guides never mention either.

The first is any flow still changing weekly. Automating a UI that's being actively redesigned means rewriting the automation as fast as you write it, which is worse than leaving it manual for a few more sprints. Wait until the flow's shape has settled before you spend authoring effort on it, whether that effort is a person's time or an agent's.

The second, and the more important one, is anything whose expected behavior is still being argued about internally. If product and engineering disagree on what a feature is supposed to do when a user hits an edge case, automating a test for it doesn't resolve the disagreement, it just encodes one side's answer into CI and calls it a passing build. The next person to touch that code will trust the green checkmark over the actual product intent, because that's what a green checkmark is for. Settle the argument first. Automate the settled answer.

The two-system months

The part every migration plan glosses over: for months, you're running two testing systems at once, and neither one gets to be someone's spare-time project.

The manual suite doesn't disappear the day you start automating phase one. It keeps covering phases two through four while they're still manual, which means it still needs an owner, still needs someone to run it before a release, and still needs to be trusted enough that nobody quietly skips it under deadline pressure. At the same time, the automated suite for phase one is new and imperfect: it will produce false positives while it settles in, and someone has to triage those instead of assuming every red run is a real bug. Running both well, at once, is more work than running either one alone, for a while.

Say the staffing reality plainly, because it's the part a VP reading this document will actually ask about. This is exactly the moment the migration plan stops being a QA lead's side project and becomes something an engineering manager who owns quality without a dedicated QA function has to staff on purpose, the same reality covered in shift-left QA without a QA team: your testing capacity does not drop in year one. It shifts, from hands-on-keyboard clicking through screens toward reviewing automated results and triaging the manual backlog that's still shrinking. If you don't have headcount to absorb that shift internally, QA automation services covering the shrinking manual tail during the transition, or hiring a QA engineer to own the whole migration, are both more honest options than pretending the two-system period doesn't cost anything.

Whichever phase you're staffing for, the sequencing matters more than the tool you pick to execute it. If the constraint you keep hitting in phase one really is authoring time rather than a decision about what to test, that's the specific gap Autonoma is built to close, which is what lets a team reach phase two while the manual suite is still doing its job on everything else.

Frequently Asked Questions