RWD, which stands for Responsive Web Design, is one of the techniques for designing web apps. The term was first used in Ethan Marcotte’s article for alistapart.com website, in which he explained how to create applications so that their size, layout and graphics automatically adjust to the browser’s window and the screen, resulting in apps gaining in functionality and clarity, both on desktop and mobile devices. The goal can be achieved by using correct style sheets or their fragments.
Features of an RWD app
In order to have a better understanding of the way application testers can effectively use RWD, let’s briefly discuss the pros and cons of this design method.
Responsive Web Design carries a number of benefits. Below is a review of the most important of them.
The app optimises display on its own in order for the content to be coherent and fit the new format.
The app is available for every device. It is also economical, as it doesn’t demand investing in more than one version. What’s more, there are situations where the mobile version is based on a different engine than the desktop version. As a result, the cost of managing both sites is greater than the cost of maintaining one website developed with the RWD technology.
RWD apps can be positioned easily. RWD compliant pages are prioritised in Google search results, which gives them an advantage over non-responsive websites. There is a small catch here though – this applies only to searches on smartphones or tablets. While introducing such differentiation, Google also provided Mobile Optimization Test. This tool allows testers and programmers to check in a quick and simple manner whether a given website is suited for mobile devices. The results of such an analysis contain screenshots showing how Google views the website on a mobile device and a list of any problems found with respect to website operation on mobile devices.
Despite the pros above, the RWD technology has certain cons as well.
We have to take into consideration the fact that maintaining several apps can be expensive – you might want to keep that in mind during the website design, coding and implementation stage. Also, we need to remember that each version of the app requires running a separate test, as well as checking how it works on different browser versions and devices which you can’t emulate on simulators (they might significantly improve testing, but don’tt always yield the most reliable results.) This means that the application tester needs to have a separate device to test each version of the website.
A given device, whether it is a smartphone or a tablet, needs to download the app’s entire code in order to view it in the interpreter (browser),which is time-consuming, especially for users who don’t have a fast Internet connection.
Graphics / Layout
While designing an app in the RWD technology, we need to consider the limitations connected with the number and size of the graphics which we can place on a responsive website. This includes the content presented and interface elements.
When it comes to RWD apps, statistics analysis of click maps is quite complex. This is because it needs to include different versions of the website, designed for different mobile devices and different screen ratios.
Testing an RWD app
Testing an RWD app should be performed as a cross-browsing process, that is based on compatibility tests of the web application and scripts, performed on the user’s side in different browsers, resolutions and ratios.
From the point of view of an application tester, the time he or she spends testing is an important issue. The main challenge here is the necessity to expand the scope of the entire project team’s duties; for example, the website design process is based on breakpoints, which are points of transition between sizes. On top of this, there are also limitations resulting from the lack of access to devices whose requirements the apps under development are intended to meet.
Nevertheless, there are several solutions which support RWD application testing and thus make the tester’s work easier, including especially:
- browser extensions enabling changes in resolution/ratio,
- services providing the OS/browser combination via cloud,
- frameworks or tools for automatic visual testing.
Installing multiple browsers
In its simplest form of cross-browsing, testing a website on multiple browsers is not a major problem, as it’s enough to install them. Browsers including Firefox, Opera, Chrome, Safari (Mac) and Internet Explorer are industry standard. Most of them allow for the window to be adjusted to the most popular RWD resolutions (e.g. Google Chrome has an extensive system of developer tools which also allow emulating a given mobile device).
There are also tools which enable synchronous testing, e.g. GhostLab or DeviceLab. These programs allow application testers to connect devices in one network and run simultaneous tests in real time on all connected devices.
Web services for cross-browsing
Using web services such as Browserstack or Crossbrowsertesting is a good solution. Their task is to emulate different browsers, operating systems and mobile devices on dedicated remote servers.
Galen Framework (Open Source) is a support tool for testing responsive apps, designed to test UX (user interface.) It contains a number or rules which can be used to describe and verify the app’s graphic layout, and features a framework allowing the user to both determine the size of the browser as well as launch application tests in order to verify layout specification. Additionally, Galen makes it possible to generate detailed reports in HTML with screenshots and to visually compare the image (heatmap).
Thanks to Galen, application testers can:
- open a browser in any size and perform visual verification of objects,
- perform verification based on the placement of objects in relation to each other,
- write the specification in a simple language that is easy to understand,
- create a case test suite in the native language or integrate WebDriver’s tests with Galen specification files.
Selected examples from the rule set:
Element near another element
near button 10px left
near button 5 to 15px left
near button 5px top
near button 5px bottom left
near button 5px top, 10px left
Below / above
Element below / above another element
above description 10 to 20 px
below caption 10 to 20 px
Left of / right of
Element to the left of / right of another element
left-of button 10px
right-of textfield 10 px
Element inside another element
inside container 10 px top left
inside container 10px left right, 20px top bottom
Element partially inside another element
inside partly container 10px top left
width / height
Width and height of the element
width 100 px height 25px
width < 101 px
aligned horizontally top menu_item-2
Centering of the element
centered horizontally inside box
Centering of the element
on top left edge user-picture 20 px left, 10px bottom
The above examples show just what a natural language a tester can use while creating an app’s visual specification files.
The use of Galen described in this article is only a small part of its functionality. Describing it in its entirety exceeds the scope of this text, but I hope that I have sparked the interest of testers (automatic and manual) in this tool enough to encourage them to familiarise themselves with its documentation – this is only one small step away from implementing Galen in your projects.