> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.tester.army/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.tester.army/_mcp/server.

# Migrate from Mabl

> Move your Mabl tests, flows, and plans to TesterArmy with a single agent prompt. Replace recorded element models and auto-heal with vision-based AI tests.

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](/cli), keep in your repo, and edit in a PR.

## How concepts map

| Mabl                            | TesterArmy                                                                       |
| ------------------------------- | -------------------------------------------------------------------------------- |
| Browser test (recorded journey) | A test with natural-language steps                                               |
| Trainer-recorded steps          | `act` steps written in plain English                                             |
| Assertions / visual assertions  | `assert` steps ("The invoice total is visible")                                  |
| Login flows / credentials       | `login` step + [project credentials](/auth/credentials)                          |
| Flows (reusable step sequences) | Repeated steps across tests, or project memories for shared context              |
| Flow parameters / DataTables    | Representative data written into step text                                       |
| Plans and stages                | Test groups (with [group webhooks](/run/group-webhooks) for triggers)            |
| Environments                    | Target URLs - per project, or per run via `--url` / webhook `targetUrl`          |
| Auto-heal and element models    | Not needed - no selectors exist to break                                         |
| Scheduled plan runs             | [Production monitoring](/run/production-monitoring)                              |
| Deployment-triggered plans      | [Group webhooks](/run/group-webhooks) or [PR testing](/run/pull-request-testing) |
| JavaScript snippets             | Describe the intent as a step; the agent handles the interaction                 |

## 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

```bash
npm install -g testerarmy
ta auth
```

Get an API key from the [dashboard](https://tester.army/dashboard/profile/api-keys). 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`:

```md
# Plan: Checkout regression (staging, https://staging.shop.example.com)

## Test: Guest checkout

- Visit home page
- Search for "running shoes"
- Open the first product
- Add to cart
- Check out as guest with a valid US address
- Assert: order confirmation page shows an order number

## Flow used by multiple tests: Login

- Visit /login
- 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:

```txt
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](https://tester.army/dashboard) and group them the way your Mabl plans were organized.
2. Add [credentials](/auth/credentials) for each login your flows used.
3. Recreate plan triggers: scheduled plans become [production monitoring](/run/production-monitoring); deployment-triggered plans become [group webhooks](/run/group-webhooks) or [PR testing](/run/pull-request-testing).
4. Run both systems in parallel for a release cycle, then retire the Mabl workspace.

## Next steps

Install, authenticate, and run your first test.

Replace scheduled Mabl plans.

Replace deployment-triggered plans.

Store the logins your Mabl flows used.