Thread Intelligence Article

December 11, 2003
By Julie Price

The web is a powerful medium, through which any person or organization can publish its message for consumption or use by anyone who has access. Part of the value of the web is that content can be easily modified or added to as a message grows or changes. However, the downside to this non-permanence is the idea that the message or site does not need to be perfect before it is presented to the intended audience and participants. This is not a productive school of thought. We must realize that a website should be treated similar to any other marketing or informational piece and thoroughly reviewed for correct content and functionality through formal quality control procedures.

Test plans
The creation of a test plan for website quality control should accompany the initial website plan itself. For instance, if a contact form is part of the site, a plan on how to test the form can be easily prepared at the same time the contact form is added to the site layout. The integration of a site layout and test plan is beneficial to ensure that the plan consists of all site pieces and functions. Attempting to create the test plans after the site is built allows for error and is not a reliable approach for a formal testing plan foundation.

Along with test case development, there are also quality control tactics that are used as site development progresses. For instance, after a page is programmed, quality control personnel can review the page for content and functionality. The client is also an integral part of quality control as the site is developed. The client knows their business better than anyone and can review the different pages and sections along the way. Waiting until development is complete is not the best time to begin quality control efforts.

Quality Control Personnel
Who should be testing the website? The client? The development team? A third party? The answer is, "Yes, to all three." Quality control personnel should consist of the client, the development team members and other personnel who are not involved with the creation of the site. This ensures that the site is reviewed by a variety of different people who have different relationships to - and expectations of - the site.

The client's involvement in quality control is critical, as they know the content of the site. Similarly, the development team knows the construction methods of the pages and sections and can best test the function. Additional personnel who are not involved in the development of the site bring value in that they can view the site with fresh eyes as opposed to the client or development team who know the content and structure.

Part Testing and the Test Drive
When developing a website, there are many parts that need to come together at the end of the development to make the site whole. However, quality control can be done throughout development to ensure a quality end product. The development team can check the parts/pages as they are developed. Just as parts of an automobile are tested before they are put into the final product, the pages of a website should be checked one at a time as they are developed.

Once all of the pieces are in place, the site is ready for a test drive. Start with the first page or section and scrutinize each page. The test plan that was created during the site planning process will assist in making sure that a methodical quality control procedure is followed. The plan should guide quality control personnel through the process of clicking on all of the links, viewing all of the graphics and trying to use all of the functions that the site is supposed to perform. Here again, a comparison to test driving an automobile can be seen. A test drive of a vehicle is usually done so that the buyer can see if it performs to their satisfaction. Therefore, before a website is launched, it should meet with the approval of the parties performing the quality control.

Bug Reporting
As the site is tested, there will be errors that are found that need to be fixed. If a formal test plan is being used, the document should provide an area where the errors can be typed or written in. A number of items are required from the testing personnel when reporting an error or bug. The first is an explanation of what the error entails. For instance, if a link does not work, the name of the link that is not functional should be provided along with a statement that the link does not function as it should. Second, the page name, URL and the place on the page where the error occurs or can be found should be provided. If the site or section being tested is dynamic in nature, an actual page name or URL may not provide enough information about how to reproduce the error. In this case, a list of steps on how the error came about should be provided. For instance, if the error is found in a site search area, the steps might be as follows:

1. Went to site search area on home page
2. Entered the word "building" in the search box
3. Clicked once on the "Search" button
4. Error message received that states the following text: "Page not found"

The documentation of bugs in the test plan document is very important, both so the developer has written evidence of the bug, and to assist the tester. Once a bug is reported as resolved by the developer, the tester needs to go back to the site and validate that the resolution is to their satisfaction. In order to do this, the written documentation is a great reference for the test personnel on how the error occurred, so they can retest the page or site function that had the bug.

Keep in mind that not all reported bugs can or should be blatant errors that keep a site from being launched. One might report a bug to the development team that could be more of a suggestion for a future site enhancement. Bugs that are enhancements may or may not be resolved during the testing phase, but instead addressed in a future version of the site. Utilizing testers that have the knowledge and experience to make those sorts of distinctions can add value to the process and help balance the relationship between the overall functionality of the site and efficient production.

Site Launch
Once the necessary bugs are resolved, the site is ready for launch. One mistake that can be made at this juncture is not following through with the test plan and testing the site once again after the launch. It is not out of the realm of possibility that the site could have some type of error when placed on the live server. Therefore, another round of testing should occur immediately after the site is launched to ensure a quality product. In fact, the team should assume that additional bugs may be discovered at that time and be prepared to quickly fix them.

Quality control is paramount to the success of any marketing tactic, perhaps websites most of all. The procedures for quality control should be part of all website development plans and budgets, in order to launch a quality product. If the cost or time to properly perform quality control procedures are not addressed at the beginning of a web project, the chances of a website failing to perform as expected are increased. A website needs to be as close to perfect as possible before it is presented to the intended audience, and the adherence to a formal test plan and test procedures will assist in making sure that all bases are covered before the site is launched.

Author - Julie Price

Editor - Dirk Knemeyer

  Download PDF file (28k)