E-Pain Relief

Thoroughly testing your code can minimize the headaches of Web heterogeneity

You've put your new web site through rigorous testing - functional, integration, compatibility, and performance - and you're confident that it will work as designed. The site is launched. Within hours, users are complaining of problems with the site.

The user feedback forms are vague, making the problems hard to diagnose, although the comments clearly convey frustration: "I was trying to buy a scooter, but the site wouldn't let me check out!" Or "Why doesn't the search feature work properly?" Without knowing what the user was expecting, you have no idea whether the site's search function worked for the user as designed or not. All you know is that it did not meet the user's expectations.

Even when the user's feedback is relatively clear, the user's configuration may be outside the site's compatibility specifications: "I'm using Netscape 3.0 on Solaris, and the images on the catalog pages don't align properly," or "Sometimes the site works really well, but other times it's so slow." All these issues stem from a Web characteristic that is both its strength and Web developers' greatest frustration - its heterogeneity.

Different Dimensions

A wide range of users on different networks with different client configurations will view your site, which can lead to an array of complications. By understanding and anticipating those complications, you can develop and test your site to prevent many of these problems, and you can more effectively troubleshoot the rest.

One of the strengths - and biggest complications - of HTTP and TCP/IP is that they can run on a wide variety of networks. When a request comes in to a Web server, the server knows only what it's been told about the client. This information includes an IP address, which theoretically is the address of the client that will render the Web page, but can in fact be the address of the firewall or proxy server that receives the data first and forwards it on to the destination client, possibly altering the Web page on the way.

For example, the user's network administrator may decide that Java poses too much of a security risk and block all Java applets from the network. Therefore, even before the request arrives at your Web server, it may have been through any number of altering and filtering devices, such as a proxy that sends the requesting client cached content that it originally sent to another user in the client's network.

A network's speed and reliability also affect the site experience. In addition to download time, network capabilities can affect a Web server's resources. Slow networks require Web servers to keep HTTP connections open for a longer time, tying up resources. Unreliable networks at the user end can require repeated attempts to send packets and eventually cause dropped sessions. Unless handled properly, such dropped sessions can cause problems with system resources and locked data. For example, a user's session may be dropped in one tier of the architecture but not another, locking the user out of the data until this second tier resets the lock and reinstates the user access.

Networks are heterogeneous, and so are user configurations. Unlike more traditional client/server systems in which a single or limited variety of clients access a server, the Web includes a wide array of clients. I use the word array purposely because Web configurations are truly arrays of multiple dimensions, which include:

• Web browser dimension. Does the user have Netscape Navigator, Microsoft Internet Explorer, Opera, AOL, or one of the multitude of lesserused browsers?
• Version dimension. Does the user have browser version 4.0, 4.01, 4.51, 4.71, or 4.75?
• Platform dimension. Which platform is the user running Windows 95, 98, 2000, NT; MacOS 7.6, 8.0, 8.1, 8.5, 9.0; or one of the many flavors of Unix?
• Plugins (and versions) dimensions. Which plugins (and plugin version) does the user have RealPlayer G2, 7, or 8; Flash 1, 2, 3, 4, or 5; or Windows Media Player?

In addition to these considerations, you must also consider the possibility of various Web appliances such as WebTV, I-Opener, or PDAs. With the many possible permutations between these dimensions, the issue of client compatibility becomes very thorny and can often be overwhelming.

Planning Ahead

The first step in minimizing site problems is to be extremely clear about your target audience and the client configurations you will support. Any variation could cause problems. Although the possibility that Netscape version 4.75 with Flash 4 running on Windows 98 will work fine while the same version running under NT will produce an error may seem unusual, such errors do occur. Unless you decide in advance which permutations you are going to support and do thorough testing with those configurations, you will be chasing down compatibility issues constantly.

Although you will never be able to anticipate all the variations that crop up in the real world, you can eliminate many problems by conducting thorough testing, both before the initial launch and before releasing any code or configuration changes. In addition to the standard procedures for testing software, I find the following four checks helpful in testing Web applications:

• Testing on a slow connection: Not only will testing over a slow connection such as a 28.8kbps modem help you catch pages that take too long to render, it will also help you to watch exactly how a page renders. Although simple math can tell you how much data a page and its associated graphics contain, the user's perception of how quickly a page loads is based on more than just the amount of data the page contains. Table structures, the order of images, and the user's browser cache all have an impact on this perception.

  Browsers will generally render pages linearly, from top to bottom, which means that problems at the top of a page can significantly delay the rendering of the rest. If a page seems to be held up at a certain point, look very carefully at that particular section of code. Common causes for this kind of delay include accessing materials on a different server (such as an ad server), accessing a different piece of software, connecting to a different backend system, or waiting for a failed connection to timeout.

• Pay attention to the status bar: You can discover a lot about a problem by carefully watching the status bar both before and after a load. If the browser appears to hang while loading, the status bar will often tell you whether the problem is that the client cannot resolve the DNS, the server could not be reached, the server is not responding, or the connection is delayed midtransfer.

  After the page loads, rolling over links and checking the displayed URL in the status bar can help you determine where your problem is. If the URL is poorly formed, the processes that precede that page are the problem. If the URL is correctly formed, the problem lies in the processes that follow that page. Pay particular attention to the query strings (the section of the URL following the path and beginning with a question mark).
  

• View the source: Once the page is loaded, view the source code. HTML's textual nature and loose parsing can result in all kinds of problems, especially when moving from Microsoft Internet Explorer to Netscape Navigator. Missing quotation marks, unclosed tags, and poorly formatted tables are all problems that generally pass undetected in Internet Explorer but can cause a page to render improperly or not at all in Netscape.
• Look at the interface points: Make sure that data going in one side of the interface comes out properly at the other end. Typically, the data path in a Web application looks like the path shown in Figure 1 .

Special characters and escape codes often complicate this process, as each of those interfaces is a potential trouble spot. For example, an angle bracket will generally pass through every step of this process fine until it is converted into HTML. If it isn't translated into its escape code at this point, it will not render in the browser. Single quotation marks will generally pass fine until they reach the database, where they will confuse SQL if not handled properly. Any characters with special meanings such as this will need to be intercepted and translated or otherwise modified to prevent them from causing problems later in the workflow. On the way back through the workflow, any such translations need to be reversed. Similar problems can pop up with quotation marks, ampersands, and line breaks.

What You Don't Know

Despite thorough testing, some errors are inevitable. In order to make troubleshooting more effective, you need to include thorough exception handling and error reporting when you build your site. The Web is notorious for only providing limited error information, particularly about the client and status. Based on a stateless model, just keeping track of a particular user session requires convoluted token-passing schemes.

Although application servers now hide much of the mechanics of this token passing from you, you can still feel its effects on session management. Session management problems can appear wherever systems interface, such as in the negotiations between Web server and application server or between multiple Web servers.

Another effect of this statelessness is that from the server side, you cannot tell what is happening at the client end. Why did users abandon their shopping carts before checkout? Was an item too expensive? Did an error in the page rendering prevent them from proceeding through checkout? Did the user's system crash? Did the user's ISP experience a problem? The developer only knows that the server received no more requests from that IP address.

Although the fast-paced world of Web application development may tempt you to cut corners, the lack of information inherent in the medium requires thorough exception handling and error reporting. The code must do more than simply capture an error and report it to a log.

Help Users Help You

If you don't want to spend days trying to reproduce an error based on a vague description from a user, the application must capture an exception and return a clear and unique error message to the user. The error message should include both a basic explanation that is clear to the average user and a unique ID that identifies the specific error to the troubleshooter. (The error message should also state that the user should provide this information when reporting a problem.)

Of course, producing an error message for every situation that users may encounter is impossible. If the code itself is not at fault, the majority of errors are less predictable - unsupported or overlooked browser combinations, network hiccups, or other problems that occur outside the application space. Having clear troubleshooting and code maintenance procedures in place is the best way to deal with these problems.

These procedures should include a well-designed feedback form for users to provide problem descriptions. Although many people argue that by providing a feedback form you suggest that the site has problems, you are really only acknowledging the unpredictable nature of the Web. If users are experiencing problems with the site, you want to know about it - not add insult to injury by making it difficult for users to inform you of the problem.

In addition, you also need a procedure for dealing with user feedback. These procedures include sorting exception reports from other types of feedback, logging exceptions into an issue tracker, assigning exceptions to developers for fixing, testing the fix, and deploying it.

The Web is a very different place from the closely controlled testing environment. Test thoroughly to avoid problems in the first place. But because you will inevitably have some errors, make sure that your coding and procedures are set up to properly handle errors and minimize frustrations. After all, the Web's heterogeneity is one of its greatest strengths.

Alex Buccino (alex.buccino@marchfirst.com) is quality assurance manager in MarchFirst's New York office.