 | ||
|
| ||
| ||
|
| ||
Nancy Winnick Cluts
Developer Technology Engineer
Microsoft Corporation
Updated October 16, 1997
The following article was originally published in Site Builder Network Magazine.
One complex side dish that the Internet brings to the development table is the testing of Web content. Traditional software-development testing has been done for years, and most testers are proficient and comfortable testing stand-alone applications, dyanamic-link libraries (DLLs), drivers, and other applications and tools. Web content, however, differs from traditional software applications -- and because content can be created very easily using HTML, more and more people are now "developing" for the Internet using a greater variety of languages, scripting, and controls.
What's a tester to do?
I spoke with the test manager for the MSDN Online Web site to find out just how she handles testing for the Web. I ended up with lots information, including how testers deal with different platforms and browsers, how to test links, how to test controls, and some special considerations for Dynamic HTML.
Users can choose from more than just one platform (operating system) and one Web browser. That's great for the users and the industry, but a pain in the neck for a tester. It's more work to test on multiple platforms and browsers -- not just released platforms and browsers, either; Web content also must be tested on beta releases of upcoming software. This adds even more complexity to the problem.
The MSDN Online Web site is tested on the following platforms:
using these browsers:
The test team comes up with a matrix showing the different browsers and platforms. In general, the testers know what is supported on the different browser/platform combinations, and can test based on that information.
To test on the different platforms and browsers, Web pages are tested on three levels:
What would a Web page be without hyperlinks? As we all know, hyperlinks are what propel us to different Web pages (URLs). On MSDN Online, we use an internal link checker utility to check the veracity of internal hyperlinks.
Links going to outside Microsoft's external Web Site, www.microsoft.com 
, were hand-tested until recently. Now, a spider technology is used. Sources of such tools include Microsoft FrontPage and Aman Software's Cyber Spider 
.
Whatever tool you use, testing external links raises a few questions:
Luckily, end users give us lots of feedback, and let us know if there is a problem with a link. But we'd rather find and fix any bugs ourselves.
Another important area of testing links is maintenance testing. After an article has been published for a while, we have to ensure that links haven't disappeared. We alert all Microsoft Webmasters when an internal link is going to be changed or will go away for some reason. But for external links, we don't get the alert. That is the tough part.
For browsers that support controls, another level of testing must be done. Controls have special security issues, must be signed, and may rely on other components, such as DLLs, to run correctly.
Controls that we produce need to be digitally signed so users will know that we vouch for the control -- it does what we are saying it will do, and it isn't some virus. As a result, the test team needs to ensure that any controls downloaded from our site are correctly signed. Testers also have to take into consideration whether the end user has a security setting that allows controls to run. If the security setting does not allow the control to run, the user should be prompted with that information and steps she can take to alter the setting, or what she will miss if the control is not downloaded.
Some controls depend on the existence of cookies, which allow data to be saved on the client machine. However, the end user has the option to turn off cookies. If a control depends on cookies, and cookies are turned off, what will happen? The control needs to have some default it can use, or it should prompt the user.
It's important for a tester to determine whether the controls created for the Web site interoperate with other controls. What happens when you add another control? Does the original control still work? It should. If not, you need to tell the user that you might be causing other components to cease to operate before allowing the download. Many users may not want to risk losing functionality of a favorite control for your new control (I know I wouldn't risk it), so it's far better to play well with others.
Does the control rely on a specific DLL or a specific version of a DLL to operate properly? To test this, the MSDN Online team purposely configures a machine so that the control may not work (for example, they may remove a key DLL). The control should still work, or should launch a setup program that prompts the user to install the DLL.
You can't have a Web page without HTML. The really good news about HTML testing is that many tools available on the Internet provide automated HTML testing. A couple of examples are HomeSite 2.0 and CSE HTML Validator . On the MSDN Online site, HTML testing is mostly automated via tools that check tags, tables, and so forth. Aside from the tools available over the Internet, the MSDN Online team includes a tool writer to create tools for any special testing needs.
DHTML allows you to create very cool Web pages. The downside is that because it is so new, automated tools are limited. Most specific DHTML testing has to be done manually. The MSDN Online team's DHTML testing includes state testing (onclick and onload, for example), and scripting used in conjunction with DTHML.
Internet Explorer 4.0 has lots of new features for the Web developer. More features mean more testing. Many Web developers who are coding on the cutting edge employ scripting, data binding, absolute/relative positioning (CSS), and new DHTML features for their Internet Explorer 4.0-specific Web sites. All of these features must be tested. When testing for these features, some questions to ask include:
Before testing, read up on the changes between Internet Explorer 3.0 and Internet Explorer 4.0. Some helpful resources are:
Nancy Winnick Cluts, developer-technology writer to the stars, always gets it right, no matter how long it takes.
Tip 1: Play nicely. Be part of the Web team. This keeps you in the loop, and gives you a voice in debates of functionality versus design. Remember, a tester is really a user advocate. Protect that position by making friends.
Tip 2: A good spec is a tester's best friend. Get design and functional specifications -- even if you have to whine or threaten. Specs help you determine what is a "real" bug and what is "by design."
Tip 3: KISS (Keep It Simple, Stupid). If you have a form that's supposed to accept only integers 1 to 10, you can start your tests by entering NULL, 0, 1, 10, 11, 1000000000, -1, a, and the other acceptable values. You needn't enter every possible key stroke to find a code hole.
Tip 4: Expect the unexpected. Before you think the previous tip allows you to cut back your testing, remember the user. If your audience is non-technical, the possible keystrokes, browser settings, and other "mystery" influences are unlimited. Think like a user, and stress the Web site the way a user would.
Tip 5: Use all the automated testing tools you can get your hands on. Many useful tools are on the Web already (see our Downloads area for a sampling). With a little searching, you may be able to find the right ones for you.
Tip 6: Stay caffeinated. A double-tall-skinny latté? Your standard cola? The importance of caffeine cannot be emphasized too much. How could one possibly test into the night without it?
Did you find this material useful? Gripes? Compliments? Suggestions for other articles? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top