How to test a responsive website? What problems arise when testing websites on different devices? How is testing a website on a desktop monitor different from testing on a handheld device such as a mobile phone? What tools can we use to test responsive websites? Our
What is responsive web design?
Responsive Web Design (RWD) is a definition of an approach to web design that aims to create websites to provide an optimal experience - simple reading and navigation with minimal size, panning and scrolling on a wide range of devices (from desktop computer monitors to mobile phones).
A site built with RWD adapts its layout to the viewing environment using fluid, proportional grids, responsive images, and CSS3 media queries in the following ways:
- The fluid grid concept requires that page element sizes be in relative units, such as percentages, rather than absolute units, such as pixels or points.
- Flexible images are also evaluated in relative units to prevent them from being displayed outside of the containing element.
- Media queries allow a page to use different rules CSS styling, based on the characteristics of the device on which the site is displayed, most often the width of the browser.
Challenges of testing responsive web design
Many people now use their mobile phones or tablets to access websites, so testing responsive web design is important because the user experience on mobile devices is very different from desktop computers.
Perhaps the most difficult part of testing a compliant website is that the website performs as expected on multiple devices and platforms, but actually testing on every mobile device on the market is impractical for most of us.
Many testers who start testing responsive web design usually start by resizing the browser window to fit the size of the mobile, tablet, and desktop viewport. This method is generally suitable for quickly visually inspecting a website on different viewing ports and helps us identify underlying display issues when we reduce or enlarge the browser window.
However, testing on real mobile devices is a completely different experience.
Using emulators
Mobile emulator is a web simulation of how websites and apps will display and function in a mobile environment.
While emulators may not provide you with the exact testing tools you'll need, they are still a cost-effective solution for testing a website's high-level functionality.
Google DevTools
In DevTools Google Chrome There is a feature called device mode that is loaded with useful tools for testing and debugging responsive projects.
Unlike most other responsive design testing tools that simply resize your screen, this tool actually emulates the work mobile device, especially touch interactions like tapping and scrolling, right in your web browser.
Some general rules for testing responsive web design:
- Text, controls and images are aligned correctly
- Suitable click-through zone
- Color, shading and gradient match
- Check that the edges are filled correctly
- Text, images, controls, and frames do not fall to the edges of the screen
- Font size, style and color are appropriate for each text type
- Scrolling text (data input) appears correctly
Check the location of modules as they shrink and expand the browser window or as you rotate your mobile device. Various modules may disappear when switching from desktop computer on mobile, but make sure you know exactly which modules should appear in which viewport.
Finally
Find out how your web application is being used. You can get a wealth of information from Google tool Analytics to see what devices your customers use to access your website. Use automated tools and emulators to perform basic checks and high-level functional testing and combine this with real testing devices manually.
From the author:“Stop resizing this browser, it's about to wear itself out!” How often do you hear this? Well, okay, maybe not that often, but if you develop responsive websites, you know what I'm talking about: every time you edit the DOM or CSS, you're dragging the edge of the browser back and forth, testing the changes and looking for inaccuracies.
In general, most of these efforts are an attempt to mimic the screen sizes of different devices.
If you're doing enterprise development, you probably have a lot of company-provided devices to test. Where I work, we have iPads, iPhones, one or two other tablets, laptops and desktops. If you don't have that luxury, you have to use what you have at hand.
At home I have two different laptops, two different Android devices: Kindle and Nexus 7. I use these devices to test my freelance developments, but it is clear that this is not an exhaustive selection. There are no iOS devices at all, and while I'm considered an early adopter, I don't plan on buying every new phone/tablet/tablet as soon as it goes on sale.
So what should a developer do? Fortunately, there are a growing number of browser-based tools that simulate the screen sizes of a variety of devices. Different tools, of course, come with different sets of features and different levels of efficiency. We will look at some of them here.
For testing purposes, I took the first truly responsive website I created, PajamasOnYourFeet.com. It is based on the Brownie HTML5 template, very generously and freely provided to the developer community on EGrappler.
Am I responsive?
Am I responsive? – a completely easy, instant preview of your site in terms of how it will appear on four different devices. All four are iOS, and the developer explains his choice on the website. It doesn't offer any controls or selections, just a very simple and elegant display. View window dimensions:
Desktop - 1600 x 992px, decreasing by scale (0.3181)
Laptop - 1280 x 802px, decreasing in scale (0.277)
Tablet - 768 x 1024px, decreasing by scale (0.219)
Mobile - 320 x 480px, decreasing by scale (0.219)
To quote the developer: “This is not a testing tool, it is very important to do this on real devices. But it is a tool for taking quick screenshots (for me) and providing a visual opportunity to “drill down” in client meetings what you meant.”
device positive
deviceponsive is similar to the Am I Responsive site? one that displays your site simply and neatly, but has no controls or available options when it comes to devices. All of them are shown simultaneously on one long page. It has an interesting property - you can modify the header by editing it background color and inserting your own logo, and then “print screen”. This way, in a sense, you can brand your site when showing screenshots to the client. Devices and screen sizes simulated on this site:
Macbook - 1280 x 800
iPad ( portrait orientation) - 768 x 1024
iPad (landscape) - 1024 x 768
Kindle (portrait) - 600 x 1024
Kindle (landscape) - 1024 x 600
iPhone (portrait orientation) - 320 x 480
iPhone (landscape) - 480 x 320
Galaxy (portrait) - 240 x 320
Galaxy(landscape) - 320 x 240
As with most similar tools, scroll bars appear on small devices. They won't show up on a real device, but to be able to scroll the test view on a non-touch device you have to make some concessions.
responsive test
Like deviceponsive, responsive test displays your site on multiple devices, but instead of showing them all at once on one page, you choose which device to view from a simple menu at the top of the page. Browsing this site on a medium-sized laptop, I found that shrinking the page works great, allowing you to see the entire site inside the window of the device under test.
It offers thirteen different viewing windows, from a large desktop monitor to what's called Crappy Android (to be fair, they also have an option called " Android is better"(Nicer Android).
Once again, Firefox stumbles a bit on this site. Notice in the screenshot - between the green header and the content area with a white background - there is only a blue bar where the image slider should appear.
responsive.is
It's very similar to the previous two, and the only thing that sets responsive.is apart from them is the smooth animation of the display from one device to the next, as well as a translucent overlay showing the site's real estate falling out of the viewport.
The only available device options here are automatic ones, which fill your browser window, showing the site as you would see it if you went to it: Desktop; Tablet (landscape orientation); Tablet (portrait orientation); Smartphone (landscape orientation) and Smartphone (portrait orientation), pixel dimensions are not given.
Screenqueries
Once again, several different features and options set Screenqueries apart from other sites. There are 14 phone and 12 tablet devices with a separate element for switching portrait and landscape modes. These are displayed on a numbered pixel grid, with the dimensions shown at the bottom right of the test display. The edges of the display are draggable so you can test custom sizes. Drag or click over the testing area and the background will turn gray, with a less cluttered appearance.
Interesting feature this site - for several devices there is a “True view” option, which shows your site wrapped in the chrome browser assigned to this device. Unfortunately, and I'm already used to this, Firefox is unable to display the image slider of the test site. Don't worry, I really prefer Firefox when it comes to browsers, but luckily we have options.
Screenfly
Screenfly really increases the usability factor. It offers nine devices larger than tablets, from a 10-inch laptop to a 24-inch desktop, five tablets, nine smartphones, three TV sizes and a custom screen size option. Any option you select can be rotated in portrait or landscape using individual element menu controls. You can choose whether to allow scrolling or not and generate a shareable link with one click of a button.
The site is proactively useful in the way it presents pixel sizing information. Each device in the menu is shown with a name and pixel dimensions, the size of your own browser window is shown near the top right corner of the window, and the dimensions of the selected option are shown in the footer below the display along with the URL of the site being tested. This small feature makes it easier to document screenshots and share information with clients.
All of the above would have already made it an ideal tool, but the Screenfly developers found an opportunity to make it simply top class and provided a proxy server property. Quoting from their website: “Screenfly may use a proxy server to impersonate devices while you view their website. The proxy simulates the user agent string of the devices you select, but not the behavior of those devices." All other tools covered here deal exclusively with CSS. Screenfly is the only one that allows testing based on the user agent string.
Having tested one site I created with an existing mobile version in this way, I can say that the results were very good. Everything displayed exactly as I expected and the features were testable. It must be said that testing user agent strings has become traditional, but this site was made a long time ago, and the proxy property turned out to be a very useful addition to it indeed.
Conclusion
So, you can see that there are plenty of resources available for testing responsive websites. They differ in unique properties; which sites you use will depend on your personal preferences and requirements, and I try to encourage you to explore and experiment with them. The more we, developers, have truly useful tools, the better.
One of the most remarkable tasks that the EastBanc Technologies QA department has ever faced is the creation of an automated website testing system www.washingtonpost.com . This is an electronic newspaper implemented as an information and news portal.
The main reason for the need to create an automated testing system was that the application was planned to transition to a new CMS (the so-called PageBuilder), which should replace several other CMSs previously used to publish content in various sections of the site. With this kind of migration, it is very important to avoid mistakes so that the content published through the new CMS on various types of pages looks appropriate.
We are not faced with the task of checking all pages for compliance with our tests. Our task is to identify PageBuilder bugs, check the reliability of the layout of pages created by a freshly baked PageBuilder, and draw the attention of Washington Post editors to those nuances of filling a specific page with content that may lead to potential problems in displaying pages.
The creation of a testing system is under active development, but some points that we think are interesting can already be presented to the general public.
Before we do this, it is necessary to note one feature of the project: all our testing takes place “outside”. Those. We, like any other user, use the combat version of the site for testing.
Selecting layout testing tools
Having explored the Internet, we settled on the following approaches and tools. To test the page frame, we used the framework Galen , which was later integrated with testNG.
Naturally, passing the Galen test for a page frame does not mean the layout is valid. In addition to the location of the blocks, you also need to check the display of various elements inside the block. We decided to test the internal contents of the blocks by comparing screenshots.
Screenshot tests include various logos, buttons, some blocks with specific display - everything that Galen cannot reach and that is difficult/impossible to check with functional tests.
Azure color - tested by Galen, filled with green - screenshot tests:
Carefully! Big picture
Hidden text
Galen and Screenshot tests can successfully replace some functional tests, sometimes gaining in clarity, sometimes in speed, and sometimes in both. We select a testing method for a specific case through a collective discussion of a test case for each type of page based on the criteria of performance, ease of support, completeness of test coverage and clarity.
For example, there are 2 blocks that we initially wrote functional tests to test: Most Read and Information Block. Now we check the first one with screenshots, and the second one with a Galen test.
MostRead Block, screenshot test:
Relatively functional test: there are significantly fewer lines of code, the completeness of test coverage has increased, and the test is updated when changes appearance this block on the page will not take much time.
Testing this block is discussed in the chapter on the screenshot method.
WaPo Information Block: 
Galen easily copes with checking the correspondence of the text and links of a given block: the links themselves are specified in the locator, and the correspondence of the text is done by an internal galen check. Regarding the functional test, the completeness of test coverage has not changed, but due to the fact that the checks are carried out within one test, we significantly save time.
Galen test code.
Our automated system testing uses: Java, Maven, TestNG, Selenium WebDriver, Selenium Grid, Galen Framework.
A cross-platform set of utilities actively helps us in creating Screenshot-based tests ImageMagick.
I would like to immediately note that we write the test code in Java using the PageObject pattern and the Yandex framework - HTML Elements . Maven and testNG are used to run tests.
To make it easier to run tests, view the history of test runs, and view reports without involving highly qualified specialists, we are developing a separate application - Dashboard.
It would be worth emphasizing that now we are still at the research stage of how to properly organize the entire testing process, and not all approaches have yet been fully mastered and studied
Testing with Galen Framework
Galen Framework has many undoubted advantages: it is a flexible, easy-to-use tool with extensive testing capabilities adaptive design. In addition, it is well documented and is actively being developed at the moment.
Galen Framework has already been described in sufficient detail in one of articles . To briefly describe the principle of working with Galen, it looks something like this: you write a page specification (the so-called spec file) using a special, well-documented and intuitive syntax. The spec file describes the relative position, size, indents, nesting of page elements and some other parameters and conditions that the page layout must meet; you can even check the consistency of the text inside the element. And all these checks will be applied depending on the tags we specify.
Tags in the spec file can be set like this:
Galen performs all checks and then generates a visual report in the form of an html file. The report indicates which specific checks failed for a given test, and for each of the failed checks, you can see a full screenshot of the tested page, where the elements that failed a specific check will be highlighted.
For example, a failed test for the distance between neighboring elements The report will look like this:
When you click on a check highlighted in red, a screenshot of the entire page being checked is displayed with the elements highlighted as follows:
Galen Framework accepts the following parameters as input:
- browser in which the check will take place
- resolution at which to run the test
- url of the tested page
- A Javascript file that needs (if necessary) to be applied on the launched page before starting checks against the .spec file (for example, if you need to check the display of the page for a user logged in on the site)
- name of the .spec file to be launched
- tags that need to be applied to the checks of the .spec file (for example: desktop, all, if we are testing the layout for a desktop).
As you can see, by varying the parameters supplied to Galen, you can achieve almost complete test coverage of our site’s framework.
After we decided on a tool for testing the site framework, the next task was to choose a scheme that would ensure maximum page coverage with Galen tests.
Selecting a page to test from a subset of pages of the same type
Which pages to choose for testing the layout if the test is intended to test many similar pages?
We decided, without bothering too much, to select a random page from a subset each time we run the test suite (i.e., to test a subset of recipe pages, we selected one of the recipes and passed its url to all layout tests). Since it is not worth checking all the pages of the task, therefore the option of choosing a random page seemed optimal. The URL of a random page of a subset of the pages being tested is transmitted to Galen using a method common to all tests within our automated website testing system (except for layout testing tests, we also have functional and screenshot tests).
For example, there are 2 options for displaying the same type of pages - pages of culinary recipes, in one of which the layout contains an error:
From the example you can see that the “Most Read” block, which should be located in the right column of the page, on the left page is located in the main part, and not on the right. To check that there are no such problems, you need to check a large number of pages and take into account many factors.
At what resolutions should I run tests?
First, the idea came to select the most common devices and use their resolutions to run tests. However, the clearly visible trend of accelerated mobilization of the planet does not allow us to identify (and, even more so, predict) any undisputed leaders in this field. There are a great many devices that allow you to view web applications, and unifying permissions for such devices is completely unfashionable today. The sudden idea that responsive design is responsive in order to display correctly at any valid resolution saved our minds and stopped further research in this area. The decision was made: we test the layout on all valid resolutions.
Valid permissions were assigned to all permissions from min Viewport width = 241 px (the browser does not shrink smaller) to max Viewport width = 1920px (the upper limit is a simple force of will). We have not yet had pages where the height of the viewport for the purposes of automated testing was the determining parameter, so we are not paying attention to the height yet.
How to test layout at all resolutions?
To begin with, the entire range of valid resolutions was divided into ranges of different layouts. The layouts themselves are “rubber”, but the different arrangement of the blocks makes it possible to make a distinction. It’s not difficult to determine the boundaries of layouts - we pull the corner of the browser and look at what boundary point the page blocks change: their relative position, number and/or behavior. For simplicity, we take into account only the width of the viewport. The result is the following table:
DESKTOP: max 1920px, min 1018px;
LAPTOP: max 1017px, min 769px;
TABLET: max 768px, min 481px;
MOBILE: max 480px, min 361px;
SMALL_MOBILE: max 360px, min 280px.
By the way, we have decided not to test the SMALL_MOBILE layout yet, since the number of users viewing the Washington Post on devices with such resolutions is catastrophically small (a speculative conclusion, and there is no problem adding it during testing in the future). There are 4 ranges left for testing, with different layouts.
Below is the code to run the Galen test for desktop resolutions:
Hidden text
When running each test, Galen is given a random resolution from the range for a given layout (getRandomResolution(DESKTOP)):
And, in fact, the resolution range is set as follows:
Testing by randomly selecting a resolution from a valid range and a test page from a subset of similar pages thus turns into a probabilistic process. The more often we run it, the more different bugs we will find. With a single successful test, we can only say that this specific page at this specific resolution – valid. But after 500 successful runs, we can say that the layout is mostly viable. Let’s say right away that “500 successful runs” is a speculative estimate, and here you need to look at the content and the number of equivalent pages.
Running at a random resolution very quickly paid off and immediately revealed one interesting bug that we most likely would have missed when running tests at a fixed resolution.
Let's look at how this approach helps us using the example of testing a recipe page.
The recipe page wireframe test runs for a resolution range (Viewport width) from 768px to 1017px. Let's take this page as an example: www.washingtonpost.com/pb/recipes/maple-banana-frozen-yogurt/14143/
The test at the boundary points of the Laptop layout (1017px and 768px) did not produce errors.
However, after we started running the test at a random resolution, in about half the cases the tests crashed and screenshots showed that blocks from the right column were crawling down under the main content.
Correct view:
Carefully! Big picture
Hidden text
The layout is broken:
Carefully! Big picture
Hidden text
Screenshot-based testing method
Inspired by the article , we decided to use a screenshot-based testing method. By the way, to test the layout, we initially relied on this method. Those. the idea was to compare full-size screenshots of the page with a pre-prepared model, replacing all potentially changing elements with stubs (a pre-selected arbitrary image is taken as a stub). These elements included pictures, flash advertising and text. The idea failed mainly due to the fact that the pages contained many blocks that were loaded dynamically, as a result of which the physical sizes of the screenshots taken and the location of the blocks changed from test run to run. In addition, for some time now Chrome has lost the ability to take full-size screenshots, which also created a number of problems.
Screenshot-based tests now check those individual elements and blocks on the page for which display is important, and/or verification of which with functional or functional tests is difficult or impossible.
For example:
This is what the MostRead block looks like: home page washingtonpost.com (left) and the model with which we will compare a screenshot of this block (right):
The test code looks like this:
The following directory structure is used to store screenshots: /models/HomePage/firefox/HomePage_thePostMost.png
As can be seen from here, for different browsers Take your own model screenshot of the required block.
The shootAndVerify() method finds the path to the model based on the class of the passed page and the name of the browser in which the test is running.
Looking ahead, let's say that it works quite well, and then we will describe some details of the process with the caveat that not everything has been fully debugged.
As it turns out, the snapshot taken of the required block may depend on many factors, such as:
- operating system version
- operating system theme
- browser and its version
- Various font smoothing options and hardware acceleration.
The first problem was that the sizes of the screenshots taken differed depending on the OS and browser settings. To make the block sizes, and therefore the screenshots, the same, you need to launch the browser with constant sizes. You can change the size of the browser window using the corresponding web driver method: driver.manage().window().setSize(requiredSize). But in this way we set the size of the window, and not the size of the visible area we need - the viewport. The vertical scrollbar, by the way, also affects the size of the viewport, and its thickness also depends on the windows theme, so you need to take this into account. The solution to the problem was a calibration method that adjusts the size of the viewport to given dimensions. After running the first test, the difference between the width of the window size and the width of the viewport is saved in a special parameter and reused in subsequent runs.
The second problem we encountered was the different display of fonts in browsers due to anti-aliasing settings. We tried to solve the problem by installing various settings browser, such as:
layers.acceleration.disabled
gfx.font_rendering.cleartype_params.rendering_mode
gfx.direct2d.disabled
But, unfortunately, this did not help.
In addition, to compare screenshots, the ImageMagick utility uses a parameter such as fuzz, which sets the maximum possible discrepancy between screenshots.
Tried to solve this problem, experimenting with this parameter. A small fuzz coefficient did not solve the problem, since the number of different pixels was very large due to the fact that there was a lot of text, and a large coefficient led to the fact that the absence of some elements in the blocks did not affect the test, and led to potentially missed bugs.
The solution was to duplicate all the settings of different browsers for everything virtual machines, on which the tests were run, and duplication of the operating system settings themselves.
For example, a test that checks the block social buttons, in which one of the images did not load.
The following links are available in the report:
picture-model 
screenshot of the unit being tested:
The result of comparing these two images:
CommandException tells us that the compared images differ by 251px:
There are also situations when the screenshot sizes do not match. In this case, we will receive the following report:
Sometimes, for unknown reasons, elements within the block being tested are slightly misaligned. For such cases, we compare not with one model, but with a group of models that match the mask, i.e. we can have several models of thePostMost block with the following names HomePage_thePostMost.png, HomePage_thePostMost (1).png, and we consider all models valid. Fortunately, the number of such options is finite, usually no more than 2.
Technical aspects
As mentioned above, a technology stack is used to write and run tests: Java, Maven, TestNG, Selenium, Galen Framework. In addition, test results are sent to graphite. Tests are launched directly using Jenkins CIS. We will not go into detail about why this particular set was chosen. Let us briefly describe how this is all interconnected.
Selenium Grid is currently deployed locally on four virtual machines with Windows 7, where the grid nodes are running, and on a Linux machine, on which the hub is running. Each node has 3 firefox and chrome browser instances. In addition, Jenkins and graphite are also deployed on the Linux machine. Galen tests run in the general test run thanks to integration with TestNG. For this purpose, a corresponding class was written that allows you to use the jav Galen API. When implementing the interaction of TestNG with Galen, we encountered some problems that were promptly resolved thanks to interaction with the Galen developer. The Galena developer himself is willing to cooperate and regularly releases updates for this tool that expand its capabilities and make it even more convenient. He himself plans to write documentation for integrating Galen with TestNG.
Functional, galenic and screenshot based tests are separated using the corresponding group parameter assigned to the Test annotation, and it is possible to run them separately.
Our conclusions
Both approaches - the method of comparing screenshots and testing using the Galen Framework - are applicable for testing page layout. They successfully complement each other. The screenshot comparison method is more applicable when you need to test the display of any individual element or block, for example the sharing panel in in social networks or the main menu in the header. A block can contain many icons within itself, which in turn can be located inside other icons and elements, or have relative positioning with them.
Using Galen, describing all these small moments is quite labor-intensive, but one screenshot for each browser solves this problem, and comparing screenshots eliminates the possibility that we might miss something when describing a spec. Galen, in turn, does an excellent job of relative placement of blocks and checking the headings and fixed text within them. It has a good use when you need to test the layout on the same type of templated pages that are not loaded with functional logic, for example, any information portal, as in our case, when almost any page of the site is available without authorization or any other user actions. In addition, Galen is good at solving problems of cross-browser testing in conditions of adaptive application layout.
The test shows what a responsive website looks like on various mobile devices. To be tested, your site must support loading and running in frames. For ease of viewing, switch your browser to full screen mode.
Check
What is a responsive website?
A responsive website automatically adjusts to the width of the device. In this case, site blocks can be hidden or modified. For example, on a computer, the site’s logo and menu are located from left to right, and on a phone, from top to bottom.
What is the difference between a responsive website and a mobile version?
If the site has a mobile version, then when loading such a site from a mobile phone, you will be redirected to another address: site.ru → m.site.ru. The mobile version is a separate site with a different address.
If the site does not have mobile version, the site address will not change when downloading from a phone. The same data will be downloaded to the phone as to the computer. Most often this is inconvenient for the user, because the phone screen is several times smaller.
This problem can be solved in two ways: add a mobile version of m.site.ru or NOT make a separate site, but add it to your main site adaptability. These are special styles and scripts that are turned on if the screen width is too small: for example, hide the menu, increase the font, show small ones instead of large images, etc.
Strictly speaking, you cannot compare a responsive website and a mobile version of a website. Essentially a responsive website = full version+ version for tablets + version for phones (mobile), and all this in one bottle. That is, one concept is contained in another.
An adaptive website combines both a regular (for PC), and a mobile (for phones), and several intermediate options(large phones, tablets, TVs, etc.). The main advantage of a responsive website is that it looks good on any screen width.
Why is the width of the phone in this service so small?
The actual number of pixels on modern gadgets is usually very large, and websites are not designed for such a huge width. Therefore, mobile devices with high-definition screens open websites, bringing them to a certain virtual standard. To find out these numbers for yourself, click the button by opening this page from your phone or tablet:
What is my browser window size?
On devices with retina-like displays, the dimensions shown will differ from the actual pixel resolution stated in the device specification. Smartphones will show 320x480 or 480x800 pixels, tablets - 1280x800.
Constant growth in the number of different portable devices creates opportunities for more and more users global network use mobile gadgets as means of viewing web pages (making online purchases, viewing necessary information, simple surfing of media content, etc.).
And since any technology does not stand still, one mobile device is instantly replaced by another, and the concept of adaptive design is being actively introduced in the web development environment.
If earlier the situation with support for mobile devices was solved by the banal creation of a separate mobile version of the website (such as on a special subdomain m.mobilesite.com), today these things are done precisely with the help of adaptive design and layout (through the introduction of media query technology inside set CSS3).
Such data is a collection of special styles created to resolve mobile devices with certain parameters of a portable gadget. The following principle is applied: if the gadget has certain screen sizes that the layout designer needs to fulfill in the process of creating a website layout, he uses the necessary CSS symbols and rules.
Adaptive web design is a special approach to the development of original web design, which focuses on creating easily viewable sites and platforms based on the use of tools for optimal perception - banal reading of text blocks, panning, and scrolling of dynamic blocks on maximum number mobile devices (from tablets to cell phones).
It seems that all this is very simple and even every inexperienced layout designer could independently cope with the task of creating an adaptive design. But, as practice shows, not all front-end developers fully grasp the essence of the requirements of such a layout, which is why QA specialists always have enough work to do when running a “freshly printed” HTML5+CSS3 layout.
Problems of testing adaptive layout
More than half of Internet users use their mobile gadgets and tablets as tools for interacting with websites, which means testing adaptive layout is very important, because sometimes front end mobile device is fundamentally different from the resolutions of desktop devices.
Most likely, the most difficult part of checking a website for certain data is precisely that the portal functions as it is required from the entire list possible devices, but actually testing remains a highly impractical task for many users.
Adaptive design
Very often, testers who are tasked with testing adaptive layout traditionally start working by reducing/adding the size of the browser used in order to adjust the product to the potential size of a portable device.
This method, of course, can be used, but only for an instant visual analysis of the site’s performance in different resolutions. This way we can immediately identify basic problems with the display of the image when we alternately reduce or increase the size of our browser window.
But in this context, we can point out that testing on real portable gadgets is a radically different experience and ability to perceive the product being developed.
How to test adaptive layout?
As a rule, when testing adaptive layout within an entire web studio or department of a quality assurance company, you should have at hand a whole scattering of various mobile devices that can be used to run the required resolution in the most real conditions.
Of course, it’s just ideal if you have a brand new iPad or iPod nearby, as well as many other Android gadgets with different resolutions.
But when there is no such luxury, you have to use what is at hand.
Much to the happiness of testers, free ones have been created for a long time online programs and services that imitate sizes mobile gadgets and ideal for testing adaptive layout. It is logical to assume that each of them has its own advantages and disadvantages. But first things first.
Am I Responsive
The most simple tool with which you can view your website on the 4 most popular devices. I am glad that there is no particular overload in terms of settings and parameters: everything is simple and extremely clear.
You can test at the following resolutions:
- PC – 1600 by 992 pixels;
- Laptop – 1280 by 802 pixels;
- Tablet computer – 768 by 1024 pixels;
- Cell phone – 320 by 480 pixels.
Deviceponsive
In some ways it is similar to Am I Responsive, probably in its simplicity and minimal set of settings for performing layout analysis.
All available resolutions are displayed in a row on the page. Using the provided options, you can edit the background and size of the title, move another logo, which is useful if you need to take a screenshot.
Available devices and portable resolutions:
- 1280 x 800 pixels – Macbook;
- 768 by 1024 pixels – iPad;
- 1024 by 768 pixels – iPad;
- 1024 x 600 pixels – Kindle;
- 320 by 480 pixels – iPhone;
- 240 by 320 pixels – Galaxy;
By the way, when working with a website, the service specially applies scroll bars to pages so that PC users can conveniently check every centimeter of the created layout.
Responsive Test
Like Deviceponsive, this service allows you to test websites on a variety of real devices online. But, in order not to look at resolutions that are not of interest to you, in the service menu you independently select those that are relevant for you.
The portal has a very well developed scaling logic, which means there are variations for tests high resolution on a small one.
About 30 different resolutions are presented - from a regular desktop monitor to old version Android.
By the way, if you are working with the Firefox browser, you may experience certain problems.
Why? There is no exact answer.
It's worth writing to support.
Responsive.is
Very similar to the first two instruments. But it has its own distinctive feature - a set of smooth animations when changing one “device” to another, as well as a translucent background that demonstrates the real volume of the site, and not just the area you are working with at the moment.
The following permissions are available for work: desktop, Tablet PC in portrait and landscape variations, mobile phone in portrait and landscape variations. Unfortunately, it is not possible to set your personal sizes in pixels.
Screenqueries
Significantly different from all previously described services. On the portal you can use up to 14 phones and 12 different tablets to conduct the most fruitful study of layout.
There is a function to quickly switch from portrait to landscape mode and back. All collected results are displayed on a special grid with convenient rulers, allowing you to instantly measure the required proportions and sizes of blocks and other things.
There are parameters for specifying an arbitrary resolution (just drag the bottom or right edge of the visible area of the site alternately).
You can also separately specify such a feature as the “Trueview” variation, which allows you to look at the display of a website in the “native” browser of a mobile device (for example, in Safari on operating system iOS).
Screenfly
In our opinion, this is the most functional and optimal service for checking the adaptability of the layout.
The Responsive Calculator
With its help, you can quickly convert a PSD layout into the required percentages while viewing the adaptive version of the future site. All you need to do is select several current specifications and alternately turn the site pixels into the required values in percentage terms.
Mobitest
It is a completely free tool with which you can quickly check the mobile performance of any website. You just need to enter the site URL in the required field and click the “Start” button.
This page will load quickly, and you will be provided with a comprehensive report on how long it actually took to fully load.
By the way, you can not just study only numbers, but “ask” the program to create a report in the form of a diagram or as a media file, which, after completing the test procedure, you can easily download to your local computer.
Mobile emulator from Google DevTools
As you know, a mobile emulator is a specialized virtual emulator of how the desired website will be displayed and interact with the user in a special mobile environment.
Although these types of tools cannot generate 100% correct data that can be used for subsequent tests, they are still the most cost-effective solution for conducting rapid, high-level performance testing of a web product.
For example, in Chrome browser There is a special user function with which you can alternately operate with a variety of tools to conduct tests and debug all the nuances that arise when creating an adaptive version of the project.
Google has even released a special set of rules for best responsiveness testing. software, namely:
- Checking the accuracy of display of text blocks;
- Optimal clickability zone for objects;
- Matching color and gradient given values from design;
- Correct filling of edges;
- Blocks, pictures and text do not go beyond the visibility of the screen;
- Each type of text has its own fonts, sizes and connected styles;
- When scrolling, the text is displayed correctly, does not float, and is aligned to the width (strict alignment to the left is such a law!).
Always check the location of unique site modules that can function freely on a PC, but when switching to mobile resolutions, disappear into an area invisible to the eye. This point can be displayed in the technical documentation (a checklist so that the QA department employee knows in advance which modules to “catch” in the adaptive layout and which ones to ignore).
And in conclusion...
Always try to check the adaptability of the web product you are developing. Use a specialized set of automated platforms and services that will quickly perform the necessary checks and provide accurate data on what has been done functional testing and will help you become a professional in the future in finding the most common bugs in mobile coding.
Loading...
