Imagine a test that needs to confirm an order was successfully created. The new order is created, but lands on page 2 of a paginated list. The test fails, not because the order didn’t get created, but because it wasn’t on the first page of orders. Then your team has to spend time troubleshooting a failure for a problem that was never really there.
Multiply that experience across a full test suite, and you’re spending hours triaging failures that have nothing to do with what you’re actually testing.
With agentic runtime recovery, mabl handles this situation automatically. When a test step fails during execution, mabl can now activate an agent to analyze the failure and attempt to recover before the test is marked as failed. For example, if a newly created order lands on page 2, runtime recovery will automatically move to the next page and find the new order.
Early access
Runtime recovery is available in early access. To turn on runtime recovery, workspace owners should enable the following settings on the Labs page: Settings > Labs
- Use preview AI models in mabl agents - the data processing location of preview models is not guaranteed to be US-based.
- Runtime recovery - this setting is only available if your workspace has enabled preview models for mabl agents.
Use cases
Runtime recovery handles common obstacles that a manual tester would naturally work around. Examples include:
- Dismissing an unexpected modal
- Clearing a stale search filter
- Navigating to a different page in a paginated list
- Retrying a button that wasn’t responsive on the first click
By recovering from incidental failures, your test results focus on what matters: real bugs and genuine regressions in your application.
How it works
When a step fails and auto-heal can’t find a high-confidence match, runtime recovery steps in:
- Analyze the failure - the mabl agent analyzes the failure using context from previous passing and failing cloud runs, comparing screenshots and step results from passing runs to understand what changed.
- Decide on an action - based on this context, the agent determines what corrective action to take.
- Move on to next steps - if recovery is successful, the agent hands control back to the test. If recovery isn’t successful, the test fails with an enriched explanation of what failed, what the agent tried, and the outcome.
Importantly, the agent uses the test’s purpose as context when deciding whether a failure is worth recovering. If the agent recognizes the failure as core to what the test is validating, the agent won’t attempt recovery.
Coming soon
By default, runtime recovery marks the step as failed, continues execution, and fails the test at the end. In the upcoming weeks, we will add the ability to configure runtime recovery settings at the plan level.
Share your feedback
We want runtime recovery to make your life easier. If you have any feedback during the early access period, we highly encourage you to share it with your mabl customer success manager (CSM). Your insights help us build a better product!
Learn more
To learn more about how agentic runtime recovery works, check out the documentation.