Migrate from Mabl to TesterArmyYour Mabl tests,
with nothing left to heal
TesterArmy tests are plain-language steps executed by an AI agent with vision. Copy your Mabl step lists into one export file, paste one prompt into your coding agent, and the agent converts every test and verifies each one against your app.
Takes less than 2 minutes. No credit card required.
Auto-heal maintains selectors
so you never stop paying for them
Mabl tests are recorded: the Trainer captures clicks, builds element models, and auto-heal patches those models when your UI drifts. Auto-heal works, but the maintenance did not go away - it moved somewhere you can only watch.
Auto-heal is maintenance you review instead of write
You are still maintaining a selector layer - it is just hidden behind healing insights, element history, and recovery settings. Every heal is a change to an element model that you audit after the fact rather than a fix you chose to make.
Your tests change without anyone editing them
When your UI drifts, auto-heal patches the element models to keep the recording alive. That means the definition of what your test checks can shift from run to run, with no diff and no reviewer in the loop.
Recordings are locked to Mabl's platform
Because tests are recordings, they live only in Mabl's platform, priced per quote. They cannot sit in your repository, show up in git history, or be edited in a pull request the way the rest of your engineering work is.
New coverage means new recording sessions
Every additional journey is another Trainer session that builds more element models for auto-heal to patch later. Coverage adds maintenance work at the same rate it adds confidence.
What your suite reads like
after the conversion
Because Mabl tests are not code in your repository, migration starts with an inventory instead of a file scan. Each test's step list maps almost one-to-one onto TesterArmy steps, minus all element references.
# 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
The migration drops the element models behind every recorded step. The agent finds elements the way a human does, every run, so there is nothing to heal when your UI drifts.
The whole migration
is one prompt
Paste this into your coding agent in the directory that contains your export file. It reads mabl-export.md, creates a TesterArmy project, converts each test and shared flow, and verifies every one locally with real exit codes.
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> --local --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.Everything you built
has a place to land
Every Mabl concept has a TesterArmy home - plans, stages, flows, DataTables, environments - and the auto-heal machinery maps to nothing at all, because no selectors exist to break.
Mabl and TesterArmy,
row by row
Mabl is a mature enterprise platform, with the compliance features - SOC 2 Type II, SSO/SAML, RBAC - and the breadth of web, mobile, API, accessibility, and performance testing to prove it. This table is about what the recording and healing model costs day to day, and where each side wins.
- Who maintains the testsTesterArmyThe agent finds elements visually every run, so there is no element model to record, heal, or review.AdvantageMablAuto-heal patches the element models for you, and your team reviews the healing insights and element history it leaves behind.
- What breaks on a UI changeTesterArmyUsually nothing - the agent sees the redesigned form or the renamed field and completes the step, so there is no recovery to review.AdvantageMablAuto-heal usually recovers, but each heal changes an element model automatically - the review happens after the fact in healing insights rather than in a pull request.
- Writing a new testTesterArmy3-10 plain-English steps that anyone on the team can write and review.MablA Trainer recording session, plain-English authoring, or even a Jira ticket, built inside Mabl's platform.
- Flaky failuresTesterArmyThe agent waits like a human, and every failure comes with a recording and a step trace.MablAbsorbed by healing and recovery settings that you tune and then audit after the fact.
- Run verdictsTesterArmyThree verdicts - passed, failed, or blocked. Environment and setup stops land in blocked with the reason attached, so the failure count only holds real product failures.AdvantageMablTwo verdicts. When a run fails you audit after the fact whether healing, the environment, or the product caused it.
- Where tests liveTesterArmyTests are plain JSON in your repository, with git history and pull request review like the rest of your code.AdvantageMablTests are recordings that live in Mabl's platform, outside your repo and your git history.
- Enterprise complianceTesterArmyA younger vendor - bring your procurement checklist and verify each requirement before you commit.MablSOC 2 Type II, SSO/SAML, and RBAC come standard, on a platform that has been shipping since 2017.Advantage
- Testing breadthTesterArmyFocused on end-to-end UI flows - the migration guide's own advice is to keep API checks in a dedicated API testing tool.MablWeb, native mobile, and API testing plus accessibility and performance checks in one platform.Advantage
- Native mobile appsTesterArmyThe same plain-English tests run on iOS and Android via managed cloud simulators and emulators.MablSupported for native iOS and Android as a paid add-on, with cloud runs on virtual instances.
- Pricing modelTesterArmyFree trial without a credit card; Hobby is $99 per month with 250 test runs included.AdvantageMablQuote-only pricing with a 14-day free trial and cloud-run credits starting at 500 per month - there is no public self-serve SKU.
Facts checked August 2026. Spotted something out of date? Tell us and we will fix it.
From recorded journeys to green runs in four steps
Copy your step lists out of Mabl, hand the prompt to your coding agent, and review what comes back. Your Mabl plans keep running alongside until the migrated suite has proven itself.
Export your inventory and set up the project
Copy each test's step list from the Trainer or the test details page into mabl-export.md, noting plans, environments, flows, and DataTables. Install the TesterArmy CLI, authenticate, and paste the prompt - the agent creates a matching web project from your primary environment URL.
The agent converts every test
Recorded interactions become act steps, assertions including visual assertions become assert steps, and login flows become a single login step backed by encrypted credentials. Shared flows turn into project memories that every test run knows about.
Every migrated test runs locally
The agent verifies each test against your environment URL with ta tests run --local and reports pass or fail through real exit codes, plus a summary of anything it skipped - API tests, extra DataTable rows - and why.
Recreate plan triggers and retire the workspace
Scheduled plans become production monitoring and deployment-triggered plans become group webhooks or PR testing. Run both systems in parallel for a release cycle, then retire the Mabl workspace.
What comes with you,
what stays behind
Each Mabl test's step list maps almost one-to-one onto TesterArmy steps, and the guide is explicit about the few things that do not carry over.
When Mabl is still the right call
- Your API tests, accessibility checks, and performance testing all live in Mabl today and you want them under one roof - that breadth is real, and TesterArmy focuses on end-to-end UI flows.
- Procurement treats SOC 2 Type II, SSO/SAML, and RBAC as hard gates and you cannot spend a cycle verifying a younger vendor against that checklist.
- Your suite leans on DataTable-driven runs where every data permutation matters, and the representative cases the migration converts would leave gaps.
- Your test authors work entirely from the Trainer and from Jira tickets, and moving them to plain-language steps kept in a repo is a workflow change your team does not want to make.
Nothing forces the choice on day one. Migrated tests run alongside your Mabl plans, and the guide's own advice is to run both systems in parallel for a release cycle before you retire the Mabl workspace.
Frequently Asked Questions
Nothing to heal, because
no selectors exist to break
Your Mabl tests encode real knowledge about the journeys your users take. The migration keeps that knowledge as plain JSON in your repo and retires the machinery around it - the element models, the healing insights, the recovery settings - so when your UI changes, the agent sees the new screen and your tests have nothing to recover from.