Here's the idea I want to leave you with. Your manual test library isn't documentation. It's automation that has been waiting for something that can read it. And you shouldn't have to move it, rewrite it or migrate it to set it free.
The clearest version of this came up in a customer conversation a few weeks ago. The head of quality at a fast-growing fintech told me his company pays an outside firm to run its manual regression, and the firm bills per test executed. Because strangers run the tests, every test case has to be written in extraordinary detail: every click, every field, every expected result.
He had already worked out the next part himself. Test cases detailed enough for a stranger to follow are exactly the kind an AI agent can pick up. And if an agent could run them, that per-execution bill was money he could stop spending.
He's right. And his situation is a lot more common than it looks.
The short answer
How AI changes what a manual test is, at a glance:
Your manual test library is closer to an asset nobody has cashed in yet than a cost of doing business.
Every mature testing team owns a library like his. Hundreds or thousands of test cases in a test management tool, a spreadsheet or Jira. Written, reviewed and rewritten over years. It describes what the product is supposed to do better than almost any other document in the company.
And most of it has never been automated. Not because nobody wanted to, but because automation has always needed a translation step. A skilled engineer reads the test case, then rewrites it as code. That translation is slow, it needs scarce skills, and you pay for it again every time the code breaks. Call it the translation tax.
Teams pay it selectively. The critical flows get translated. The long tail stays manual forever, and people run it by hand every release. That's what I mean by trapped. The knowledge is all there, sitting one translation away from running on its own.
What's changed is that the translation can now be done by the thing doing the running. An AI agent can read the test case as written, work through it in the application, check the expected result and keep a record of what it did. The first run is the automation.
Next time the same test needs to run, it runs based on the automated test generated by the AI agent and not the natural language steps in the manual test case.
That flips how teams approach an old manual suite. The traditional way is a project: prioritize, estimate, staff it, convert a few hundred tests a quarter, and hope the app doesn't change underneath you. The new way is closer to a habit. You run the tests you would have run anyway, and each run leaves automation behind.
| Aspect | The traditional way | The new way |
|---|---|---|
| Approach | A project | Closer to a habit |
| What it takes | Prioritize, estimate, staff it, convert a few hundred tests a quarter | Run the tests you would have run anyway |
| Result | Hope the app doesn't change underneath you | Each run leaves automation behind |
Not every test will go through cleanly the first time. Some are vague, some are out of date, and some assume knowledge only a veteran tester has. That's useful too. The tests that don't run tell you exactly which ones need a human's attention, instead of leaving you to guess across the whole library.
This is the part I'd push back on hardest. A lot of modernization advice starts with a migration: move your test cases into a new tool, restructure them, retrain the team, and then start automating. For a large library, that's months of work before a single test runs on its own. Plenty of teams never get past step one.
It doesn't have to go in that order. If an agent can read a test case, it can read it where it already lives. The library stays in the tool your team knows, with its history, its links to requirements and the habits built around it. Automation starts on day one.
We keep hearing the same thing in customer conversations. The teams most excited about this aren't the ones with clean, modern test suites. They're the ones sitting on thousands of manual cases they had quietly given up on.
If you want to try this on your own library, don't start with the whole thing. Start with the tests your team runs by hand every single release, because those pay the translation tax most often. Within those, pick the ones written well enough that a new hire could run them without asking anyone. Those are the ones an agent will handle best on day one.
Then follow the money. If you're paying people, in-house or outsourced, to run the same steps every release, that's the time and budget this gives back. Decide now what your testers would do with it, because the answer is the real business case.
For years, a manual test library has been treated as a cost of doing business. I think it's closer to an asset nobody has cashed in yet. The teams that notice first are going to have a very good year.