Troubleshooting test issues

If your test fails to get past the first step

Confirm whether your test environment is accessible from the public internet.
Many connectivity issues arise from the fact that the test environment is protected by a firewall that blocks inbound traffic from the internet. mabl traffic originates from machines in the cloud. To test firewalled environments using mabl, you can allowlist mabl's IP addresses for inbound connections or use mabl Link to create secure tunnels through the firewall.

If you set up mabl Link and receive an error trying to connect, please confirm that the Link agent is running on a machine with Java 9 or later installed.

Note: Many mabl users are surprised by this because their local machines (the devices that they use to "train" mabl) are able to connect to the test environments via a local network or VPN.

Confirm whether your site rejects "bot" traffic.
mabl identifies itself as a "bot" when it connects to your web site. Many web sites and applications block bot traffic by default. If your environment is accessible from the internet but mabl fails to connect, you may need to allowlist mabl traffic from your bot blockers.

If your test fails to locate an element that appears to be present

Verify that the right element is included in the step
It is not uncommon for web applications to use UI controls in unexpected ways. For example, rather than using native controls such as buttons or checkboxes, some apps use images that look like these controls and use Javascript, hidden controls, and hyperlinks to simulate the behavior that the native controls would create. If your step appears to be failing for an unknown reason, verify that you didn't inadvertently include the wrong element in the step via a CSS or XPath query. For example, is the step trying to insert the value of a variable into a frame around an input box rather than the input itself? Are you clicking on an object next to a button rather than the button itself?

If a given element is problematic in your test, start by inspecting that element's HTML properties in Chrome DevTools. You can access Chrome DevTools from the "View" menu or by right-clicking on a given element and choosing "inspect". Once you have Chrome DevTools open, you can use the inspector to confirm.

You can also review best practices for debugging failed tests for some additional tips.

If your test fails intermittently

Look for timing issues
Latency is highly variable for many applications and in test environments. If a particular test or step fails intermittently, consider whether there are intermittent spikes in latency in the test environment. If so, consider adding wait steps before the failing steps to account for the spikes in latency.

You can also download detailed performance data for any test step to get a better understanding of what's going on.

Confirm that your test environment has the capacity for mabl load
mabl executes all tests within a plan in parallel by default. Many test environments are deployed on an infrastructure that is not designed to handle many concurrent users. If you have unexpected failures, try running tests one at a time or sequentially. If tests pass when run serially but not when run concurrently, either configure the plan to execute tests sequentially or break the plan into separate plans that include a smaller number of tests.

If your test is taking longer than expected to run

Remove unnecessary hovers
When you record hovers, mabl collects a large amount of hidden data and steps that may slow down the execution of your plans. Hovers are hidden in the regular test output to remove clutter. They are shown and can be deleted when training or editing a test via the mabl trainers. You can speed up your test run by removing any unnecessary hover actions (see deleting hovers).

Replace slow steps
If some steps take considerably longer than others, consider replacing the slow ones more efficient actions. Some steps take a long time because mabl has very little information upon which to locate elements. In those cases, mabl tries to locate the element for 30 seconds using default methods before searching the page using more sophisticated heuristics (you can see details on these in the output logs). These add minutes to the run time for your tests.

If you notice mabl consistently "searching" for a given element, consider adding a unique ID or CSS classname to the element if possible. If that is not possible, try replacing the step with an explicit search for the item (using a CSS or XPath query).

If your test cannot connect to a private testing environment

Confirm Link Agent Connectivity
When running a plan or test that is associated with a Link Agent, ensure that it has been activated. Under Settings —> Networking, you should see an entry named with the agent you just started. The Link Agent should become Connected and show state Ready within a couple of minutes after starting it. You can also review the Link Agent FAQs for additional information that can help with troubleshooting.

If your test fails on a hover step

Try replacing recorded hovers with CSS hovers
Given that it is challenging to record hovers precisely, we recommend using CSS selectors to find the elements that you want to include in hover steps. You can access this via the "Find Elements" option within the mabl trainer.

Used effectively, CSS selectors can reduce the likelihood that your test will fail due to mabl hovering on the wrong element.

For more troubleshooting test issue help, check out the second installment of mabl's Webinar Training Series below, which focuses on how to optimize your team's approach to reviewing mabl test results and isolating issues for faster turnaround.