Website Quality Assurance for Beginners

We've all been there, jolted out of our sleep at midnight by a phone call from an angry client: "You just launched my website yesterday and the Contact Form is broken!"

Yikes! How did that happen? Didn't you test that before it went live?!

Chances are: maybe.

It's been our experience that, although everyone knows the benefits of good QA (quality assurance), and everyone knows too well the pain of its absence, testing can often receive too little attention during website development. There are many reasons — compressed schedules, delays during development, lack of resources, you name it — but none justify giving QA the short shrift; it's just too crucial to project integrity, user experience and client relationships. When done right, QA actually makes website development easier, and saves the hassle of fixing things when it's too late, too time-intensive and too costly.

Even though it might seem like rocket science, QA is actually fairly easy to implement, especially if you begin at the beginning of your project.

Specifications Documents
We all know that good websites require a lot of planning and documentation. This means more than a "site map" or "flow diagram," but, at minimum, a complete set of annotated wireframes. There should be a wireframe for each distinct page of your site, and the annotations should include, or refer to, every type of content, feature and functionality of the page.

• What are the links on the page and where, specifically, do they go?
• If the page contains a form, what are the fields, options and actions of the form?
• If the page content is dynamic, where does the content come from and what are the conditions under which it changes?

It's very important to answer every question you might have about a page in as much detail as necessary. This not only enables everyone to build the pages correctly, it also provides the information you'll need to test properly.

Test Plans
Once your documents are in order, you can plan how you'll test the site. Good testing is more than "banging on it till it breaks" — proper testing follows a systematic approach to resolving issues. Using the specifications documents, you can design a plan to test the different components of your site so that you get specific feedback for all issues. A simple plan might be:

1. Proof all graphics prior to build-out.
2. Proof all copy prior to build-out.
3. Test all links, including those in navigation, body copy, callouts, footers, etc.
4. Check all graphics to make sure there are no issues.
5. Proof all copy again.
6. Submit all forms and check for appropriate results, including error messages.
7. Have Clients and Test Users run through the site at-will.

It's important to go through each step as a "cycle," testing only for the issues pertaining to that cycle, and repeating the cycle until no more issues are found.

Test Scripts
While the above plan might be just the ticket for your project, how will you ensure that your testers do the job correctly? This is where test scripts come in. At its most basic level, a test script is simply a set of instructions defining what will be tested, how it will be tested, and what the desired outcomes should be. Your test scripts can almost be lifted directly from your specifications documents (assuming you've done these in enough detail). A very simple test script might be:

1. Complete the Contact Form, including First Name, Last Name, Email and Comments (all fields are required). Result should be Thank You Page (includes Email in body copy).
2. Submit Contact Form and omit one or more fields each time. Result should be same page (refreshed) with an Error Message for each omitted field and RED CHECK next to each.

The Testing Team
The number of people who test your site will be determined by time, budget and availability. However, you should keep a few things in mind:

1. The people who build the site shouldn't be the only ones testing it (they're too close to things and will invariably miss issues).
2. The people who fix problems should have their work checked by the people who found, or are managing, the problems.
3. It's best to have one person responsible for overseeing the entire QA process.

The Testing Process
During each testing cycle, your team will go through a particular process which, at its core, goes like this:

1. The Tester reports a bug to the Project Leader.
2. The Project Leader determines if the report is valid, then assigns it to somebody to fix.
3. The "Fixer" fixes the bug and assigns it to someone who checks the work (often the Tester).
4. The "Checker" determines if it's fixed properly and, if so, alerts the Project Leader that the issue is resolved.
5. The Project Leader "closes" the issue.

Keeping Track of Bugs
It's crucial to keep records of your testing cycles to assure all issues have been attended to — and to maintain your sanity. A good tracking system will help you manage the process of assigning bugs and tracking the progress of repairs. There are many tools out there, running the gamut from free to costly, from simple to overly-complex.

BugSherpa to the Rescue!
BugSherpa was developed specifically specifically for small web boutiques (though it's scalable to much more complex environments). It's sure to fit your team's — and project's — needs.

Conclusion
So now you know enough to get started. Armed with excellent specifications documents, a solid test plan, well-crafted test scripts and a devoted testing team, you're ready to take on the world of Website QA. And you'll never again be awakened at midnight by an angry client (well, at least not because your QA process failed).

Ready to get started? Sign Up for BugSherpa now!