In today’s age, the use of mobile devices to access the internet has grown and become quite popular. Almost every internet user desires a mobile version of the website.
However, most websites are not as optimized as they should be for mobile devices. The testers should perform a mobile responsive test on the responsive designs.
Traditional software products render essentially the same on any device.
Microsoft Office, for example, looks the same on every personal computer. Imagine taking Microsoft Word exactly as it runs on your desktop, and viewing it on an iPhone4. Either the menus and buttons will appear tiny, or else you’ll only see a corner of the screen, and need to use extensive scrollbars. Either way, the application becomes essentially unusable.
This frustrating experience is exactly what every designer goes through when they try to design for the web.
The fix for the problem is something called “responsive design”, a technique to have web pages ask the browser what the resolution is, then gracefully re-design the user experience based on the available screen real estate. Suddenly, it is impossible to know exactly how your software will look in production.
That means a test strategy (and an automation strategy) that needs to be capable of experimenting and learning what “looks right”, and what doesn’t, at various resolutions.
What You Will Learn:
When we try to open a website, the server reads “m.sub-domains” to identify what kind of mobile device the request originated from. Based on that, it redirects the user to the corresponding mobile version.
To make this 100% effective, each device should have its own design of the website specifically built for it; for example, a different specific design for Blackberry, iPhone, iPad, etc. taking into account their screen size and resolutions.
RWD targets for websites to react to their device, resolution and be able to render and adapt correctly. For example, if the user switches from desktop/ laptop to iPad, then the website should automatically adapt the resolution changes like image size etc. as per the respective device abilities.
In short, Responsive Design is “One website for every screen”.
The below screen is an example of RWD:
(Note: Click on any image in this article for an enlarged view)
Note: Real time example of a responsive website is www.fpl.com
In RWD, a website is designed to give a superior user experience through easy navigation, clear and simple user interface etc. Responsive websites adapt easily and work in all resolutions, browsers, screen sizes, hardware, and Operating Systems.
The diagram is an accurate simile to how the content adapts to the environment and behavior of the device.
Note: Apart from RWD there is another approach called Adaptive Web Design (AWD). In the AWD approach, there will be specific design for each device. However, AWD might not be suitable all the time. Besides, designing AWD sites takes more time and money in comparison to the RWD sites.
#1) User Experience: Based on the device from which we access an RW, it hides the unusual elements and helps the users achieve their goals faster. For example: if we open an RW from a mobile then it hides the unimportant elements and speeds up the loading of web pages.
#2) Sharing or Linking: For an RW only one URL is used for various devices. As only a single URL is accumulating all the data and information from various devices, it gives a better UX for users.
#3) Little or minimum maintenance required for an RW.
#4) RW layouts are fluid.
Differences between Responsive Web Design and Adaptive Web Design:
RWD & AWD are closely related to one another.
Responsive Web Design has three main components:
#1) Flexible Layouts: Building a website with a flexible grid that can be easily resized to any width dynamically.
#2) Media Queries: Provide various styles for the browsers and devices based on the context, such as the orientation of the device, viewport, etc.
#3) Flexible Media: As the size of the viewports changes, the media (images, videos etc.) also need to change their size or resolution according to the requirement.
Note: “Viewport” is the area of the browser where the actual content of the website is displayed. Viewport does not include the toolbars, tabs etc.
Open the link www.fpl.com from various devices and observe the URL. The URL of a Responsive website remains same for all devices.
a) View of the RW from a desktop or laptop (large screen size)
b) View of the RW from a tablet (medium screen size)
c) View of the RW from a mobile (small screen size)
Open the site www.yepme.com from a laptop and also from a mobile and compare the URLs. This yepme.com link is not a responsive link.
a) View of a non-responsive website from a desktop or laptop
b) View of a non-responsive website from a mobile
The Responsive design test means testing the website or URL from different devices. Practically, it is not possible to test the responsive website completely because to do so we need to set up various systems for various screen sizes.
A possible way for the responsive test is by resizing the browser window size as per the test scenario.
Some browsers, such as IE and Safari will provide plug-ins or browser extensions which will help you view the viewport area in pixels. This makes the testing easy by getting the desired screen size by modifying the pixels.
Other browsers like Chrome provide a software or program called “Emulator” which will help change the screen features and environment as per the desired device needed for testing.
Note: “Emulator” is software or program that is provided within the browser which makes the host system (current browser) behave like the guest system (browser of the desired device that is to be tested for the screen size desired).
Even though the emulators cannot give you the exact environment needed for testing, they are a cost effective solution to test an RW at a high-level.
The responsive web design tester should make sure that a responsive design is satisfying all the below-mentioned test scenarios to ensure it is a bug-free responsive design.
#1) Responsive website link or URL should be same for all browsers in each and every device irrespective of the screen resolution.
Suppose www.abc.com is a responsive website. If we open it on a laptop and in a mobile phone then the URL should be same on both the devices. The website opened in the mobile browser should not start with www.m.abc.com or www.mobile.abc.com
Example: Open the website www.kotak.com from a laptop and also open the same from a mobile too and observe the URL in both the devices. The URL is not same for both the devices.
Below snapshot displays how the URL changes for a non-responsive website in different devices such as laptop and mobile.
Open the website www.w3schools.com from a laptop and from a mobile and check the URLs. It should be the same for both the devices.
Below snapshot shows the URL remaining the same for a responsive website in different devices:
#2) The display location of the content (images, sub links, menus etc.) of a responsive website should change dynamically as per the change in the screen resolution. That is, if we change the screen resolution from the size of the laptop to mobile then the display of menu options should change dynamically.
Example: Open the link www.fpl.com from a laptop and click on the menu on the right top corner of the window. Menu options are displayed as shown below:
Open www.fpl.com from a mobile and click on the menu on the right top corner of the window. Menu options are as below:
Note: This scenario can also be tested using browser emulators (Ex: chrome).
Open the website www.fpl.com through a desktop and observe how the menu options are displayed. See below snapshot:
Now resize the browser window to that of a mobile screen size and then check the display of the menu options. See below snapshot:
#3) URLs of a responsive website should also be resolution specific.
Pre-requisite to test this scenario: Ask the developer to insert any sub-link into the Responsive testing website where the sub link is not responsive.
For example, the developer can insert link www.snapdeal.com to our testing website.
Now, open the responsive testing website from a mobile and click on the sub-link mentioned in the pre-requisite. Then the URL of the sub link should change to https://m.snapdeal.com.
#4) The same scenario can be tested from a laptop too. Open the RW from a desktop or laptop and click on the sub-link (mentioned in the pre-requisite of test scenario three) that is not responsive. The URL of the sub link should not change (as we are testing this scenario from the laptop the URL should remain the same).
#5) Pre-requisite to test this scenario: Ask the developer to insert any sub-link, for example, www.paytm.com into the testing site. The mobile device in which you are going to execute this scenario should have the respective application of Paytm installed in the mobile.
Now open our testing responsive website from a mobile and click on the “paytm” sub-link. Then the Paytm application which is installed in the mobile should be opened. (The user should not be redirected to the website in the browser or another window; only the app should be open.)
#6) The images in the responsive website are resolution specific. It means that the resolution of the image inserted in the code of responsive website designed for mobile compatibility is different from that of a desktop or tablet. Each screen size should have its specific image in the design.
Pre-requisite to test this scenario: Testing and checking the resolution of the images could be a tough task. Ask the developer to insert three different images in the responsive website separately for mobile, tablet and desktop.
Open the testing responsive design website from a desktop, tablet and a mobile. The images on the responsive web page should be different for all the three devices.
Open the testing RW from a desktop and check the image on the web page. Now resize the window to that of a tablet and check the image. This should be different from that of the image shown for the desktop screen size. Now you can resize the window to mobile screen size and check the image. This image should also be different from the above two images.
Example: Open the responsive site www.fpl.com from a desktop; right click on the image on the home page -> select “Inspect” from the menu. Check the image resolution (check the image file name extension .jpg) from the code. See the below screenshot:
Now resize the same window to that of a tablet screen size and check for the image resolution. (The image name extension is medium.jpg)
Finally, resize the window size to that of mobile screen size and check the image. (The image name extension is small.jpg)
#7) Click randomly anywhere on the web page and check if any data or text which is not hyperlinked gets initiated and redirected to any other page or content. This tests whether any word or text is marked as the hyperlink in the back end.
Note: In few projects, the requirements talk about the pixel size and resolution of the screen for particular devices. (For example, a tablet view for their RW should be at 15:15 pixel and for a mobile, it should be at 10:10 etc.)
Testing for the dynamic changes that should happen for the RW display when we change the pixel size is the main scenario.
#8) Open our testing RW in a browser and view the contents and display of main images. Now resize the window till the breakpoint of the tablet size and verify the changes that should happen to the image resolution and any other content. At breakpoints, the changes should happen dynamically (sometimes the changes will not happen at the breakpoints and may change at some other pixel size which is a defect.)
There are few tools (websites) that will let you preview the web pages of our responsive website.
For example, we can test our responsive site at different predefined screen resolutions (smartphones, tablets etc.) and also customize to any desired resolution. These tools make the testing activities easier and quick. Such in-browser tools can be termed as “Responsinator”.
Some tools also offer an important feature of capturing the responsive screenshot that might help us test the website designs, HTML, layouts, CSS etc. of the responsive website.
These tools are great alternatives when the actual devices are not available or ready.
Here is a quick tool list:
Enter the URL of the responsive website that needs to be tested in the above “Enter Your URL Here” field and click “GO”. You can even select the device and resolution at which you want to view the responsive site.
Now enter www.fpl.com in the field, select the layout “Nexus 7 PORTRAIT” and click GO. The site gets displayed in the resolution of the selected format.
Enter the testing site www.fpl.com and click GO.
Change the layout to desktop, tablet, mobile, etc. and test the site. With this tool, you can even customize the resolution.
For example, set the screen resolution to 512 x 256 and test the site.
Note: With this tool, you can even test scenario 6 easily by changing the resolutions and verifying the image naming.
Enter any URL, www.makemytrip.com and click Enter.
On the right-top side of the browser, you have the option to change the layout of the website to that of any specific mobile model or device etc.
Note: This tool has another feature like dragging the screen and modifying the resolution to our desired resolution.
Enter the testing URL, www.fpl.com in the field and click on “Test” button.
Note: This tool has only a few fixed layout options on which our site can be tested.
If you want to have a view of your RW on multiple screen sizes at a time then this tool mattkersley is what you need.
Now enter your testing URL in the address bar and click enter. You can view the RW on multiple screen sizes at a time.
#6) By default, chrome has few Dev Tools through which we can simulate the device mode and their capabilities.
To use this feature of chrome, open any testing responsive design website like www.fpl.com in chrome and right click on the webpage and select “Inspect” option from the menu or press Ctrl+Shift+I. The below window gets opened at the bottom of the web page.
Now click on the icon as shown in the below screenshot.
Mobile mode of the web page gets opened. From that, you can change the resolution to any specific pixel and also to any predefined mobile model which is displayed in the drop down menu. View the below snapshot to get a clear idea:
Note: We can also change the web page to portrait or landscape view too.
There are many other good solutions for responsive design testing like:
14) For MAC machines we have a separate application called “APTUS” to test an RW. This application allows you to set-up various break points on various devices for testing. APTUS is not a free application and we have to buy it from the Mac App Store.
Moving from 320×480 (the resolution of the iPhone4) to 2048×2048 (a large monitor) leaves over 4 Million possible browser sizes. Most test groups will narrow the list of test devices down to a handful. Even then, the manual testing problem is hard or impossible to approach.
Developers cannot possibly anticipate all of the platform problems, and testers can’t catch them before release. Because of this, we find the occasional user interface issue in production.
Maybe someone reduced the size of their browser causing important text fields to be covered by a page label. Perhaps some code designed to handle dynamic page resizing breaks modal date pickers and never gets noticed by a normal test built on WebDriver. There are too many display options to build tests for and too little time.
Let’s take a look at a realistic example to illustrate the problem.
Dynamic pages, things like advertising sliders, and content streamed in from users in different page sizes, are a staple of many software products. Add to this the fact that we can’t predict how the page will be displayed and many automation efforts start with failure.
I see two popular solutions for this problem — using a standardized, or baseline, data set and refreshing that every time the test suite is run, and taking things one environment or platform at a time.
Standard data ensures page content will look the same every time we load the test environment. That strategy combined with something like Sauce Labs that gives people access to many platforms and you get pretty far.
This approach takes time and resources. You will need time from someone with database access, usually a DBA, to create and update database exports. And, someone has to create scripts setup and teardown scripts to maintain the test environment. After all this effort, you might end up with the type of sanitized environment bugs love to hide in.
Alternately, you could use Visual Testing technology to help automate tests on web pages that vary in layout and content. Using this tooling, you can create tests without any changes to your test environment, and without requiring any skill sets from people outside of your test group.
Let’s look at an example.
Consider the Twitter mobile app.
This product is a combination of continuously changing user content and advertising. There are also a few core parts of the user interface, such as the news feed and notifications, in the header.
Using a visual testing tool, you could start by performing a screen capture of the entire scrollable page, not just the viewable area. You could choose a comparison option that ignores text content but focuses on page elements.
For example, You could see that the fields for tweets exist, that each tweet has a name element and a date/time element, without worrying about what is in the elements.
Searching for elements across full pages also relieves the maintenance and complexity burden we see in many automated tests. Rather than manipulating data on a page, saving, scrolling and then verifying, you get everything in one shot. This means less code to write, less code to maintain, and fewer false positives in the nightly test runs.
Responsive design has added the combinatorial problem to every available platform. The question is; out of all of these possible platforms and screen sizes, which do we select for the best test coverage.
Reducing the number of environments we cover to only the most popular ones makes the technical task easier while also ignoring the coverage problem.
Increasing the number of environments with an automation framework alone creates a maintenance nightmare and potentially adds an unsolvable testing problem.
The combination of good visual testing tools with a flexible UI automation framework, such as web driver, can make the technical aspects of this problem not just easier to deal with, but solvable.
The target is good user interface coverage with a reasonable maintenance burden. Visual testing is your only robust and scalable option.
#1) While testing an RW you should mindful of the design consistency such as the alignment of images, texts, padding around the edges etc. across all the browsers and Operating systems.
#2) During the testing of an RW, the tester should be aware of what to test and how to test on multiple devices at different breakpoints. Otherwise, it could be quite exhaustive and disorienting.
#3) For thorough testing of a responsive website, the tester and developer coordination is a must. The developer should help testers with creating the conditions mentioned in the prerequisites of the test cases.
#4) Check whether the web pages are readable at all resolutions, i.e. the content should be readable even if we resize the browser to mobile screen size.
#5) The important content of the RW should be visible for all breakpoints, i.e. if we change the browser size from desktop screen to mobile screen then the main images, main text, menu, etc. should remain the same.
#6) If the browser is resized for testing then any click area (like buttons, menus, sub links etc.) of the RW should be suitable for clicking.
#7) Resizing the browser and testing the responsive website can identify only a few major issues whereas there may be a few other issues related to finger-swipes, tapping etc. on mobile devices. Testing these particular features on the actual devices can lead to better defect finding and removal.
When we are testing Responsive design will have many challenges. You should think in an efficient way to overcome the challenges.
Testing a Responsive website is very important for a successful future of many mobile applications. Mobile users are only going to increase and their expectations are very varied from that of desktop users. Implementation and thorough testing of RWD is a great way to set your site up to meet the expectations.
Implementation and thorough testing of RWD is a great way to set your site up to meet the expectations.
We hope the information, tips and test scenarios discussed in this article will surely help your responsive website testing needs.
About the author: This is a guest post by Laxmi. She is having 7+ years of Software testing experience and currently working as a senior software test engineer.
Try all the examples provided in this article and let us know if you have any queries/comments on the same.