Testing your Web pages is very much like testing any other computer program. You test it while creating the page because you have to look at it with a browser or your HTML editors browser view. If you use a completely WYSIWYG HTML authoring environment, the authoring program does most of the developmental HTML syntax testing.
As you proceed with page development, you tag and view, tag and view, and so on, until you decide that you like what you see. When you have coded all features that you want into the page, its ready for more stringent testing.
The following steps generally guide you through what is called the alpha-testing phase. Only you and a few trusted assistants need to make it through this phase. Hopefully, by the end of the alpha phase, you will have removed most of the big, ugly, and obvious problems. If youre developing your own home page and personal Web, you still need to go through the steps because if its worth doing, its worth doing right, isnt it?
Run it through a spell checker.
And while youre at it, correct the spelling and double-check your grammar. Poor grammar is even worse than spelling errors.
Test the page by itself on your own computer
with local files and relative URLs.
Fix the problems and test again.
Test the page in the Web of other pages on
your own computer.
Fix the problems and test again.
Test the page by itself on the Web server
in your private area with relative or full URLs.
Fix the problems and test again.
Submit the pages URL to an online
HTML validation form for syntax checking.
Fix the problems and resubmit until its clean. Hey, nobody produces perfect code the first time.
Use a link tester and other programs to
test the page with the other pages in your private Web on the Web server.
Fix the problems and test again.
Enlist a few work associates or close friends
to critique the page.
Otherwise, keep it private and get them to keep quiet about it. Fix the problems and test again.
When you think the pages are ready, submit
them to the HTML validation site one last time.
If it comes up clean, its ready to beta test.
After iterations of comments and revisions until your alpha testers abandon you -- or until they dont find anything else to nitpick -- your page(s) may be ready for honest-to-goodness beta testing (in which you actually ask other people to pick your page apart and tell you about it). We discuss beta testing in Extra 5. The rest of this chapter explains some details of your alpha testing.
The two strongest reasons for testing your Web pages with an HTML testing and validation program, link checker, and anchor checker prior to making them available to the WWW community are
Your Web pages may contain HTML tag errors or nonstandard tags that would cause them to display improperly on your targeted browsers.
Your Web pages may not contain either required or optional HTML tags that are important to search engines or spiders in the future. Without proper usage of the tags that crawlers search on, your pages may not be listed in future indexes and jump pages; therefore, it wont be easy for participants to find your Web.
If you havent created your page on a strict HTML-syntax-checking authoring system, submit it to one of the online HTML syntax validation systems or use one or more of the programs found at the following sites.
Go to the following URL at Yahoo! and you
find links to 27 -- thats right 27 -- sites with HTML validation
checkers, link testers, forms testers, syntax checkers, anchor checkers,
Using some of these sites is as simple as linking to the testers site and entering the URL of the site you want to test (that is, your site) into their form. Other sites you must download and run on your own computer. Here are a few of our favorites:
After you get the report from one of the syntax checkers, revise your Web page if necessary. Most of these syntax checkers check for the HTML 3.2 DTD and HTML 4.0 DTD, so any tags you use that dont conform may be marked as errors. If you want to continue to use tags that are specific for certain browsers, do it knowing that your page may not look the way you expect on other browsers.
|WebCrawler may not pick up your Web page if you use the <!DOCTYPE> tag with a reference to HTML 4.0 until HTML 4.0 is officially approved. (This is scheduled to happen early in 1998, so stay tuned to the W3C Web site at http://www.w3.org/.)|
Creating your Web pages and assembling your Web is a repetitive, build-and-change process. After you have more than one page, changes on any single page can affect others. Unless you repeat the same tests each time you make a change, you may find out the hard way from your users that errors have crept into your pages. Among the many things that build-and-change requires -- unless you have perfect recall -- is that you write down your testing procedures and keep accurate records of your testing.
You actually started the testing and validation of your Web pages when you sketched the layout of each page and your overall Web structure. These sketches are the first documents in your test plan. (See? Youve already finished something, and you didnt even know youd started.)
For your personal Web, your test plan may consist of only a copy of these layout sketches with a checklist of testing steps that you want to use on each page of your Web. This testing takes some of your valuable time, but the results will make you happy later.
If youre in a business or institutional environment, you are probably more accustomed to formalized, structured development and testing. Familiarity with this environment can help your undoubtedly more complex Web accomplish its goals.
The following section presents a generic alpha-test plan. Those who need to produce this type of document for your organization or anyone who really wants to proceed with testing your Web pages in an extremely orderly fashion may modify it to suit your specific needs. If you dont fit in that category, you wont suffer from brain-strain by reading over the plan. Remember, do it right the first time or take the time to fix it later.
The following sections outline a plan for alpha testing your pages.
Provide a comprehensive plan for testing the accuracy and completeness of the Web page at stages during the development cycle or prior to the release of a new version.
The test plan encompasses testing user-level functionality for all features, states the accuracy of the data generated, checks the agreement of the user-guide information with the Web page operation, and tests the agreement of the normative data from the manuals and errata sheets with the Web page data, and the compatibility of the Web page with various hardware and software configurations.
In general, a good alpha test of any Web page should
Test all functions of the Web page under expected usage conditions with appropriate hardware and software.
Test all functions under abnormal usage conditions, such as inappropriate hardware or software, incorrect or extreme data conditions, and operator errors.
The goals of your Web page alpha test are to
Determine the level of functionality and performance of the Web page.
Document all operational abnormalities and Web page errors in an efficient and flexible test-tracking system.
Verify Web page and participant information correlation.
Testing begins on (date) and continues until you complete the test plan and find no correctable errors on the Web page. The Software Testing and Quality Assurance Department staff (you and your friends) provide full-time testing. Make sure that you pick only people close to you who can keep the location of your pages to themselves. You dont need the aggravation of unwanted testers at this point in the process. When you recruit helpers, you need to give them instructions on what type of feedback you want. At the least, ask them to e-mail you with any problems or suggestions they may have. This e-mail method works if they are conscientious, organized people, which is the only kind of alpha testers you want. At most, you want to conduct detailed interviews with them to force them to give you the real dirt you want!
Providing a simple text form that your testers can complete and e-mail back to you really helps both your testers and you. Request at least the following on your form:
Tell your testers that it would be really helpful if they religiously filled in all of the information on a separate form for each different problem. When the forms start clogging up your e-mail in-box, you need a place to store them and a method of sorting them. Any reasonable method, from printing each and visually sorting them to importing them into a database program, will work. Use the easiest one that works for you. Keep in mind that you probably want to use the same method for the beta-test feedback, so choose a method that can handle the number of messages you expect -- then double that number to get ready for the unexpected!
Testing is conducted by using the following system configurations as representative of systems in the field:
Browsers: List all browsers to be tested. If possible, try all browsers that you think your target audience may use (or every one you know about, anyway).
Computers: List all computer systems you want tested along with the above browsers. Many of the browsers work on more than one system (such as PC with Windows, Macintosh, X-Windows, and so on).
Web servers: List Web server software you want tested with CGI scripts and forms. You may be limited to your own Internet Service Provider or your business or institutions Web server, but test it thoroughly and completely.
Your test should have a method to its madness. Solid testing methods ensure that:
Testers evaluate Web page functionality and performance primarily at the user level by performing operations with keyboard and mouse input and evaluating data that the Web page generates.
Testers document Web page errors and operational abnormalities by recording this information when they encounter problems:
Priorities are assigned to the problems as they are received: Priority 1 -- system lockup or data corruption; priority 2 -- cosmetics (spelling, wording, screens ); priority 3 -- inconvenient operation.
The document on Web page problems must be updated as often as possible and made available to developers for resolution of problems.
The following sections outline some areas to consider during the performance and functionality testing.
Inspect each screen looking for inaccuracies or omissions related to spelling, formatting, and layout. Download and install all the browsers that run on your own computer and test with them first. Make a deal with Web friends who have different types of computers. Have them test your pages in return for your testing their Web pages with your computer. Turnabout is still fair play, and it can expose you (and them) to new ideas and materials!
Verify that each link functions correctly and that each destination URL exists and presents the information named in the hyperlink text. Use one of the link testing programs found on Yahoo! to help you. (See the section, WebBuilder, test thine own web thyself, earlier in this chapter for more information.)
Verify that each form correctly receives, processes, and records the participants responses. Verify that the Web server properly stores the data and delivers it to the appropriate location in the desired format. Use one of the forms testing programs you find on Yahoo! to help you with this.
Verify that clicking on each portion of the map displays the appropriate image or page. Verify what happens when you click other portions of the map and screen around it.
Test all limit and boundary conditions, such as high and low numerical values and text amounts in forms. Make sure you test the edges, not just outside the expected limits.
Extra 5 Main Page | Previous Section | Next Section
E-mail: HTML For Dummies
Webmaster: Natanya Pitts, LANWrights
Revised -- January 16, 1998