Originally reported by InfoWorld. Mabl is an automated front-end testing platform co-founded by former Google engineers.
What Is Mabl?
Mabl is an AI-assisted, automated testing platform focused on the front-end of web applications. Unlike traditional code-level test frameworks, Mabl tests are designed to validate user experience—verifying that an app behaves the way a real user expects, not just that the underlying code passes unit or integration checks.
As Mabl co-creator Dan Belcher explained: “Frameworks like Selenium test front-end code, not user experience. So all your scripts may pass, but from the user’s perspective the thing may still be broken.” For teams already invested in Selenium, Mabl supports importing existing Selenium test suites to ease migration.
New Integrations: GitHub, Bitbucket, and Atlassian Bamboo
The release described here focuses on extending Mabl’s reach into the daily developer workflow through integrations with popular code-hosting and CI/CD platforms. The core idea is shift-left testing—moving quality checks earlier in the development cycle so that issues are caught before they reach production or even staging.
GitHub Integration
- End-to-end Mabl tests run automatically as part of the pull request checks pipeline, blocking merges if tests fail.
- GitHub Actions can trigger Mabl test runs on commits, branch pushes, or PR events—no separate CI server required for this step.
- Tests can be snapshotted and version-pinned to specific workflow stages or product milestones, making it easier to reproduce exactly how tests behaved at a given point in time.
Bitbucket and Atlassian Bamboo Integration
- Atlassian Bamboo automation can also trigger Mabl tests, bringing front-end quality checks into teams using the Atlassian toolchain.
- Bitbucket repositories gain similar pipeline integration, allowing Mabl to slot into existing Bitbucket Pipelines workflows.
Developer-Centric Features
Beyond CI/CD pipeline integration, this release adds tooling aimed squarely at individual developers rather than dedicated QA teams.
Headless Local Test Runner
The headless local test runner lets developers execute front-end Mabl tests directly on their own machines during development—without needing to push code to a shared environment first. The runner operates in the background and surfaces issues without requiring the developer to monitor the test process manually.
Command-Line Interface (CLI)
A new CLI allows developers to configure and run Mabl tests alongside their regular development tasks. This makes it practical to run a targeted test suite from a terminal window without switching context to a browser-based dashboard.
Jira Ticket Automation for Regressions
When Mabl detects a regression or failure, it can automatically file a Jira ticket that includes:
- Full stack traces
- Screenshots or other test artifacts
- Enough context for a developer to reproduce the issue without manually re-running the test scenario
This reduces the back-and-forth between QA reporters and developers by embedding reproduction details directly in the issue tracker.
Pricing and Trial
Mabl’s pricing is available on request. At the time of this report, the platform offered:
- A 14-day free trial with full feature access
- Plans starting at 1,000 test runs per month, scaling upward based on volume and the auxiliary features required (such as cross-browser support beyond Chrome and Firefox)
Check mabl.com for current pricing, as plans and feature tiers will have changed since this article was originally published in April 2020.
Why This Matters for DevOps Teams
Integrating front-end UX testing directly into pull request workflows addresses a real gap in many CI/CD pipelines: automated tests often cover backend logic and API contracts thoroughly, but browser-rendered user flows are tested manually or only in dedicated QA sprints. By making these tests run on every commit—and by providing local and CLI tooling—Mabl reduces the cost of finding front-end regressions late in a release cycle.
The shift-left approach is especially valuable for teams practicing trunk-based development or deploying frequently, where catching a broken user flow after merge is significantly more expensive than catching it at the PR stage.