HTML 4 For Dummies - Bonus Chapters

Beta Testing


You’re not alone in your quest for a perfect Web site. Practically everyone on the Web would like every single page they view to match their vision of perfection. In fact, millions of Web surfers will happily judge your work. The key is to get a few of them to help you make your Web site better during the test phase called beta testing.

During beta testing, you enlist a larger (but still manageable) group of users to help you make your Web pages the best thing since coffee and candy bars. They not only test performance and functionality, but they generously advise you as to how stupid you were to put the image of the sparrow in with the finches and so on. They spot problems that you didn’t even know existed. What? Things that you look at every day but ignore can bother enough of your beta testers that you may decide to change them -- the problems, that is; not the beta testers!

You can use the same basic technical form that you used during alpha testing for beta testing. However, you should add the following questions:

Ask your beta testers to tell you about their specific likes and dislikes, and your beta testers will oblige you; believe us, they really will!

Beta testers

We hope that you can find beta testers who are directly interested in the content that your Web pages present. You need feedback on their likes and dislikes, as well as their impressions of your Web’s functionality, layout, and behavior. They are your primary audience, albeit a small portion thereof, so treat them well.

Find beta testers by posting an invitation in relevant newsgroups. Simply ask for people interested in helping you test your new Web page. Filter them by asking them to e-mail their names, addresses, phone numbers, backgrounds in your content area, and some reasons why they think that they would make good beta testers. To everyone who replies, e-mail immediate thank-you messages with a noncommittal statement that you were overwhelmed by the response and will get back to them shortly.

If you decide not to use some respondents, which is unlikely, send them a nice e-mail thanking them profusely and saying that you ran out of your allotted testing spaces before getting to their names, or something equally friendly.

Tip Icon Cliché warning -- Do a good deed for someone and that person will tell three friends about it. Do something that makes someone mad and that person will tell 11 people what a jerk you are. You may not be able to make everyone happy, but try your best not to irritate your users when selecting beta testers!

E-mail each beta tester an announcement for each change cycle, with a list of revisions and a copy of the beta test report form you want them to complete and return. Thank each tester for each problem report. Make sure that you notice those testers whose problem reports resulted in a revision. Take the time to make real friends out of your beta testers and you will benefit from it for a long, long time. Your beta testers are your users. Remember Rule number 1? (If you have no idea what we’re talking about, see the document Extra 4 on this CD.)

Revision cycling ahead of the gremlins

No, a revision cycle isn’t something you pedal backward. It’s a method to handle problems and changes to your pages in an orderly way. Simply stated, you don’t fix problems in the order in which you receive them. Sure, you’re anxious to clean up your work, but you must prioritize the problems that you (or others) find. If you don’t prioritize, fixing changes costs more time in the long run. You’ll find that, for a large complex Web, a one-week revision cycle is probably the shortest period possible, with a two-week cycle less anxiety-provoking.

Cycling revisions also helps you keep ahead of the insidious gremlins called unexpected side effects. These occur when a seemingly small change is made in one page without enough thought put into its effects and without any testing of the entire site afterward. One common example is changing an image that’s linked to every page in your site, such as an icon or navigation button. Suppose you put that image in the wrong directory. That image wouldn’t show up at all and that would be easy to detect. But suppose you change the e-mail address for feedback and make an error. You may not find out about that for quite a while, unless you use the new address to send yourself mail immediately upon installing the change. (Now that we think about it, this is a good testing technique, too -- why don’t you try it?)

Tip Icon By batch-processing prioritized problems, you can give everyone in your testing crew adequate time to thoroughly perform their validations. While they test your most recent set of revisions, you can work on the next set. Be sure that you note your fixes on each problem form as completely as the problem itself was documented. Also, be careful to update the version number and revision date/time for each page that you change and include this information in the problem fix section of the form or database.

From a testing report database, make and keep an ongoing list of problems. Prioritize them in your own order. Then decide which problem or group of problems to fix. Consider not only the time it takes to revise HTML documents, but also the time you need to run the changed pages on the entire site completely through your test checklists on all appropriate browsers and platforms. With this time frame in mind, you’ll probably decide that daily changes aren’t possible. That’s what we learned, too!

Extra 5 Main Page | Next Section

Home | Bonus Chapters | FTP Resources | Site Overview | Book Contents | Book URLs | Book Examples | Wayfinding Toolkit | Contact Info

E-mail: HTML For Dummies

Webmaster: Natanya Pitts, LANWrights
Copyright Information
Revised -- January 16, 1998