Tunnel 7 | Podcast | Episode 6: Testing

Podcast

Episode 6: Testing

Published on Dec 17, 2008

In the previous five episodes I’ve been talking about the different elements that go into building a successful website. Today’s episode continues this series. Now, if you’ve missed any of the earlier episodes please check them out on the podcasts page at tunnel7.com.

Like I mentioned last month, you should be getting the picture that a website project is built layer upon layer and each layer is very important and builds upon the other. As I like to say, building a website is like building a house. A weakness in any component will cause the finished product to suffer. Today the component we talk about is testing.

Why do we need to test a website?

It is not uncommon for me to get this question when meeting with clients. And it’s a fair question. Why do we need to test a website? At this point I usually like to answer that question by making a comparison.

When people think of designs they tend to think of print pieces - catalogs, brochures, newsletters and the like. What is it that all those print pieces have in common? Go ahead. Think about it. For those of you who answered a controlled environment you get a gold star. Print pieces, unlike websites, are produced in an environment the designer has complete control over. He or she knows the paper the design will be printed on, can specify the color inks to be used and generally has complete control over the finish product. Each piece will look identical and everyone will see it the same way.

Now let’s consider a website. Do we have a controlled environment? Go ahead. Think about it. For those of you who answered no you also get a gold star. Because websites can be viewed on any number of operating systems running any number of browsers with screen resolutions that will vary greatly from machine to machine, we as website designers need to test to accommodate all these possibilities.

If you’ve ever seen a website that doesn’t work correctly or has a layout that appears broken or just plain doesn’t work in your browser you really have the answer to the question why do we need to test a website? It’s to avoid all of these things.

When it comes to website testing I tend to organize my tests into two general categories - website functionality and browser compatibility.

Testing website functionality

If we carry the print versus web comparison a bit further we will quickly realize the other component that print pieces do not have that websites do. Anyone? Go ahead. Think about it. For those of you who answered interactivity you also get a gold star. (And I promise not to use this annoying little Q&A mechanism again.) Websites are interactive. At the most basic level this could be a click on a navigation button that takes users to a new page, checking for broken links or a general contact form where users can submit information that then gets sent via email (or entered into a database). At more advanced levels it could be a member login where registered users receive additional content that non-members don’t or a forum or a wiki or some other format where users actually contribute content to the website.

All of these items, whether basic or advanced, require testing to ensure that the expected action or behavior actually happens.

When testing for functionality, in many cases I’m actually attempting to break the website. Why? Because if I can find something that will cause the website to fail then so will visitors to the website. I want to find those things before they do.

Let’s use the example of a basic website form. When testing such a form I do things like enter a lot of special characters into the form to see if it still functions (special characters have special meanings in programming languages that can affect form processing). I leave required fields blank to see if I get logical error message telling me to complete the required fields. I’m also checking to see if that form data is being received properly (either by email or entered into a database). If any of these tests fail it then becomes a matter of determining why the failure happened and revising code to fix it. Is it tedious? It sure is. Is it essential? Absolutely.

Consider the alternative for a moment. Company A builds a website whose sole goal is to generate leads from the website through a contact form (much like the one we just discussed). The website gets built and launched with minimal or no testing of this form. After all, everything “looks good”. Six months pass and Company A realizes that they haven’t received a single lead from the website. Upon closer inspection it turns out that every time someone submits the form they receive a message politely thanking them for contacting Company A and a note saying someone will be in touch with them soon. However, Company A never receives the results of this form. Somewhere along the line there is a failure that was never caught because it was never tested properly. Company A not only doesn’t know how many submissions they’ve missed but has no way of reassuring those people who did complete the form and who, by now, have turned to Company B for their needs.

Does this sound far fetched? It shouldn’t. I can’t tell you how many times I’ve heard a story just like this. Functionality testing of a website eliminates this possibility and it should never be overlooked.

Testing website browser compatibility

So we’ve established that with websites we don’t have a controlled environment. Here at Tunnel 7 world headquarters I have a Unix machine running the Firefox browser, a Mac running the Safari and Firefox browsers and a couple of PCs that run the following browsers: Internet Explorer 6, Internet Explorer 7, Firefox, Opera and Chrome (Google’s new browser). Now I don’t mention this to make myself sound schizophrenic. (For the record I have one primary machine I do most of my work on. These others are testing machines. ) I mention this to illustrate all the different testing environments I have here to pinpoint any issues that can crop up with a website. Only by viewing a website in all these different environments will I be able to identify any bugs that remain.

Now you’re next question may be this: don’t all browsers work the same way? Ah, if only that were true. They don’t. Each browser uses a different engine that will render the code that makes up the website differently. You may recall that last month I talked about validating website code. Now I’m not going to go into much detail on the subject here (see last month’s episode for more) but as website designers we validate our code to ensure there are no errors in it. Having coding errors will nearly always create browser compatibility issues. However even 100% correct and valid code will render differently from browser to browser.

Let’s look at a real world example. Just this morning I was testing a project I’m finishing up in all the different browsers I mentioned above. I noticed that in Internet Explorer 6 a search button at the top of the page was twice as wide as it should be. It looked perfect in all other browsers but it looked awful in Internet Explorer 6. I had to go back into the code and make a revision specifically for Internet Explorer 6. However, had I not conducted a thorough browser compatibility test I would never have seen this issue. The visitors to this website would have seen it and it would have reflected very poorly on my client (and on my work as well). Not a good situation.

Just like functionality testing, browser compatibility testing should never be overlooked in producing a website.

Conclusion

Website testing is a no less critical component then any of the other items we’ve talked about over the past several months. Testing is a requirement simply due to the nature of websites. Unlike print pieces, websites have no controlled environment (they can be viewed on different operating systems running different browsers) and they are interactive. As such, websites need to be tested.

Without testing a website runs the risk of not functioning properly when users interact with it and/or not rendering properly in different browsers and operating systems. This will reflect poorly on the website owner and have real negative impacts to the success of the website.

Is website tedious? It sure is. Is it essential? Absolutely.

Download Episode 6: Testing (.mp3)