Responsive design testing: tools, challenges, solutions

What’s so challenging about responsive design testing? Or should I say, what’s not challenging about it?

We all know that responsive web design testing can get tedious. A dozen of screen sizes, multiplied by the number of supported Webkits and Geckos. Oh, and how about IEs? Okay, I know I’m basically rubbing it in at this point…

Still, it’s not just the number of browsers and devices. When testing responsive designs, you get a bunch of tools and tactics to choose from. Yet none of these tools and tactics cover the whole spectrum of requirements posed by responsive design testing of a real-life web app. So what can we do about it?

To find the answer, let’s briefly analyze the options we get when testing responsive web designs.

Device/screen emulators for responsive design testing

Screen size emulators like Responsinator or Viewport Resizer make for a fast and cheap way of responsive design testing. These tools are, essentially, a step up over Chrome’s device toolbar because they target a wider range of screen sizes.

One disadvantage of this sort of tools is that they rarely offer anything except for the very basic functionality. All they can do, in a nutshell, is let you see how your UI looks on multiple of screen sizes. But real-life testing of a web app requires regression UI testing. Besides that, you need to verify verification that the UI looks correctly in every resolution.

Besides, emulators never give you a precise picture of how your UI will behave on real devices.

Besides, emulators never give you a precise picture of how your UI will behave on a real device.

Responsive design testing on real devices and browsers

If precision is a priority (and it most certainly is), testing responsive designs on real devices seems like an option. Here are the reasons why this option is viable:

• Testing input gestures like swipe or pinch-to-zoom on mobile is hardly possible without a mobile device.

• Testing on real devices lets you know if your hit sizes are wrong, or if your UI lags when responding to user input. No emulator can offer this sort of functionality.
• You need mobile network connection to test loading speed for mobile. The most straightforward way to do this is to test on a real device.

The precision offered by testing on real devices makes a difference, yet it comes at a price. Setting up a device lab for responsive design testing is far too expensive for most teams. In fact, even large web platforms like BBS use limited sets of real devices for testing.

What’s more, testing on real devices involves a great deal of manual work. Sure, responsive design testing is viable for critical releases, but isn’t something that you will do on a large scale or for every update.

Remote testing on real devices with Open Source Lab, BrowserStack, SauceLabs

Knowing that testing on real devices isn’t always an option, communities like Open Device Lab seem like a nice solution. Platforms of this kind offer you remote access to real devices, saving you time and money.

Besides, there are commercial platforms like BrowserStack or SauceLabs that expand this functionality with a readymade infrastructure for automation with Selenium or similar solutions. So if you have experienced automation engineers onboard, you can build full-scale automation suites that include responsive design testing.

One minor disadvantage of working with services of this type is low ROI of hand-coded tests. Automating end-to-end UI testing for a responsive design project often takes weeks, even if you have the budget for full-fledged team of senior QA engineers. But what if you don’t? If that’s the case, there’s a smarter solution.

Cloud-based codeless platforms

Cloud-based codeless platforms (like our very own product Screenster) offer a more efficient solution for responsive design testing.

Instead of making you hand-code your tests, these tools record user sessions as series of editable steps. What’s more, these tests cover both visual and CSS testing of a UI. By prioritizing speed and simplicity, these tools demonstrate a higher ROI for QA teams.

As far as responsive design testing goes, Screenster enables you to record responsive design tests across a range of popular screen resolutions. You can select a predefined resolution, or set up your own screen size when creating a test:

Aside from this, the platform offers a number of advantages that your testers will definitely love.

Visual baselines with smart locators

Screenster substitutes simplistic image comparison with a concept of visual baselines. When taking screenshots of every UI state, the platform captures DOM snapshots along with images. It uses these snapshots to automatically build robust locators of every UI element.

When comparing screenshots, Screenster ignores minor differences caused by anti-aliasing to eliminate false positives. When it comes to comparing actual layout differences, though, even a one-pixel shifts don’t go unnoticed.

The reason why this matters is because minor layout inconsistencies are the bane of responsive design testing. Small shifts are hard to notice during manual testing, yet they often annoy end users. With Screenster, such shifts are not a problem.

Smart automation of timeouts

Screenster automatically determines the optimal wait time for UI events eliminating the need for hand-coded waits. This move optimizes the duration of test runs because you don’t have to set up global timeouts. Given the fact that we’re talking about testing on multiple screen sizes, this might be a huge time-saver.

No hassle with dynamic regions

Hand-coding your way around a timestamp, a userpic, or a banner adds a lot of overhead to UI testing. When working with Screenster, your testers will definitely appreciate not having to do this. Screenster automatically detects dynamic content during the first test run, and it automatically suggests to ignore it during future comparisons. Yet again, a problem that used to cause all sorts of headaches isn’t a problem anymore.

Bottom line: combine and conquer

Given the wide array of tools available for responsive design testing, which one do you actually choose? And is there actually a one-size-fits-all solution? Sadly, the answer is no. When testing responsive designs, you will most probably have to combine several solutions to achieve an optimal coverage of your project.

Specifically, every project will probably require testing on real devices, and you’ll naturally need to prioritize between them. Luckily, there’s a neat guide from the development team at BBS that seems to address this.

As far as automation goes, there are a lot of factors that will influence your choice of a platform, If you’re looking for a solution that delivers in terms of simplicity and ROI, try Screenster online by hitting the button below.