Testing Your Site

In this lecture I want to cover issues surrounding testing your site and multimedia creations.

Testing is an important stage in making sure that your site is correct.

Errors are good!

The first thing that I want to say about testing is that errors are good.

I do not know a single person who doesn’t make mistakes especially mistakes when creating computer based applications / media.

If you create a system and tell me that you tested it and found no problems I simply won’t believe you.

There is always something wrong with your work at some point in the design.

If it isn’t an actual fault then there will always be something that could have been done better.

We test to find errors and they will exist, therefore we need to find them!

In documenting your testing I expect you to state clearly what errors you found and what you did about them in your test logs.

If you have tests with no errors and no resulting changes to your system, your test strategy is simply flawed.

When to Test

Testing that is carried out prior to the release of the site is called formative testing. Testing carried out after the site is complete is called summative testing.

Formative testing directs the design of the site as it is in development. It guides the design process to keep it on track.

Summative testing takes place after the project is live and could be the source of some embarrassment as problems that should have been found at an earlier stage come to light.

Summative testing does have a place should one go to the trouble of evaluating similar sites already out there.

Imagine a chef making soup.

The formative stage is the chef tasting the soup as they make it.

The summative phase is when the customer tastes it.

In the design process described in these lectures testing should take place at all stages of the design process.

Problems that are identified early on are much less costly than problems found after the site has gone live.

Why do we test?

The most obvious reason to test your site is to find faults or errors with the code. Broken links and code that contains bugs both need resolving before the site goes live.

However, because the suitability of our multimedia systems may be open to interpretation we need to be very careful that our design is suitable for the user.

You may create a multimedia interface that looks perfectly fine to you as the developer however it fails when placed in front of the customer.

Why is this?

One problem is that as the author of your system you know it back to front. You know where everything is and what buttons to press to perform different tasks. Youwill inevitably be an expert on your own design and as a result find it hard to imagine what it is like to approach your design for the first time.

We need to have our designs viewed through fresh eyes to see the things that are hard to see ourselves.

What do we test?

As stated above, we need to test the code that makes up our system however we also need to test other aspects of the system that may be harder to identify than a broken link.

We need to find some way of establishing the following points.

Does our system provide “ease of use”?
Is our system accessible?

For the sake of this lecture I shall split testing into three types.

System testing
Accessibility testing
Usability testing

System Testing

There are a number of issues that need to be considered under the heading of system testing.

You will need to consider issues such as the following.

Is your code correct? Validation – broken links?
Does your design work on different browsers?
Does your design work at different screen resolutions?
How does your design behave on different computer platforms?

Is your code correct?

Dreamweaver provides you with a number of tools that assist you in validating and fixing your HTML.

Dreamweaver allows you to validate your HTML by pressing Shift + F6.

You will get a report like the one below.

If you double click the error Dreamweaver will take you to the place in your HTML containing the error.

In this case the body tag has been typed using capitals, only lower case tags are allowed in HTML.

Another useful tool is the link checker shift F8. (ctrl F8 for the whole site)

Pressing it will list broken links like as shown below.

As before double clicking on the entry will take you to the error and allow you to fix it.

IMPORTANT! Try your links on a computer logged in as a different user!

If you are always logged on as yourself when you use your site you won’t spot errors such as the one below.

<a href="page3.html">This is linked correctly</a>

If you are not in the habit of using the site manager correctly you may have created a link via the file system!

Cleaning up your HTML

Another useful tool in Dreamweaver is “clean up HTML”.

This tool will check your pages and where possible correct any errors it finds in your mark-up.

A rather more sophisticated tool is the reporting tool. This tool may be configured not just to check a single page but the entire site.

It performs the following tests on your page / entire site.

The work-flow reports give you statistics on who has done what to which pages, e.g. who has edited what page and when.

The HTML reports give you reports on the design of your pages.

Accessibility This reports possible problem areas for people with disabilities.

Missing Alt Text Lists images lacking a suitable alt tag.

Untitled Documents Identifies pages that don’t have a title.

The last test you should perform on your pages is to spell check them using shift F7.

Note the default spell checker in Dreamweaver is an American one. Change it to British via the preferences.

Once you have tested your site within Dreamweaver you need to then test it in as many different environments as possible.

You need to consider the following points.

Different browsers. (Internet Explorer, Firefox, Opera)
Different Screen Resolutions (Design for liquid layout, use percentage values in positioning)
Different operating systems? (PC, MAC, Unix)

Testing Your System on Different Browsers

There are a many browsers available on the market.

The following pie chart indicates browser usage for the faculty dated 19th Oct 2008.

So what is the problem?

Sometime during the 1990s an event took place called the browser wars.

In 1993 the most popular browser was a platform called Mosaic.

In time, other browsers appeared on the market for example Netscape.

Netscape at one point grew to be a hugely popular browser. In order to undermine Netscape’s position, Microsoft decided to give away Internet Explorer free of charge. (You had to pay for Netscape.)

In addition to giving the software away for free to achieve mass acceptance, browser manufacturers started to devise their own versions of HTML.

Although HTML had been created by Tim Berners-Lee it didn’t quite do what people wanted it to do as the demand for new features grew.

A good example of this is the marquee tag.

The marquee tag creates a section of text that scrolls across the page.

This is fine if you had Internet Explorer but wouldn’t work in Netscape.

This pressure from companies to redefine the web in their own image meant that there were lots of different variations of HTML which were not guaranteed to work on all browsers.

The other issue is that HTML is a mark-up language and is not very good at specifying presentation. This limitation in presentation leads to the introduction of Cascading Style Sheets.

The World Wide Web Consortium

"W3C primarily pursues its mission through the creation of Web standards and guidelines."

This is the place to go to find out if the HTML you produce is any good.

Resolution Testing

At the very least you should see what your site looks like should you reduce the size of your browser window.

The computers at the university have unusually large displays. Try to create a “liquid layout” for your pages that uses percentage values for the positioning of screen elements.

One easy way of doing this is to use Dreamweaver’s built in templates.

How to change the resolution

To change the resolution, from “control panel” select “display” and “settings”.

This will give you a screen allowing you to change the screen resolution. (You won’t be able to do this on the university computers!)

Test your site at different resolutions to see how it looks.

Accessibility

Designing for Accessibility

Accessibility relates to how many different types of users may access the content of your site.

When creating your pages remember that some people may use technology other than a screen to "view" your pages.

A Braille Reader

Your wonderful new web site may look great to the eye but turns into a very different creature when your site is put through a speech synthesizers or Braille device.

Below is a selection of some accessibility guidelines.

The web accessibility initiative will provide more information at the following address.

Guideline 1: Provide equivalent alternatives to sound and visual content

This guideline emphasizes the importance of providing text equivalents of non-text content (images, pre-recorded audio or video).

So for example if you have a picture on your site, make sure that there is a text description.HTML insists that you set a value for the "alt" attribute when displaying images.

Do all of your images have an alt tag?

Guideline 2: Don't rely on colour alone

Ensure that text and graphics are understandable when viewed without colour.

Similar colours are hard to differentiate if viewed on black and white equipment.

People with colour blindness won't be able to see text in certain colour combinations.

Find out how your site looks to a person with colour blindness.

Does your site work without the colours? (Rename your style sheet to test this.)

Guideline 3: Use mark-up and style sheets and do so properly

For example, don't use a table to layout your document.

Only use tables to represent tabular data!

Have you used tables to lay out your pages? Is there a better way?

Frames are a complete no-no!

Guideline 7: Ensure user control of time-sensitive content changes

Allow users to freeze moving content, avoid movement in pages.

If you have animations can the user stop them?

Guideline 11: Use W3C technologies and guidelines

Many non-W3C formats (e.g., PDF, Shockwave, etc.) require viewing with either plug-ins or stand-alone applications.

Can you still navigate your site if your flash buttons don’t work?

Guideline 13: Provide clear navigation mechanisms

Provide clear and consistent navigation mechanisms -- orientation information, navigation bars, a site map, etc. -- to increase the likelihood that a person will find what they are looking for at a site.

Do you have a consistent layout for your pages?

Usability Testing

What is Usability?

Usability may be defined by the following questions.

How easy is the site to learn?

How quickly are tasks performed?

How easy is it to remember how to use the site?

How many errors does a user make?

Is the user satisfied with the experience?

Who to use?

You need to locate potential users of the site and obtain their feedback.

How many test subjects?

It has been suggest by Jakob Nielsen that you only need five test subjects. The argument states that after five users you will end up watching the same mistakes being made over and over again.

To find out more visit the following page.

His argument is based on a position of cost versus benefits.

One point however is that testing zero users gives you zero insight.

Approaches to Testing

Focus Groups

A focus group may be of value in comparing two different approaches to the design.

“Would this site be better structured using a hub and spoke navigation model or a linear one?”

Testing the Paper Based Design

This test would involve potential end users being given a paper based design and allowing them to pretend it was on the computer.

How would they imagine the system would work?

What changes would they make to the site?

The test would be observed and notes taken by the subjects and the observer.

Card Sorting

May be used to identify an organisational scheme.

Write down on file cards the names of the sections of your site with a short description.

Give the cards to different potential users and ask then to sort the cards in a way that makes sense to them.

For more details follow the link below.

Design an Experiment

In this case potential users are given a task to perform.

For example locate a product, add it to the cart and then proceed to checkout.

The task is observed, timed and both observer and subject make notes on the performance.

Planning Test Scenarios

It isn’t good enough to simply ask a user to “find something and see how you get on”.

For a test to provide worthwhile data a test scenario is required.

For example

Find a pair of men’s trousers in black for less than £25.

Make sure that the user starts at the home page and all data is in an initialised state.

Screen recording software (CamStudio) could be used to record the test and observe the results at a later date.

A web cam could be used to observe the users expression.

Avoid Polluting the Test

One problem you must take into account is that the behaviour of a user may change when they know that they are being observed.

There is evidence to suggest that people work better because they are under test conditions.

The tests should try to be as much like real situations as possible.

This obviously means that if a person gets stuck using your web site you must not jump in and help them!