Best Practices for Website Testing

Ten years ago, building a website was much easier than it is today. 88% of all internet users used Internet Explorer, 90% of all Internet users used a Windows platform and 87% of all users viewed the internet on one of two different window sizes. Things were much simpler then.

Today, there are four versions of Internet Explorer alone to contend with – plus three other major browsers that have significant market share: Chrome, Firefox and Safari.  Even less popular browsers, like Opera, are making a big push to be relevant.  To add to the complexity issue, each browser handles HTML and CSS in unique ways, creating headaches for web developers worldwide.

To add to our ever-expanding menu of choices, Internet users can now choose between seven different operating systems – four of them being different versions of Windows. Users can view the Internet on screen sizes from those that fit in their pocket to screens that are the size of TVs. There are more than 3,000 different smartphones that are built for mobile browsing – an activity that barely existed in 2002;  today, the average American spends 115 minutes each day on their mobile device. In fact, research shows that 25% of all Internet users access the Internet only using a mobile device.  My, have things changed!

The challenge?  With all these choices – browsers, operating systems, devices and screen resolutions – a single page on your website can be viewed hundreds of different ways.  So how do you know if your website is being viewed as it was originally intended?

The answer: test it.

Why Test?
When it comes to your website, there is no such thing as too much testing. When we develop websites, we test before, during and after the build. We have a dedicated quality assurance team, QA Engineers and a systematic process for testing.  In this article, we’ll explore best practices in testing a website across browsers, operating systems and devices.

Step 1:  How Will You Communicate?
Determining how you will communicate your testing results is your first order of business. Here’s the process:

1.  Find problem.
2.  Show problem to developer.
3.  Developer fixes problem.
4.  Developer confirms problem is fixed.
5.  Re-test to make sure problem is gone.

Sounds easy until you need to do this for an entire website.  Communicating to the developer, tracking changes and testing fixes can eat up days and weeks of time if it isn’t organized.  Plus, without a good process, you could miss problems that end up on your live site.

Best Practices in Communication
Placing screen shots in emails is definitely one way to communicate bugs, errors and fixes to your web developer. But that eats up lot of time for the tester, plus it causes massive organizational issues for the developer. It becomes even worse when you are testing with multiple testers and multiple developers. On top of that, tracking the completion of issues is not easy at all.

The next best thing is to use a group sharing software like Google Docs, which that allows any number of users to input and view information using Microsoft Excel’s formatted layout. This can help you stay organized when there are a few people involved, but this method still requires a ton of manual entry.  Items can still be (easily) missed.

We’ve found that the best course of action is to utilize real-time communication software that will mark, track and record all issues found during the testing phase. This is, by far, the most effective tool we have found to test and communicate our findings to our development team.  Using specially designed website testing software that can be implemented on your live website has been proven to reduce testing time, increase productivity during testing, and reduce the chance of missing items marking for correction.

Our recommended website testing software is BugHerd.  BugHerd is an easy-to-use web-based website testing software that allows a tester to tag comments directly in a browser and delegate tasks to a developer.  Once a comment is tagged in BugHerd, the developer is notified by email that there is a required fix. After the fix is made, the developer marks the task completed. BugHerd notifies the tester that the task has been completed so that he can go back in and re-test.  It even tracks changes and the time it takes to make a change, provides useful information to the developer (like browser and device where the error was seen) and provides insightful data that may be used to improve development speed.

BugHerd Screenshot

Step 2: Check Your Browsers
Browser testing is usually the first thing we tackle when testing a website or web application. As of March of 2013, only 2.3% of internet browsing is done on a mobile device. So even though that is very important, the bread and butter of your website is going to be desktop or laptop users.

Remember this while testing: you aren’t just making sure pixels are aligned, links have hover states and that contact forms send the correct information. You are also the first person outside of the web developer to go through the site. So keep this basic rule of thumb in mind: if YOU don’t understand something while you are on the website, if it doesn’t make sense or doesn’t work for you, then it will probably confuse or frustrate your end users.  Since we don’t want that,  flag the issue – even if it’s minor – and ask the developer for their input. Even when you have a team of UX strategists, interactive designers and web developers, not every little detail is going to be 100% perfect until the code is written and online.  The best plans can change during a months-long project. Remember: it is your job to ask “why?”.  Advance fearlessly, young tester.

Best Practices in Cross Browser Testing
We prefer to start initial testing in either Chrome or Firefox. This allows us to view the website in one of the two most utilized and powerful web browsers, and it gives us an excellent “baseline” browser experience from which to start. Before we start testing  a site, we need to have two pieces of information handy.

First, grab the sitemap or webtree. These documents show the architecture of the website. As a tester, you’ll need to know what pages should be on the website and how the user will navigate to them. Understanding the layout and main navigation of the website makes things so much easier, especially if the site being tested contains deep content or has alot of pages.  A proper webtree shows relationships between pages, URL names and navigational hierarchy.  Use this as your roadmap.

The other items I look at before I test are the approved wireframes and design files. These are important reference documents.  Typically there will be a file for the homepage and multiple files for the different internal page layouts.  Wireframes note layout, structure and can even show functionality.  Your web designer should understand how a website should be constructed and the limitations of the Web, but even in a perfect world there will be times when a design cannot be perfectly replicated when it is coded. This occurs due to the limitations of a certain browser or limitations of the Internet in general. It is your job to make sure every image and feature of the site is aligned based on the approved design, but in some rare cases, this just won’t happen.

Once you have the reference documents, start testing the website, noting any inaccuracies from the coded site to the webtree, concept art and wireframes.  After your testing is complete in one browser, move on to the next browser using your baseline as the new comparison. If the website in the second (and third, fourth, etc.) browser you’re testing doesn’t match the site in the baseline browser, flag it and ask the developer to fix it. Repeat until you’ve tested the site in the four major browsers (IE, Chrome, Firefox and Safari) and their iterations (like IE 8, IE 9 and IE 10).

A Note About Graceful Degradation
When testing across different browsers, you will likely come across cases of graceful degradation. In its purest definition, graceful degradation is the concept of designing webpages that can be viewed properly and fully functional despite limitations imposed by legacy browsers or browsers that rely on older technology.  It also handles variations in how the different browsers handle certain commands.

You’ve probably seen graceful degradation on a website, even if you didn’t know it by name.  Below is an example of how a default “Chooses File” button will look on the same website, but across different browsers. As you see, they are all different but function the exact same way.

Examples of Variations of the Choose File Command Among Standard Web Browsers and Operating Systems

The most important thing to remember about graceful degradation is that with it, users will recognize the functionality of the item based on what they are used to seeing and using. Understanding (and accepting) that browsers handle certain CSS styles and commands in different manners will not reduce your testing time – it’ll help you keep your sanity, too.

Step 3: Cross Device & Screen Resolution Testing
Like anything in life, you have to have the right equipment to complete the job. The same goes for website testing. In order to accurately test a website, you’ll need access to the hardware and software that web users use for browsing.

Web browsing in today’s world consists of users viewing websites in many ways: a PC with dual 23″ monitors, a MAC OS  laptop with a 13″ screen, iPads, phone/tablet Franken-devices (or, phablets, as they are known) e-readers and thousands of different smartphones.  Now, before you go out a purchase a ton of devices, be aware that there are emulators and virtual software programs that allows you to view your website across different devices and in different screen resolution. Simply search for the operating system or device emulator you would like and a multitude of websites with those programs to download will appear. But when you can, I would always suggesting viewing your website on the real thing because emulators simply aren’t exactly like the real thing.

Testing on Desktops and Laptops
Testing on desktops and laptops testing should be fairly easy since this hardware can be found in more homes and businesses. Testing different screen resolutions for different laptops is as easy as reducing the window size on your desktop. This can be done without the need of an actual laptop because these devices run the exact same operating system as desktops; however, this doesn’t apply for mobile devices.

Tip: Try BrowserSize or Resize My Browser for an easy way to quickly set your browser window to a different size.

Testing on Tablets and Smartphones
Simply reducing your window size to 768×1024 or 480×320 is not going to give you an accurate depiction of what your mobile device user is really going to see. Mobile devices run on different operating systems than desktops and often feature different screen resolutions, causing tablets to display webpages differently than their similar-sized cousin, the laptop. Again, try to test your site on the actual device if you can. When testing a site on your device, remember to test every page from both the landscape and portrait views. There are no hard statistics proving which orientation is more widely used, so make sure that both are tested. If the webpage is too difficult for you to read or a link is too small to click with your finger, then there is a good chance your users are going to be frustrated, too.

Keep in mind that different devices use different mobile browsers, and all need to be tested to ensure continuity. Apple products have Safari as their default browser; Android devices ship with the Android Browser installed; and Windows phones have a mobile version of Internet Explorer on their operating system. All these devices can also download browser apps from Chrome or Firefox.  We always start mobile testing with the native version of the browser associated with each device, since these browsers will be the most used.

The graphics below show mobile browser usage and standard screen resolution sizes for popular mobile devices. You can use this information to make decisions on which browsers and screen resolution sizes to test for your site.

Mobile Browser Usage, May 2013

Screen Resolution and Sizes by Mobile Device Type

A Final Note: Make Testing Part of Your Plan
As you can see, testing your website across browsers, devices and operating systems can be a lengthy, involved process – yet it is a critical step that all websites, mobile apps and web applications must undergo. Save time (and money) upfront by making the testing process part of your website development plan. Many times we’ve seen that the testing process is not planned upfront because there is so much time put into the look and feel of the site. You have just spent the last few months designing your site, writing content, gathering images and making decisions regarding technical aspects, so adequately planning a testing phase usually isn’t at the top of the priority list. If you skip it, however, be prepared for many headaches down the road.

So, how long does testing usually take? A general rule of thumb based on a 30 page website:

• 8 hours of testing for baseline browser
• 4 hours for cross browser testing in one browser
• 2 hours for cross device testing per device/screen resolution
• 1 hour of testing per form
• Add time for edits and re-testing
• Add time for testing of special applications and databases

Using this example, setting aside 35-50 hours to test a 30-page website is just about right.

Need Website Testing Help?
Worrying about website testing is a thing of the past when you partner with Synapse. We check every website we build in every browser, device, operating system and screen resolution to ensure 100% client satisfaction.  Our Interactive and QA teams boast more than 150 years of industry knowledge and “in the trenches” expertise in web design, website development and website testing. Combine that with our extensive testing process and library of 245 testing devices and browser combinations, and you’ll see why Synapse is the partner your company can rely on. Synapse has tested and launched hundreds of successful websites, mobile apps and web applications. We take pride in our industry knowledge and our ability to solve issues before they get to you (or your users).  Our goal is to make your life easy!

Have a question or website testing quandry? Leave us a comment below.

Ready to put Synapse to the “test”? Start a Conversation with us.