Mobile testing

Thank you for your question. Mobile testing has come up in our discussions, but we haven’t prioritized it yet. Implementing a second set of screenshots could significantly increase the complexity of the interface, configuration, and alert management. We’re evaluating whether the potential benefits outweigh these challenges. At this point, it’s not on our immediate roadmap.

We’d love to hear more about your specific needs and use cases for mobile testing. Your input could be really valuable in guiding our future plans.

Thanks, @steffenbew.

In general, mobile design is different than desktop design, and many times has different CSS.

As mobile traffic is sometimes larger than desktop traffic, making sure there isn’t a visual regression on mobile is as important as desktop, if not more.

It isn’t safe to assume that if things havn’t change on desktop they havn’t change on mobile as well.

More specifically, a mobile menu is an element visible only on mobile. It is an essential element and a relatively complex one, sometimes involving JavaScript. For this reason, it will be beneficial to track it for visual regressions, and it isn’t possible without mobile testing.

Please let me know if I can help further.

Thanks again.

Thank you for your input!

In your opinion, how significant is the choice of browser when it comes to testing on desktop and mobile? We’re currently using Chrome for testing.

Thanks, @steffenbew.

As Chrome is by far the most popular browser, both on desktop and mobile, it seems the best choice. Edge is also built on Chromium.

Did you have other considerations?

Just gathering opinions. While Chrome is the most popular mobile browser overall, there are regions where mobile Safari is more popular, such as North America. Additionally, a website’s user group might show a specific browser preference. However, in the past, we’ve also settled on Chrome, considering it a solid baseline.

Interesting.

Yes, the more specific your target is the better assumptions you can make.

Another thought I had is that as what you measure is a relative change (rather than an absolute value) the choice of a browser is less important. Your tool isn’t a browser compatibility testing tool.

I assume (but might be wrong) that most visual regressions are caused by the code (the website) rather than the browser.

Having that in mind, you might want to consider it from a developer point of view, rather than a visitor point of view. Meaning, it might be more important to reflect the site as the developer is likely to see it, rather than the visitor.

Another thought is that whatever you end up choosing, it might be a good idea to be transparent about it and the display the details of the test (for example the User-Agent value).

That all makes sense to me and closely aligns with our views.

Additionally, the idea to show the User-Agent is a nice one! Will consider it.

Happy to help, @steffenbew.

Looking forward to new features.

+1 for mobile testing. Even if it replaces desktop it seems more sensible.
I think having an interface toggle either via a tab or dropdown selector would help simplify the UI and make the implementation leaner, even though it won’t be perfect (yet).

Thanks for your feedback! Do you mean a tab or dropdown to toggle between the desktop and mobile comparison for a tested page?