Troubleshooting browser tests

When a browser test fails, your starting point is conversational results analysis. The mabl agent has direct access to screenshots, logs, DOM snapshots, runtime recovery data, and runs of the same test going back days. If you need to dig deeper, you can manually review the logs on the test output page.

This article covers:

1. Investigating with results analysis
2. Digging deeper into specific artifacts
3. Investigating timing and performance

Investigate with results analysis

Open the failed test run and look at the Results summary tab. The agent posts a high-level analysis of the failure as soon as the tab loads. Use that summary to orient yourself, then ask follow-up questions in the chat to narrow in on the cause.

The example prompts below cover the most common investigation paths:

Compare across runs

• “Compare the screenshot of the failed step to the last passing run. What’s different?”
• “Did the target element’s attributes change between this run and the last passing run?”
• “Does the failed step show a network error, an unexpected popup, or elements that didn’t load?”
• “Do passing and failing runs of this test consistently differ in environment, browser, or time of day?”
• “Is this failure new in the last five runs of this test, or recurring?”

Look upstream

The step that mabl fails on may not be the step that caused the issue. Earlier steps can drift from the expected behavior in ways that surface as a downstream failure: a “Find first” step matching a newly added element, an auto-heal identifying the wrong target, a “Passed with warning” step that didn’t actually complete its action.

• “Did any earlier step pass with a warning or auto-heal? Did it complete the intended action?”
• “Walk through the steps leading up to the failure and tell me where this run started to diverge from the last passing run.”

Investigate find failures

• “On the failing step, did the target element’s ID, CSS class, or DOM position change?”
• “Does the DOM snapshot for the failing step contain the target element? If not, what’s there instead?”
• “Did mabl interact with the wrong element earlier in the test?”
• “Why did auto-heal pick this element?” or “What other elements on the page matched the target?”

Look at the plan run

A test can fail because of conditions set up elsewhere in the plan run, such as a preview test that didn’t seed data correctly or a misconfigured DataTable. Switch to the results analysis page for the failed plan run to investigate:

• “Did a preview test in this plan fail or leave data in an unexpected state?”
• “Are other tests in this plan failing on the same step? Do they share a failure reason?”

As you investigate, the agent compiles supporting evidence into a complete analysis. When you need to share findings with your team, export the full analysis as a PDF report from the chat window.

Dig deeper into specific artifacts

When the agent can’t answer a specific question, or when results analysis isn’t available for the run, you can review test artifacts directly from the Step details tab.

Inspect logs and DOM snapshots manually

Click on the LOGS tab to view mabl Activity, network, DOM, and console logs for individual steps. For more on each log type, see browser test output.

For find-step failures, the DOM snapshot and mabl Activity logs are the most useful:

• mabl Activity logs document the target element’s attributes and how mabl searched for the element.
• Element history: for natively recorded steps, click Element history to view the tracked properties of the target element across runs. If the element details or history target the wrong element, retrain the step.
• DOM: confirm the target element existed in the DOM at the time of the step.

Replay in the mabl Trainer

Some failures need a live look at execution, such as when mabl encounters a browser pop-up like basic auth, or when you suspect the issue depends on browser state that isn’t captured in logs. In those cases, replay the test in the mabl Trainer:

1. On the test output page, click Edit test.
2. Select Launch Trainer and replay to failed step.

Open Chrome DevTools alongside the Trainer to inspect console errors and network activity during replay.

While in the Trainer, the More actions menu on a step gives you two helpful options:

• Show step info displays element details such as tag, innerText, and XPath.
• Play through here replays a specific step. If the test starts to deviate earlier, find the step where the deviation occurred and troubleshoot that one instead.

If the element is obscured by another element, try adjusting the viewport width. If the step doesn’t already use Configure Find, add it. If it does, confirm that the Configure Find attributes match the target element.

Investigate timing and performance

Latency varies across applications and test environments. If a particular test or step fails intermittently, latency spikes may be the cause:

• Check the speed index for increases in app load time.
• Download the step trace to review a timeline of the step as mabl recorded it.
• Add a wait until step before the failing step.

If a test takes longer than expected to run, see the guide on optimizing test performance.

For tests that fail when run in parallel, your test environment may not have capacity for concurrent mabl runs. You can trigger tests ad hoc or change the plan to run tests sequentially.

Reach out to the mabl team

If you’ve tried the above and still can’t determine the cause of the failure, feel free to reach out in-app or by email to the mabl support team. We’re always happy to help.