Quality publications, industry research and online services
for the software development and testing professional.




|
Testing the Weird Wild Web |
Whether testing a world wide internet site, an internal corporate intranet, or an extranet virtual IP
network that grants limited internet access to select groups, web sites and network applications that use a
browser interface are everywhere. Web testing is critical when your image and reputation are on the line,
around-the-world, 24 hours a day.
This article presents the challenges that web testers face, the tools that are available, and gives some suggestions of where to begin when you attempt to test the World Wide Web.
Testing Links and Web Site MappingTesting begins with mapping out the site under test. Your web test plan should include following all the links of a web site to generate or validate a map of the web site structure. Testing the links ensures that no "404 - Not Found" errors exist, and that the pages retrieved for display are the ones that are expected. Links come in all shapes and sizes: hyperlinked text, linked graphics, or java-enabled controls. Some automation test tools can’t recognize and manipulate links. Be sure your tool evaluation includes a question about exactly how links are recognized, and how they can be tested once recognized. Even in straight HTML, links need to be recognized as controls or objects in order to test them. Tools are available for starting with a URL (Uniform Resource Locator), then automatically following all the links and pages that are found within that site. There are some robots available for this process. Some of the less-expensive robots limit how deep the link search will go, but they generate comprehensive error reports, and save the pages that were retrieved for off-line review. Some even allow you to replicate an entire web site in no time. More expensive automated test applications have few limits in number of links deep that can be followed or other restrictions, but require you to build scripts, customize existing scripts, or invest lots of time in creating your own.
Page PropertiesOnce a page is accessed some immediate attributes are made available to the browser and can be tested. These include the URL, title, date last updated, size, number of links, last HTTP status, and the time to load. Virtually all of the automated test tools allow this level of testing using pre-defined commands or routines, and every web test plan should include interrogating these variables. Track these properties to compare to what is expected, or to establish the environment at the time the test was run.
Load and Performance TestingThere’s nothing better than automation when you have to hit your program or server with multiple simultaneous requests to see how it performs! Imagine load testing the next version of Yahoo™, which today gets hit rates of one million a day. Fortunately, there are automated test tools specifically available for this task--sometimes even a Java applet will do the trick.
ChallengesOne of the challenges lies in automating the testing process and keeping the unattended test scripts synchronized with the application under test. Synchronizing implies knowing when an event has occurred before proceeding with the test. Automated scripts that are clock- or timeout-based will be logging nothing but false defects in just one day of high packet loss over the net. Even event-based solutions can fall short since few things inside the browser window are reliably present to signify that an event has occurred. Many visual clues for events--such as files being fully loaded--are on the browser window frame, and even those aren’t reliable. Think how many times the phrase "Document: Done" appears on the frame before all files that make up a page are fully loaded. Another challenge lies in the behind-the-scenes complexity. If your web browser crashes, how do you know what problem you’re really seeing? The bug you’re chasing could be in that browser version, or in the HTML code, or the database connectivity software, or the database itself, or in the web server software, or a unique combination thereof. Each day that goes by adds to the pieces and parts of web sites that beg to be tested. Perhaps the biggest web testing challenge has to do with the browser interface itself. Even though there are only two real players--Internet Explorer© or Netscape Navigator©--the browser eases delivery but complicates the testing process. First you must test the different versions of the two browsers, test for browser neutrality on all browsers, and test with different plug-ins that may be installed. With the browser issue comes operating systems, platforms, graphic capabilities, and machine configurations. Testing all the different configuration combinations can quickly become a huge and insurmountable task. Just thinking about it can keep you up at night.
Testing Java and Active X through GUIsSecure access, managed accounts, dynamic web content--a lot of internet-related needs are enabled using Java or Active X programs on the client or server side. These programming languages, which are barely a year old, are standard fare today. The browser neutrality issue particularly comes into play for Java and Active X programs, which may not work from one browser to the next but also may behave completely differently on one than the other.
Go Forth and Web TestFrom the upper processes down there won’t be too much difference in a web test plan than any other. Issues of supported configurations will take up a lot of time and metrics--probably more than any other testing project. An in-depth understanding of the parts that make up the web site, and which part is responsible for what, is necessary for formulating the right mix of hoops the site must jump through. Selecting and using automated tools where possible will give you an edge since web test developers and their users have already encountered many of the challenges you’re likely to face.
Web Testing Tools Sampler
Editor’s Note: Special thanks to Scott Killen of AutoTester, Inc., Yakup Kinikoglu of Texas Instruments, Inc., and Mike McGary of OnDaWeb, Inc. for sharing their expertise in the crafting of this article.
|
© 2002 - All Rights Reserved - Software Testing Institute