[thelist] Site Testing Procedures

[Lischke, Katherine L.]

Here's what we do for internal sites and one of our public sites. This 
isn't the "well documented" version - that's unfortunately company 
confidential information that I can't send to anyone outside the company. 
But here's the basic gist:

1. At the beginning of a new project, write a full list of requirements for 
the project. From the big picture down to the minutiae. Basically, state 
your requirements for the site with regards to checking images, links, 
usability, grammar, etc. ("Each page shall be test-loaded and the correct 
loading of all images in the page shall be verified.") Once you have this 
list, you basically have a test procedure - which is to go down the list 
item by item, noting any discrepancies.

2. Decide how many times during the development process you will be putting 
the site through its paces. Maybe you want to test once early, once in the 
middle, and once slightly before delivery. Maybe you only have time for one 
test and fix cycle near the end of the project. Whatever schedule you 
believe you will have time to stick to.

3. Create a database where you'll log each of the discrepancies you find as 
you go through the site following your test procedure. You can throw in all 
sorts of bells & whistles here, giving each bug a seriousness rating, 
assigning bug fixes to specific people, estimate how many manhours it will 
take to remedy each bug, etc. One of the most useful bell and/or whistle 
you can include in this database is a field where the bug fixer can note 
what the fix was. That way, if the problem was difficult to solve (let's 
say a relatively complex perl script or javascript had to be written to 
achieve desired functionality) and might come up again, you'll have the 
solution sitting in the database, and your employees won't have to 
re-invent the wheel.

4. Using the information in your bug database at different points in 
development, you should be able to see potential problems. Mistakes that 
keep getting made over and over, possible schedule overruns, etc. Your 
database will not only help you make sure you fix all the bugs you found, 
but it will also serve as a log that will help you fix future problems 
before they happen. You'll see patterns: things you can fix with more 
training, more planning, etc.

Good luck. Quality assurance can be a rough road. :)

Kathy

At 02:25 PM 3/20/01 -0500, you wrote:
>Greetings,
>
>I've just been tasked with developing a site testing (spelling, grammar,
>functionality, broken images & links, useability, etc.) process for our
>shop. We're currently severely lacking in this department, the consequences
>of which are forcing us to miss deadlines and ultimately deliver a product
>containing bugs...Many of which are found by the client.
>
>Is there a solid, well-documented testing process that any of you use for
>your sites, or one that is documented somewhere on the web?
>
>Any help would be greatly appreciated!
>
>Alan McCoy
>amccoy at altairtek.com