Mabl's coverage feature allows you to browse your app's page coverage to more easily identify gaps and quickly find which test run on each page. On this page, you'll find a list of all the pages that mabl has explored in your app via the default link crawler in the last two weeks, filtered automatically by application. You can specify if you only want to view data as new as one day or as old as the last four weeks.

Understanding coverage

For each page in coverage table, you'll be able to view the most recent screenshot from the link crawler as well as the specific URL host and URL path in the first three columns, respectively. You're also able to filter by the specific host and path, in addition to selecting the age range of data you'd like to view. You'll need to run your link crawler regularly to take advantage of this feature. If the link crawler is not run regularly, the calculations may not accurately reflect the coverage of your application.

📘

Frequency of coverage page updates

All measures are updated at least once a day

🚧

Page coverage

The metrics in the previous screenshot only present the executed page coverage from the past two weeks (by default). Unique steps or tests that are recorded on a specific page but are never executed, due to an upstream test failure or conditional logic, are not included in these totals.

Understanding coverage metrics

In addition to the above, mabl provides multiple measures to understand your level of existing coverage for a page:

Tests

The metric captures the number of unique tests that have visited that particular page in the timeframe defined above, regardless of whether or not they interact with elements on the page. If the number is 0, this means that no tests visit this page other than the link crawler. Click anywhere in the row to view the specific test that run on this page, or easily add your own if none exist.

Note: if a test is part of two plans and runs against that page twice, only the first unique run will be reflected here.

Steps

This metric captures the number of distinct interaction steps from tests that visit this and are executed on the page in the selected time frame. Steps are distinguished by the element they interact with and what action they perform.

Note: because assertions, wait steps, echo steps, etc. do not interact with the elements on the page, they are not included in this total.

Assertions

This metric captures the number of distinct assertion steps from tests that visit this and are executed on this page in the selected time frame.

Complexity

This metric measures the overall complexity of the DOM itself as measured by mabl when crawling the page or during a regular test run. The higher the number, the more interactive elements the page contains such as buttons, links, and fields.

Linked Pages

The metric captures the number of pages that link directly to this path as detected by the mabl link crawler. The deeper a specific page is within your app, the lower this value will likely be. If you have not run your link crawler recently, this section may appear empty.

Depth

This metric captures the number of clicks necessary to access the specific path (starting at 0) as recorded by the link crawler. For example, your app homepage will have a depth of 0 while your login page will likely have a depth of 1. If you have not run your link crawler recently, this section may appear empty.

Daily Users

This metric captures the averaged daily number of unique users that visit the specific page using data captured from Segment data in your own application.

📘

Segment Integration

Please visit this link to set up the integration. Feel free to contact us in-app or by email with any questions you may have.

By integrating with Segment, mabl uses your real user data, via the Page and Track methods, to securely build a model of the pages in your app and determine the number of unique users interacting with each page. mabl does not process personally identifiable information (PII) as part of our Segment integration.

Identifying common pages in Coverage

Page coverage is reported in terms of common pages of your application. We use a technique called "URL-clustering" to group dynamic URLs of pages, giving you more accurate and readable coverage data on how mabl is testing your apps.

What is URL clustering?

Many web applications have dynamic URLs that include random IDs and other large groups of distinct URLs that describe very similar pages. This means that one web application could have thousands of distinct URLs, yet there might only be very small differences in content displayed for each URL. mabl analyzes the distinct URLs within a given workspace and combines URLs that appear to be variations of the same type of page.

How does URL clustering work?

Take a look at the following example mabl URLs. Every mabl user will have seen a URL of this form since one exists for every workspace.

app.mabl.com/workspaces/83hd632h9a-w/insights
app.mabl.com/workspaces/uvg9eh2n56-w/insights
dev.mabl.com/workspaces/qn243lf97h-w/insights
qa.mabl.com/workspaces/bv82bfnv75-w/insights
preview-env-445.mabl.com/workspaces/cd64lhaj32-w/insights

The URLs in this group all display different insights, but they share the same page template. mabl will cluster URLs like the ones above into one group to represent one page of an application. A cluster will be in the following form, even across different domains with the same path:

/workspaces/*/insights

The distinct URL variations that are grouped together will be represented with a wildcard [ * ] in the locations where the variations occurred. Here is another more generic example:

/store/women/pants/pants-variation-1
/store/women/pants/pants-variation-2
...
/store/women/pants/pants-variation-2048

The above URLs would be combined into the following cluster:

/store/women/pants/*

URLs that are very unique will be contained in their own clusters. For example, with the mabl application, the login page will be its own cluster since there is only one and the page is the same for all users.

/login

How does URL clustering affect my Coverage metrics?

Coverage metrics and charts have a clearer display of how well your test suite tests your application, especially for customers with the segment integration and many dynamic urls. mabl gets the total pages count and the covered pages count from the number of common pages instead of the distinct URLs. This will be reflected in the charts on the Coverage page, in the table on the Coverage page, and the Page Coverage item on the Dashboard.

With fewer total pages, you can now more easily scroll through the table on the Coverage page to identify pages within your application that need more journeys.

📘

How often are the URL clusters calculated?

The URL clusters are updated at the same frequency as the Coverage page metrics

Common use cases

How can I find which high traffic pages are lacking page coverage?

By default, the results on the coverage page will be sorted by complexity in descending order. Once you've integrated with Segment, click the "Daily Users" twice to sort your coverage by the average number of daily users in descending order. Once the data has loaded, view the "Tests," "Steps," and "Assertions" column to easily identify pages lacking comprehensive coverage, as shown in the box below.

How can I determine which pages have the most existing coverage in a specific environment?

By default, mabl won't aggregate coverage data across environments (e.g app.myapp.com & dev.myapp.com). Type the URL host of the specific environment you'd like to view and wait for the table to populate with your data. Then, click on "Tests," "Steps," or "Assertions" to view the tests which have the most of each respective coverage type. This is also a great way to identify which pages may be visited by many tests but are lacking in steps that interact with or assertions that verify the page itself.

How can I find my existing page coverage on pages that are linked to heavily in my app?

To do so, you'll need to sort your coverage by "Linked To" in descending order. You'll view all of your pages ordered by the number of times the page was linked to by other parts of your app discovered by the link crawler. This helps you identify which pages are most frequently linked to and where they may lack coverage, as well as the number of users that are visiting the page on average.

Customize your experience

Exclusions

The pages used to determine your page coverage are found through test executions, link crawlers, and segment integrations. While these sources provide a general snapshot of your applications, these pages might not all be relevant to your team. You can exclude pages from your coverage report by defining url paths that you do not want to see.

The list of paths to exclude from your coverage report can be edited by clicking on the "exclusions" button in the top right corner of the Coverage page. Paths to ignore can be entered in the modal, and the changes can take up to 12 hours to appear.

Exclusion examples