Publishers of technology books, eBooks, and videos for creative people

Home > Articles > Design > Voices That Matter

Web Design Reference Guide

Hosted by

Testing

Last updated Oct 17, 2003.

Some debate that testing is not a phase because it occurs across many phases. Although true, it's necessary to test the units before the final and integrated product to ensure that bugs are caught earlier in the process. Unit testing is completed during the development stage. Some shops do component, module, system and acceptance testing.

When shopping, do you blindly buy products? When you're standing by a clothing rack, do you close your eyes and pull out whatever item and take it to the cashier to pay for it? Typically, when a person finds an outfit that meets her style, she first checks the size. We know that size alone doesn't ensure that it'll fit nicely because every design manufacturer has its own standards for exact sizing. One designer's size 8 might fit, whereas the other is too big. If the size is good, we give the outfit a last look-see to verify that there are no marks, tears, holes, or any other damage. This is testing, fashion-style. Application testing works similarly, where the requirements act as the "person trying on the clothes."

Testing not only makes sure that the Web site looks good, but it also checks its performance and back-end functionality. Try to get the client's end users' feedback because they will be the ones using the Web site. Add user testing to the requirements at the beginning of the project as well as the project schedule and explain the purpose to the client. Establish measurable testing objectives early on in the project that validate the requirements are met. It's a challenge to catch every bug, but as long as the application meets the intended requirements and expectations, the test is a success.

Mapping the Plan and Reporting Results

Clarify the testing team's role as early as possible, including the process of reporting a problem. Not all departments have the luxury of a database for reporting and tracking bugs. To put together a testing process, think about the following questions:

  • Where do we do the testing?

  • How do we report defects?

  • Who should be notified of the defects?

  • How will the defects be resolved and reported?

  • How to categorize the defects for tracking where the defects occur?

  • When does the team meet to discuss open and closed defects?

The "where" focuses on the testing environment that is separate from the development and product environment on separate servers. When the users or audience is defined, this helps identify the kind of system they use while interacting with the application. The test team mimics this environment as close as possible. Define the process for moving code to and from the test environment.

Document the testing process and verify that all parties involved are in agreement. Without buy-in, few will follow and support the process. It's possible to go overboard with documenting the process where it becomes a burden instead of a help. Whatever works for the organization is the best way to proceed. The key is to have a process for conducting testing, reporting results, and closing issues.

The Many Faces of Testing

With the many types of testing, few design shops do the same thing. Even one design shop may use different testing types for each project. Here are the more common testing types:

  • Usability testing

  • Unit testing

  • Markup testing

  • Load testing

  • User acceptance testing

  • Security testing

Usability testing checks the application from a "user's" viewpoint and how it affects the experience. The requirements typically describe the users who will most likely visit the Web site by way of user profiling. This identified a few users who would use the site supported by a biography to "put a face" on the user. The end result is to find out whether the user can interact with the Web site to achieve her goal. A good way of doing this testing is to bring in outsiders who have the make up of the user to use the Web site while testers or developers watch the user's moves. Here's a shocker! Users make mistakes. They click the wrong button, enter the wrong information, enter the wrong URL, and so on. See how the Web site handles those mistakes.

Unit testing occurs during the development stage and verifies the functionality of a small piece of the application. The unit is as small as accomplishing a single task, and the test ensures that the task result is the expected result. Testing a button to see if it takes the user to the right page is one example. Another is entering data into a text box to see if it can handle it, especially when garbage or a large amount of text is entered. Catching defects early in the game prevents bigger defects later.

MarkUp testing validates the accuracy of the HTML or XHTML markup. World Wide Web Consortium (W3.org) has several validators: HTML, XHTML, and CSS. There are also accessibility validators like Bobby, Cynthia Says, and Wave. Internet Explorer is more forgiving of bad or poorly written markup. Users using other browsers like Mozilla, Netscape, and Opera may not see the page at all or have problems using it. It goes back to knowing what the users have in terms of browsers.

Load testing checks performance, scalability, reliability, and availability. It checks to see how well the Web site handles heavy bandwidth usage from many users arriving at the site at the same time and using its features. It also verifies the page downloading speed. According to Speeding Up Your Site, a Web site that doesn't load within eight seconds (give or take two seconds) loses users. Chances are good that the site will continue to grow, so it needs to be scalable for future enhancements. A company who advertised during the Super Bowl wasn't prepared for the use of massive bandwidth on its Web site, which shut down for hours. Anticipating such events ensures that the site is reliable and available for anything that comes.

User acceptance testing involves using the application as it is intended. A common way to accomplish user acceptance testing is through a beta test. Users are ideal for the beta test, and they'll be responsible for providing feedback.

Security testing checks for holes in security to validate it's safe from internal and external security threats. If the site is an e-commerce site, obviously customers want to feel secure about sharing their personal information. Security testing is best when it's initially done before the site is live with regularly scheduled spot checks to ensure that the Web site remains secure as hackers get more sophisticated with time.

Testing is expensive, but customers discovering errors is more expensive in terms of credibility and security. The 2002 Winter Olympics site paid dearly for overlooking ALT tags, which is needed for people who use screen readers to "read" Web sites, leading to a price tag in the million-dollar range. If the issue had been caught earlier in the process, the cost would've been lower.

Pinto-Free Zone

Explain to the client that the users aren't as well informed as the client on the products and services, so you need lesser-experienced people to check it out. Whatever happens, testing shouldn't be a sacrificial lamb to save the budget or the delivery deadline. Do so and it'll backfire...just like the poorly design Ford Pinto.