Migrate from mabl

Export representative mabl browser tests, reconcile unsupported steps and artifacts, migrate the reviewed code or intent to ContextQA, and verify parity.

Quick answer

Use mabl’s current CLI export as an intermediate artifact, not as proof of a lossless migration. Export representative user-authored browser tests to Playwright or Selenium IDE, record the mabl branch and environment used, reconcile mabl’s documented unsupported step types, and run the exported code independently. Then analyze the reviewed Playwright output with ContextQA’s documented repository workflow—or rebuild from a behavior packet—before comparing normal, seeded-failure, data, and evidence behavior in parallel.

Understand the supported boundary

mabl’s official CLI documentation currently describes exports for user-authored browser tests in Playwright TypeScript, Selenium IDE, JSON, and CSV formats. It also lists step types that are not exported to Playwright or Selenium and says mabl-generated tests are excluded. See Exporting tests from the mabl CLI and verify the page against your mabl version before running the migration.

This ContextQA guide does not claim a direct mabl importer. The recommended path is:

The intermediate export can lose behavior before ContextQA processes it. Keep the original mabl test, branch, plan, environment, and run evidence authoritative until the ContextQA behavior passes review.

Phase 1: Freeze the mabl source

Record:

mabl workspace/application:
mabl branch:
Environment and environment ID:
Application build/revision:
Plans and labels in scope:
Selected user-authored test IDs:
Generated tests in scope:
DataTables/data sources:
Credentials and integrations:
Baseline run IDs/artifacts:
mabl CLI version:
Migration owner:

Use immutable test and build references where available. Preserve a source run for every representative test.

Phase 2: Inventory behavior before export

mabl test ID	Business behavior	Assertions	Branch/environment	Data	Special steps	Last run	Owner

Inventory reusable flows, variables, DataTables, JavaScript, API steps, cookies, file operations, accessibility checks, email/PDF/MFA behavior, downloads, conditional logic, and plan-level configuration.

Pre-classify documented export gaps

The current mabl documentation lists these step types as unsupported in Playwright or Selenium test exports:

• select steps;
• drag and drop;
• JavaScript snippets;
• API steps;
• cookie interactions;
• file uploads;
• download assertions;
• accessibility checks;
• MFA authenticator steps;
• email testing; and
• PDF testing.

It also says Selenium exports do not support conditional steps and that mabl-generated visit-home, link-crawler, and visual-smoke tests are not exported.

Treat this list as a starting point, then compare with the current official page and your export result. Product export behavior can change.

Source feature	Tests affected	Exported?	Migration treatment	Owner
		Yes / Partial / No / Unknown	Rebuild / Retain / Replace / Retire

Phase 3: Export a representative test

Install and authenticate the mabl CLI using mabl’s official instructions and your organization’s approved credential process. Do not paste access tokens into a shell history, GitBook page, or migration artifact.

For a Playwright export, the official command pattern is:

mabl tests export <test-id> \
  --format playwright \
  --environment-id <environment-id> \
  --file <safe-output-path>

Add the documented mabl-branch option when the source test is not on the default branch. Run mabl tests export --help and the current official documentation before executing; do not infer option behavior from this example alone.

Use one output directory per source revision and do not overwrite earlier evidence.

Phase 4: Reconcile source and export

Check	Source mabl	Exported Playwright	Result
Test identity/branch			Match / Gap
Ordered actions
Positive assertions
Negative assertions
Conditional behavior
Variables and data
Reusable flows
Environment/base URL
Authentication/session
Setup/cleanup
Special step types
Browser configuration

If a required behavior is absent, do not silently patch the generated file and forget the source gap. Add a migration decision linked to the behavior packet.

Phase 5: Run the export independently

In a clean, disposable environment:

1. Review the generated code and package requirements.
2. Install dependencies through the approved package process.
3. Supply only documented, nonproduction configuration and secrets.
4. Run the exported test against the same application build used for the mabl baseline.
5. Capture its result, failure diagnostics, browser, and environment.
6. Introduce a controlled application failure and confirm the export fails for the expected reason.

If the export does not run or loses a critical assertion, choose manual reconstruction or retain the test in mabl. Do not send a broken intermediate artifact into bulk migration.

Phase 6: Prepare the ContextQA behavior packet

Behavior ID:
mabl test ID, branch, and environment:
mabl baseline run:
Export file and commit:
Export limitations affecting this test:
Preconditions and role:
Actions:
Required positive/negative/persisted assertions:
Data setup/reset:
Browser/device/network:
ContextQA destination:
Retained mabl behavior:
Reviewer:

For an accepted Playwright export, follow Playwright-to-ContextQA migration. Analyze and dry-run the repository before creating cases. For an export with material gaps, reconstruct the behavior directly through documented ContextQA authoring or requirement-import workflows.

Phase 7: Map mabl concepts to ContextQA ownership

mabl source	ContextQA destination	Required review
Browser test steps	Natural-language ContextQA test steps	Preserve intent and order
Assertions	UI/API/custom verification	Preserve exact protected outcome
Environment	ContextQA environment	Confirm same application build
DataTable/variables	Test data profile/environment variable	Scope, isolation, reset, and secret handling
Reusable flow	Reviewed reusable design or expanded behavior	Dependencies and change ownership
Plan	Purpose-based suite/test plan	Browser/device, schedule, retry, and evidence
JavaScript/API/special step	Verified ContextQA step, manual reconstruction, or retained mabl control	Feasibility and security review
Cloud artifacts	ContextQA result/evidence plus retained source artifact	Access and retention parity

Phase 8: Preserve source evidence

mabl documents test-run artifact exports that can include screenshots, console logs, DOM snapshots, HAR files, traces, and other artifact types depending on browser and run. Use the current mabl artifact export guidance for your source evidence package.

Record availability rather than assuming every artifact exists for every browser.

Artifact	mabl source run	ContextQA run	Required?	Access/retention gap
Screenshots
Console logs
DOM snapshot
HAR/network log
Trace
Resolved-variable record
CI/release reference

Protect exported variables and artifacts as potentially sensitive. Review before attaching them to a ticket or migration repository.

Phase 9: Compare in parallel

Build	Behavior	mabl result	Export result	ContextQA result	Expected	Gap classification	Owner
						Export / Test / Data / Environment / Unknown

Run normal and seeded-failure cases. Include one test affected by a documented export limitation, even if the decision is to retain it in mabl.

Phase 10: Cut over by disposition

Source test	Export result	ContextQA result	Final disposition	Authoritative system	Rollback trigger
			Migrate / Retain / Replace / Retire / Unresolved

Do not delete mabl tests or revoke credentials as part of content implementation. Perform operational cutover through a separate reviewed change after the overlap window.

mabl migration checklist

• Workspace/application, mabl branch, environment, CLI version, test IDs, and baseline runs are recorded.
• User-authored and mabl-generated tests are separated.
• Current official export formats and limitations were reviewed.
• Every unsupported/special step has an owner and treatment.
• Representative tests were exported without overwriting prior evidence.
• Source-to-export steps, assertions, data, and setup reconcile.
• Exported Playwright runs in a clean environment.
• A seeded defect fails in the export for the intended reason.
• ContextQA analysis/dry run uses only the reviewed intermediate repository.
• ContextQA behavior and evidence pass parallel acceptance.
• Sensitive variables/artifacts are protected.
• Retained mabl tests, source of truth, overlap, and rollback are explicit.

Common questions

Can ContextQA import a mabl test directly?

No direct mabl importer is documented here. Use a reviewed mabl Playwright export as an intermediate source or reconstruct the behavior through supported ContextQA inputs.

Does a successful mabl Playwright export preserve every step?

No. mabl publishes a list of unsupported step types and excludes mabl-generated tests. Reconcile the exact source test and current documentation before migration.

Should we choose the Selenium IDE export instead?

Use the path your team can execute and review reliably, but note that mabl documents additional conditional-step limitations for Selenium export. For ContextQA repository analysis, the reviewed Playwright route is generally easier to preserve as code, but it still requires acceptance testing.

Related documentation

• Migration overview
• Migration planning checklist
• Playwright migration
• MCP-assisted suite migration
• Clean-environment portability test

Want to test a mabl migration using one representative export? Book a migration review → — Bring the source test, current export, and its documented gap list so the pilot starts with an honest boundary.