Creating mobile web tests (responsive)

Testing your responsive web design is an important part of delivering a great user experience on devices. You can use the mabl Trainer to train tests with different viewport sizes and also specify a mobile user agent to have the browser identify itself as a given device.

When devising a mobile web testing strategy, it is best to start by analyzing data from actual usage patterns. For example, Google Analytics provides such data with their Audience reports. Once there, you can go to the Mobile -> Overview report to get a breakdown by user device such as desktop, mobile and tablet. The Devices report can also provide you with a break down of specific devices and you can even set the Primary Dimension of the report to Screen Resolution to get the most common mobile resolutions.

You can also find a report about the top browsers and operating systems that your users use under Audience -> Technology -> Browser & OS. To see the top overall screen resolutions, set the Primary Dimension for the report to Screen Resolution.

Note that if you don’t have access to your analytics data, you can request an export in CSV or PDF from your web or marketing team. If you are starting a brand new project, you can search the web for the most popular mobile screen resolution.

Let’s assume we’ve identified that 360x640 resolution and iPhone devices are most popular with our users. Next, we'll open Chrome DevTools, toggle Device Mode and setup our mabl Trainer to start training our first mobile test.

Working with Chrome DevTools and mabl Trainer

To open Chrome DevTools hit F12 or use the menu View -> Developer -> Developer Tools. Then, we can make the most out of the screen space by docking the DevTools to the right of the browser window from the three dots menu. We are now ready to enter Device Mode from the mobile icon on the left of the menu.

Make sure to check out the Chrome DevTools docs on responsive viewports for many useful tips.

You can set the responsive viewport size to our sample resolution of 360x640. It is important that the device type is set to Mobile to emulate a touch experience. You can show the device type options from the three dot on the right.

You will notice that the mabl Trainer will appear inside of the page context . You can hide that instance of the Trainer and open one inside the Chrome DevTools to better work with small resolutions in Device Mode.

Setting the viewport

When you open the the mabl Trainer for the first time it will automatically capture your current viewport size. You can simply edit that viewport step to set the desired size. It is best to specify only a width value so the content flows down as long as needed.

It is possible to add additional viewport steps from the mabl Trainer options.

You can now start training your mobile tests by interacting with the application, adding assertions, etc. One productivity hack to save time is to take existing mabl tests trained for desktop and duplicate them by editing the copied test steps as necessary. You can also use labels to tag your mobile tests for easier management.


Menu navigation and hover steps are something to watch for since the navigation will most likely be collapsed in a hamburger menu and hovers do not work with touch input devices.

Additionally, each browser limits the viewport size differently in responsive mode.

Working with mobile user agents

Once you have created some mobile tests, we can run them using mabl Plans. This is where we can also specify a mobile User Agent value to identify as a mobile device in the HTTP headers that the browser sends to the application. Mabl will then use the specified viewport and mobile user agent when executing the Plan.

A quick way to generate User Agent strings to select device in Device Mode in Chrome DevTools and type navigator.userAgent in the Console panel.

You can also review the Chrome documentation on user agent strings.

Updated 4 months ago

Creating mobile web tests (responsive)

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.