Quality Test Plan

A check-list for common website errors.

"...if quality costs a nickel extra, you quickly see the true colors of those who would have to shell out the nickel."
- Peopleware, Tom Demarco

It never ceases to amaze me how easily errors creep into the most rudimentary of websites. Even more stunning is that I’m often the culprit (e.g. I’ve almost launched a website with the word Melbourne misspelt as Melboure). You would think that after years of experience within the web realm, I should be getting better at it right? I guess its a bit like taxi drivers, because they spend most of the day on the road, you would assume they would become excellent drivers (we all know that isn’t the case). Whatever the reasons behind these common errors, it’s a given that they will be there, so if you know this, what do you do? A Quality Test may be the answer you are looking for.

How is a Quality Test different to a System test plan? A Quality test is designed to check for basic mistakes common to ‘information driven websites’, mistakes such as; spelling errors, bad grammar, broken links, missing image ALT tags, etc. A System test plan is designed to check a web application for bugs. By ‘information driven website’, I mean your stock-standard web presence (e.g. a company website with sections like ‘About Us’, ‘News’, ‘Contacts’, etc). If you are looking for information on System Test Plans, please see the article Writing a System Test Plan.

One of the best things about a Quality Test plan is how easy they are to make (about 30 minutes or less for a 10-15 page website), there really is no excuse not to do them. The purpose of a Quality Test is to check for; script errors (e.g. a crash occurring on a fill-in form), usability best practice (e.g. showing the user what page they are on), and SEO (e.g. descriptive page titles).

The structure of the Quality Test is simple, its just a Word document where you list every front-end page of the website (i.e. anything which is going to be visible to the Internet public). As far as conducting the Quality test goes, I would recommend getting an independent QA tester to do it (programmers shouldn’t be used as testers). Any problems found during testing should be logged in your bug tracking system, assigned by default to the project manager who can then direct it to the appropriate programmer.



The break-down of the Quality Test document is as follows:

Page Title – you want to ensure each page has a distinct and descriptive page title (i.e. the title that appears in the browser bar). This has a very significant impact on search engine optimisation (e.g. ‘Products – Xbox 360 action pack’ is far better then just plain old ‘Products’).

Max. Data Length – this relates to the fill-in forms appearing on the website. You are checking that textboxes have had their ‘maxlength’ attribute set correctly. This is a danger because you may have a textbox called ‘Company’, and the corresponding database field may be set to hold a 32 character string. If a user was to enter ‘International Shipping Industries’, that’s 33 characters, enough to cause a nasty script error.

Hyperlink Check – you are just checking for broken links. I would recommend an automated tool like Xenu (there are also websites which will crawl your site looking for broken links).

Navigation Check – there should be some kind of indication of what page the user is on. Its very easy for a person to ‘get lost’ on a website, especially when many levels of sub-navigation are involved. Good ways to do this are to highlight the active navigation button and to show a big title on the page currently being viewed.

Image ALT Tags – at a minimum, pictures which aren’t related to the layout should have an ALT tag. This connects to SEO and usability. ALT tags like ‘Picture’ or ‘Photo’ are pretty useless, UI experts say you should put sentence-like descriptions. For example; ‘Photograph taken at base of Mount Everest showing light snow coverage’, but I can’t say I’m a big supporter of that, I would more likely go with ‘Photo at Mt. Everest’.

Spell Check – nothing smacks of unprofessionalism like bad spelling, and the real travesty is how easy it is to avoid. Copy and paste the site's text into MS Word, run the spell checker and you’re done.

Proof Read – checking for well formed grammar is a little trickier. For one, it requires someone with a good grasp of the English language, and secondly, it can be extremely time consuming if it’s a big site. There have been times when I have off-loaded this work to the client. Another alternative is to recommend a copy writer.

Browser Compatibility – an old favorite. Just when you thought your website is done, someone comes out with “hey, have you seen the navigation bar in Opera? Its all squished”. As to what browsers you should be checking, that is a matter of browser market share (e.g. check 2-4 of the most widely used browsers). As far as screen resolution goes; a few years ago we were checking at 800x600 pixels, now it is 1024x768 pixels, this will probably continue to increase in future.

Required Field Check – this relates to fill-in forms on the website. You are looking to see if fields marked as required are being checked by the system. For example, there could be a textbox called ‘First Name’ which the user must fill in. If they go to submit the form without entering their first name, does the system show an error message?



Can a Quality test plan be used on a web application in addition to a System test plan? For sure, and I would actually recommend it. The Quality test is so quick to make, why wouldn’t you. Some tests will seem odd though (e.g. checking for spelling and grammar), but chances are good it will still reveal a few bugs. A Quality Test is no substitute for a proper System test plan when it comes to web applications.