A few months, I wrote a blog post about performing compatibility testing for mobile web apps. Since that time, I have been talking with Sauce Labs about putting together a webinar focusing on locally debugging and executing compatibility testing that will eventually be run in the cloud. And that time is finally almost upon us! You can sign up here for the webinar, which will mostly consist of walk-throughs of writing and debugging tests in preparation to run over multiple devices and platforms off in the cloud.

One of the additional things covered will be a brief overview of how web pages are architected, and how this can lead to writing more effective tests. While users will not care about your site’s architecture, it’s important for the tester to know what strategy was used to build the site, in order to ensure tests can be modular, efficient, and robust. This post will cover the different methods of web application architecture. This will be covered in the webinar, but not in as great detail. The webinar however, will have a lot more examples of how to utilize this information for test design.

Non-Responsive Sites

A non-responsive web application is one that responds the same way all devices. The same information is displayed on a laptop’s web browser as it would on a mobile device. While more and more sites are moving away from Non-Responsive sites, there are still multiple advantages to it.


  • Less Expensive
  • Less Complex
  • The mobile web world is changing really fast
  • Easier to design tests


  • Information may be harder to read
  • Buttons and links may be more difficult to click

Separate Sites

Having a separate Mobile Site is an approach that  is also used to provide a better mobile experience by redirecting mobile users to a separate site optimized for mobile use. Different URLs are used to access each site, typically a www and an m site. That said, it is not required to have different sub-domains to have separate sites, different folders, pages, etc, for different devices or browsers, is enough to qualify as having separate sites.


  • ŸBetter mobile experience
  • ŸLess complex site design


  • ŸSEO penalties
  • ŸDual code maintenance
  • ŸLinks don’t transfer

Responsive Sites

Responsive Web design is an approach that suggests that an app should respond to the user’s behavior and environment based on screen size, platform and orientation. The site responding differently to different devices or browsers, whether on the front or back end, really defines a responsive site.


  • The app is easy to use with all interfaces
  • Design looks good on any interface
  • Don’t have to redesign the site for each new device


  • ŸMay suffer from performance issues
  • More expensive to design, develop and test

There are generally two different methods for setting up a responsive web application. Creating a Responsive Design Website (RDW) means that the responsiveness comes from the client side. Data is passed to the client from the server, and based on the screen size and browser capabilities, the data is rendered in such a way to make the best usage out of the web application. A Dynamic Serving Website, conversely, reads the device trying to access the data, and passes back different information based on how the browser identifies itself. The server tries to send the best data according to what device is requesting it.

Responsive Design Website

This practice often consists of flexible screens, grids, and layouts, images and an intelligent use of CSS media queries, automatically switching to accommodate for resolution, image size and scripting abilities. Intelligent usage of CSS3 media queries and HTML5 allows the dynamic code to look at the capability of the device and re-architect the content. Multiple things are examined, including the screens height and width, along with resolution and orientation. There are a host of different methods for achieving this, including, fluid grids of objects, flexible images, and multiple CSS rules. Responsive design typically requires a much higher technical level of developer to accomplish properly, versus a typical non-responsive or dynamic serving web application.

Dynamic Serving Website

A dynamic serving website behaves very similar to having two separate sites from a development perspective. User agent detection is used to determine what type of device is accessing the content, and different data is then returned. Typically the default content to be served is content for a desktop, and if the server recognizes the user agent as a mobile or tablet one, specific data for that device is returned. This may be different CSS, HTML, or even Javascript. User agent detection is prone to mistakes, as the list of smartphone user-agent strings constantly needs to be updated, as the market changes incredibly quickly.

Responsive Design vs Dynamic Serving

Both of these methods makes it easier for users to share and link content with a single URL. Responsive design applications require less engineering time to maintain as there are not multiple pages for the same content. They are also less resource intensive on server, and less prone to error, due to not relying on user agent lookups. Finally, as new devices get released, updates do not have to be made. As for dynamic serving web applications, browsers don’t need to be as modern, and they don’t require as powerful client devices for CSS and JS.

Wrap Up

So…why do you want to know all of this? Well, understanding how your webpage is build, can give you a leg up on how to design your tests, and how to locally execute your tests, preparing for execution of them over multiple browsers and devices. What are some of the best tips and tricks for testing and debugging locally before you go to the cloud, or however you plan to test on multiple devices. The point is, it’s cheaper (time and money) to test locally – how can we do this? Tune in on October 1st to find out

Leave a comment

Your email address will not be published. Required fields are marked *