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.

Writing a System Test Plan

Using a test plan to ensure your software really works.

"Extraordinary quality doesn't make good short-term economic sense."
- Peopleware, Tom Demarco

Imagine for a moment you’ve just finished a web application for a client. Swimming around within that application is 100 bugs. What proportion of those bugs would you say is acceptable for the client to find (e.g. 50, 30, 10)? The point is, those bugs are going to be found by someone, and its either going to be you or the client. You can think of it as a sliding scale, the more bugs the client finds, the more your creditability suffers and the more damage you do to the business relationship.

In the martial arts there’s a saying; “expect the best, but prepare for the worst”. The US Navy Seals have a slightly more gun-ho version which goes; “The more you sweat in training, the less you bleed in battle.” Notice how it says the ‘less’ you bleed in battle, implying that if you enter into combat, you are going to get bloody. Software development is like this too, if you’re going to create software, you are going to get bugs.

As a rough guide, you want to try catch at least 80% of all bugs. Ideally, you would go for 100%, a worthwhile but lofty goal. Your best bet for catching as many bugs as possible is to create a system test plan. Creating a decent system test plan is easier said then done. A good place to start is your functional specification (assuming you have one). In effect, your specification gets converted into the system test plan. What you are doing is checking to see if the things you said you were going to do have actually been done.

A test plan is nothing new, in fact, the structure I use was developed by Microsoft years ago. It’s a simple format, a test case has a title, some steps, and an expected result.



I write my test plans with the intent of having an independent QA tester run through it, so no prior knowledge of the system should be assumed. You want someone who has never used the system before because they will take a fresh approach. You’re counting on them to use it in a manner which was never intended (e.g. on the ‘My Profile’ page, they type in a really long name for the ‘Company’ field and crash the system because the database only has room for a 32 character string).



You should keep your test cases short, to the point, and self contained (i.e. they generally don’t link to other test cases). If you have a test case that goes over a page, consider breaking it into smaller units. The document itself should be self contained as well, that is; it shouldn’t require the QA tester to get up and ask programmers questions like “what’s the login password?”. Instruct your QA tester to log any bugs they find in your bug tracking system and also to write a proper description rather then just saying “Test Case 16 failed.” You may want to read my article on Logging Bugs Like a Pro for some suggestions on good bug logging practices.

Article reviewed by Alex Barclay.