Testing approach


The following is true of mobile/device testing in general, but worth going over to ensure time isn’t wasted covering off items multiple times, when once or twice is sufficient. As a general rule, if a link functions on one device it will work on all devices. The exception to this is when a link isn’t just taking you to another page or a document; examples of this would be when a link shows/hides a section, or opens a new window, tab, or a lightbox.

The elements listed below only need to be tested once per device, as they use identical code per page. Only on larger projects, with changes on multiple sections, would they need to be tested more than once – this is when the navigation code would be separate for each section.

The only elements that need testing in both landscape and portrait are those that produce a change to the page, either showing/hiding something ie an expand/collapse section as part of an FAQ page for example, or those elements producing an overlay eg menu buttons.

So to summarise:

Once per section per device
  • Primary navigation – full size page navigation
  • Breadcrumb links
Once per section per device, in landscape and portrait
  • Menu button – mobile site / responsive navigation
  • Search button - mobile site / responsive
Once per device
  • Embedded links within the page
  • Repeating pod links

As previously stated, generally if a links works on one device it will work on all devices. So this would apply to anything not already mentioned eg footer links. Also test to confirm:

  • Images and logos are rendered correctly – particularly with retina/HD display (and when resizing)
  • Links are displayed and behave as expected when selected ie highlighted and/or audio confirmation
  • Page behaves as expected to screen gestures ie pinch and stretch, scroll etc.
  • Native elements work as expected eg. dropdown lists etc.


Moving on from the basics, the following should be considered when testing the responsive build:


The layout of the page at the different sizes is probably the most important thing. Without knowing how a page will look and behave on different device sizes it’s impossible to know when a page is displayed correctly for that device.


There should be sufficient wireframes for a range of device sizes, in both portrait and landscape. Below are three examples from a project. Fig. 1 is a small template, the equivalent to a mobile in portrait. Fig. 2 is a medium template, the equivalent to a tablet in portrait. Fig. 3 is a medium/large template, the equivalent to a tablet in landscape. The medium/large template is the last template before desktop.

Fig. 1 – Wireframes template for small devices.

Fig. 2 – Wireframes template for medium devices.

Fig. 3 – Wireframes template for medium/large devices.


Find out how many break points there are, what they are set to, and if the design is based on the base font size (using ems) or just standard pixels. Basing the design on the base font size means everything should always scale with the font size and everything should remain in proportion, regardless of the screen resolution.

The breakpoints for Aviva.co.uk Travel were:

  • Small to medium 560px (35x16px – 35 being the ems and 16px the base font size)
  • Medium to large 880px (55em x 16px)

The breakpoints can be tested effectively in a browser using the tool on responsivepx.com. With this online tool it’s very easy to test the boundaries of the breakpoints and see how the layout changes around it.

Layouts based on ems should also be tested by increasing the browser base font size (best achieved in Firefox). Fig. 4 is an example of where increasing the base font size broke the hero image design. Here the base font size was increased to 32px, which is somewhat extreme, but gradually increasing the base font size up from 16px should identify any issues as the layout moves between the different breakpoints/layouts (the page needs to be refreshed after each font size change).

Fig. 4 – Example of testing with an increased font size.


The following site covers off five of the current common layout patterns – lukew.com/ff/entry.asp?1514

Understanding something about the way the layout behaves helps identify when a particular devices is behaving unexpectedly. With the idea of a responsive design being dynamic the layout should cope with screen sizes in–between the breakpoints. For example, on the Galaxy S3, a device with a taller screen, the landscape layout of a page is a variation on the mobile landscape and tablet portrait templates.

When testing the layout of the page on a device it’s important to also test the transition between portrait and landscape and vice–versa (there is an issue with older version of iOS that cause the page to be displayed zoomed out – the page should appear at the right zoom level to fit the screen).

Here are side by side comparisons of the different breakpoints for the travel section on Aviva.co.uk and Healthcarezone.

Fig. 5 – Aviva.co.uk large size

Fig. 6 – Healthcarezone large size

Fig. 7 – Aviva.co.uk medium size

Fig. 8 – Healthcarezone medium size

Fig. 9 – Aviva.co.uk small size

Fig. 10 – Healthcarezone small size

Navigation and tables


There are a number of options for navigation once the space available is too small for a primary navigation. The navigation in section further reading covers off some of the common ones.

Fig. 11 shows how navigation is handled for Travel – button open and closed and Fig. 12 shows how it was handled for Healthcarezone.

Fig. 11 – Aviva.co.uk navigation system both open and closed

Fig. 12 – Healthcarezone navigation system

The immediately noticeable difference is that the navigation for travel includes links for both the primary navigation tabs and the left hand navigation links. Healthcarezone only includes links to the primary navigation. The left hand navigation links for Healthcarezone were displayed at the bottom of the page, as shown in Fig. 13.

As previously stated, when testing menu buttons ensure they are tested on all devices and in both portrait and landscape; as they are making a change to the page by producing an overlay.

Make sure the menu is tested while open and when moving between orientations. It’s also good to use responsivepx.com to step through the breakpoints and confirm the layout of the menu stays consistent ie buttons stay aligned and text doesn’t overlap the icons/images.

Fig. 13 – Healthcarezone section navigation system


Some of the common options for handling tables are detailed within further reading. Testing should be tailored based on the solution. The principles already defined should be adhered to. This is a fantastic example of the sort of thing that’s being built – premiumdraught.com/#menu


With all the devices – new and old, and all the different screen sizes and resolutions currently available, it would be impossible to test on them all. So as with cross browser testing, focus on the devices being used to view the pages being developed (site MI if pages are new).

With a limited number of devices likely available, focus on the screen size and resolution – for example the iPhone4, 4s and 4th Gen iPod touch are the same screen size and resolution. As is the iPhone5 and the 5th gen iPod touch and all 3 iPads have the same screen size but the iPad 3 has retina display – double the standard resolution of the other 2. Also consider taking advantage of the devices available at the Apple store for newer devices that may not be available to the department.

Note: cross browser testing is still also a requirement.