Migrate from Mabl

Mabl tests are recorded: the Trainer captures clicks, builds element models, and auto-heal patches those models when your UI drifts. It works, but you’re still maintaining a selector layer - it’s just hidden behind healing insights, element history, and recovery settings. And because tests are recordings, they live only in Mabl’s platform, priced per quote.

TesterArmy skips the element model entirely. Tests are plain-language steps executed by an AI agent with vision, so there’s nothing to heal - the agent finds elements the way a human does, every run. Tests are plain JSON you can create from the CLI, keep in your repo, and edit in a PR.

How concepts map

What translates and what doesn’t

Because Mabl tests aren’t code in your repository, migration starts with an inventory instead of a file scan. Each Mabl test’s step list (visible in the Trainer or test details page) maps almost one-to-one onto TesterArmy steps - recorded interactions become act steps and assertions become assert steps, minus all element references.

A few things don’t carry over:

• Auto-heal history and element models - intentionally. There is no selector layer to maintain.
• API tests - TesterArmy focuses on end-to-end UI flows; keep API checks in a dedicated API testing tool.
• DataTable-driven runs over many rows - convert representative cases rather than every data permutation.

Prerequisites

$
npm install -g testerarmy
$
ta auth

Get an API key from the dashboard. For non-interactive agent sessions, set TESTERARMY_API_KEY instead.

1. Export your Mabl inventory

For each test you want to migrate, copy its step list from Mabl (open the test and view its steps in the Trainer or the test details page) into a local markdown file, for example mabl-export.md:

1
# Plan: Checkout regression (staging, https://staging.shop.example.com)
2
3
## Test: Guest checkout
4
5
- Visit home page
6
- Search for "running shoes"
7
- Open the first product
8
- Add to cart
9
- Check out as guest with a valid US address
10
- Assert: order confirmation page shows an order number
11
12
## Flow used by multiple tests: Login
13
14
- Visit /login
15
- Sign in as standard user

Include flows once each, note which plan/environment a test belonged to, and note where DataTables supplied values.

2. The migration prompt

Paste this into your coding agent in the directory containing your export file:

Migrate my Mabl tests to TesterArmy using the TesterArmy CLI (`ta`). The
Mabl inventory is in mabl-export.md. Verify auth first with
`ta status --json`, and use `ta --help` plus subcommand help to discover
commands. Prefer --json output.
1. Read mabl-export.md. Each "Test" becomes one TesterArmy test. Plans
   indicate grouping and target environment URLs.
2. Create a TesterArmy project (skip if one exists in `ta projects list`):
   echo '{"name":"<app name>","url":"<primary environment URL>","projectType":"web"}' | ta projects create --json
3. Convert each shared Mabl flow into a project memory so every test run
   knows about it (category site_structure, importance high), e.g. "Login
   is at /login; standard users land on /dashboard after signing in."
   echo '{"category":"site_structure","title":"...","content":"...","importance":"high"}' | ta memories create --project <projectId> --json
4. Convert each Mabl test into a TesterArmy test:
   - Recorded interactions -> steps with type "act"
   - Mabl assertions (including visual assertions) -> steps with type "assert"
   - Login flows -> one step with type "login"
   - Where DataTables supplied values, write one test with representative
     data described in plain English; flag remaining permutations for me
     to review instead of generating dozens of near-duplicates.
   - Keep tests focused: 3-10 steps.
   Create each test:
   echo '{"title":"<test name>","description":"Migrated from Mabl plan <plan>","steps":[{"title":"Visit the home page","type":"act"},{"title":"Order confirmation shows an order number","type":"assert"}]}' | ta tests create --project <projectId> --json
   Step types: act, assert, login, screenshot.
5. Never hardcode passwords in test steps. List the Mabl credentials each
   test relied on and I will add them with:
   echo '{"kind":"login","label":"...","username":"...","password":"..."}' | ta projects credentials-create <projectId> --json
6. Verify: run each migrated test locally with
   `ta tests run <testId> --url <environment URL> --json` and report
   results. Exit code 0 = pass, 1 = fail.
7. Report a summary table: Mabl test -> TesterArmy test ID -> run result,
   plus anything you skipped (API tests, extra DataTable rows) and why.

After the migration

1. Review the migrated tests in the dashboard and group them the way your Mabl plans were organized.
2. Add credentials for each login your flows used.
3. Recreate plan triggers: scheduled plans become production monitoring; deployment-triggered plans become group webhooks or PR testing.
4. Run both systems in parallel for a release cycle, then retire the Mabl workspace.

Next steps