(I am hoping to categorize these in the near future.  Please email me if you have any tips that you would like to see added.)

1. Keep a list of sites that link to your page and check their links when you change your site. You can use a tool like WinRunner’s web extensions to automate this process. Remember that external links to your site are a major source of new visitors.
2. Identify all major browsers types which visit your site and test your site with each browser.
3. Spell check the web site. Tools such as Microsoft FrontPage make this task easier.
4. Check that every page contains the companies address, links to phone numbers, fax number, and a link that will provide email addresses to the major departments in the organization.
5. Ensure that every page provides a link to the main web site. Remember that the majority of users will enter your web site through a search engine and subsequently they will have to be redirected to the home page.
6. Test the server to ensure that it contains MIME types for all objects contained in your web page. In particular, check for objects such as Shockwave. Remember that MSIE does not require MIME types, but Netscape uses them to locate the plug-ins which will allow Netscape to view a particular MIME type. MSIE can use object tags instead of MIME types, although MSIE will use MIME types if they are present. (MSIE stands for Microsoft Internet Explorer. MIME is a way that servers tell the browser what type of content to expect. Typically this is done based on the extension of the file. Thus any .htm or .html files would have a MIME type of text/html. A document with a .doc extension would have a MIME type of application/msword.
7. A web testing regression should be set to automatically run twice a day. An important concept with web servers is that unlike traditional applications, web applications are constantly changing and ‘live’. This means that the web application could break at any time during the day. An important web site might have an hourly basic regression that makes sure all forms can be submitted to and that the server is responding in a timely manner.
8. Establish a test which will ensure that the server is up (a ping test), and another test which actually grabs HTML content. If either test fails, then the test program should contact you via pager or email. (Or the group responsible for the web application.)
9. Does your web application use adequate white space? Remember that web applications should be user friendly and easy to read.
10. Does your web application avoid colors which color blind people can’t see? (Red and green.) These colors or okay for some applications, but many sites use them to indicate if an item on a form is required or not.
11. Does your web application avoid busy backgrounds with complex patterns? Remember for faster loading over a modem stick with RGB values for solid backgrounds and use small simple backgrounds for extra effects.
12. Does your site avoid the use of horizontal frames? Remember that users will be accessing your site with resolutions from 640x480 to 1024x768 and what looks good on 1024 will look terrible or be unusable at 640x480.
13. Test your site using multiple resolutions. A minimum would be 640x480, 800x600, and 1024x768. An easy way to test at multiple resolutions is to use a video card such as the Diamond Stealth 3D (www.diamond.com) which allows ‘HOT’ swapping of video resolutions. So instead of a reboot, or control panel change, the tester can merely hit CTRL - F6 to switch resolutions. The concept could actually be automated by having the test tool resize the screen automatically. Thus the test tool could test at 1024x768, then switch to a lower resolution and test again.
14. Remember that the type on your web site should be readable and consistent. Test your type on 1024x768 screens and make sure it is legible. Size your print for your intended audience, make print for children and senior citizens larger while mainstream applications should stick with a standard 12-16 size font. Also remember that some programs allow you to set fonts, but these fonts are not always visible on all browsers
15. Test your site for Internet safe colors. Test your site from MSIE and Netscape. Another good test is to use a 16 color machine to test your site. Most people have 256 colors, but a large portion of the home computer users don’t know their machine is capable of displaying different colors and resolutions, much less how to change them and as a result they often view web sites in 16 colors and / or 640x480 resolution.
16. Check for clearly marked required fields on ActiveX controls and web forms. Always use symbols to indicate required fields. NEVER rely solely on color.
17. Test your web application for too many fields on one page. Eight to ten fields are the maximum you should have on one page. Break large forms into several smaller forms. Support caching user information so that you don’t have to require a user to re-enter information. An email address is a great way to cache the information. DON’T expect a user to remember a numeric id.
18. Test the image sizes in your web application and make sure the proper encoding format is used. Remember that JPEG provides a smaller image in 16 million colors versus GIF’s 256 colors and much larger size. GIF should only be used where animated GIFS are required or transparency is required.
19. Test all JPEG images in your web application for ‘banding’. Sometimes banding will show up on one operating system and not another.
20. Test your web application to ensure that users will NEVER have to scroll the browser view area horizontally. This is typical of sites which use frames and are not tested at a lower browser resolutions. Remember that laptops are almost always 640x480 and only the newer more expensive versions are even 800x600. Do you want your web application to be non-accessible by the mobile laptop user?
21. Test your web application to ensure that all pages have identifying titles. Remember that when a user bookmarks a page in your web, the title becomes the default name for the bookmark. By giving each and every page a distinctive name, you help promote future traffic.
22. Bookmarks should take the user back to the page bookmarked. You can test this by automating bookmarking every page in your web site and then cycling back through the bookmarks. Use a gui_check to check the content of the pages.
23. Check your application for links to external sites and make sure that credit is given to any external information. Many lawsuits are coming about because of mis-information on web sites. A typical example would be producing a web site that had two frames and one frame took a user to an external site, while the other frame still displayed your site. This is a common practice and yet it is rich for a lawsuit.
24. Develop a consistent graphic that you can place next to external links to tell users that they will be leaving your site. Microsoft is a good example of a company which has a symbol to signify external links. (External links are links to a web site other than your own.)
25. Remember that timing issues are critical to web applications. What might work fine over a 10MB Ethernet connection might bomb over a 14.4K phone line. Test your web site on a minimum of a 486, Pentium, Pentium II, and a Macintosh 68K or PPC. Java tickers are notorious for looking great on a fast 486 or slow Pentium, but when displayed on a Pentium 200 or greater they will scroll so fast that they become unreadable.
26. Test your web application so that the first page will fit on one 640x480 screen. Ensure that no page is more than 3 full 640x480 pages long. (This means to get to the bottom you should have to only click under the scroll bar three times.)
27. All images and HTML for a page should not exceed 50K. The average image displays the best if it is under 10K.
28. Load test your server! In your testing results include data that shows the maximum number of users and indicate the average time to complete the major tasks in your application under a light, moderate, and heavy load respectively.
29. While load testing, remember to simulate users who are connected over a modem line. They do not download a lot of data, but they do hold open a TCP connection for long periods of time. According to the May 27, 1997 issues of PC Magazine by the year 2000 77% of all users will still be using modems 56Kbps or slower.
30. Be sure and test your server for concurrency issues. What does this mean? It means you need to simulate two users doing the same tasks at exactly the same time. Your ODBC driver might not be thread safe, or some custom C++ code might explode if two users try to access the same portion of code at the same time. Use a tool such as Mercury Interactive’s Astra Site test to test concurrency issues. (www.merc-int.com)
31. Remember that new browsers offer security that often disallows installing plug-ins when the source is not known. Look into MSIE’s security mechanism and if your site uses plug-ins, test from machines that do not have the plug-ins to make sure the plug-ins can be easily downloaded and installed. Remember that MSIE and Netscape handle plug-ins differently.
32. Use a test tool such as Test Bytes by Mercury Interactive to provide large amounts of data input for forms, custom web applications, Java, and VB Script. Boundary conditions are important for web applications. Make sure that the data is placed into the end database and matches the values of the data from the original input files.
33. Test the memory requirements of a your web application. Many database intensive web applications can easily triple the memory requirements of a web site. Be prepared to test sites with multiple servers as well. (There are several utilities that allow you to monitor memory usage on various platforms. NT has memory usage monitoring standard.)
34. Test your web application for invalid data and make sure that the user is informed of incomplete forms and how to correct mistakes.
35. Test your site for use of cookies and make sure your intended audience supports cookies if your web application uses cookies. Be sure and provide a link explaining what your web application uses cookies for and how the end user benefits. Explain how cookies can’t invade the end users PC. Web application designers need to take a proactive role in making sure that cookies have a more positive connotation.
36. If you are developing a professional site or web application, AVOID the use of webmaster for an email link. Yes, I know the world over uses webmaster, but think what if we had testmasters, and managemasters, and programmasters…. You get the point right? There are many much more acceptable names such as Web Administrator. (Okay so this one is a personal bias ! J )
37. Test to see if your server allows client browsing. The easiest way to do this is to point to an image directory and see if all the images are listed. Thus if your images are stored in /images you might type into a browser http://www.yourserver.com/images and see if your server lets you view all the files or if it gives you an error. (You need to point at a directory with no default document such as index.htm or default.htm). Sometimes it is undesirable to allow directory browsing in a secure environment. (It makes it VERY easy for a competitor to grab all of your web images and other materials.)
38. Test to ensure that all directories in a web application have a default document. You can test this by not specifying a HTML file in the URL. The idea is that if a user comes into your site at http://www.yoursite.com/electronics/home/water, then the user should be able to delete water and be able to view a page. If you don’t have a default document in the water directory, then the user will either a. get and error or b. see a list of all the files in the water directory.
39. Test your web site for ease of navigation by doing the following. If you have a corporate web site that sells products, then try typing in things such as http://www.yourserver.com/products or http://www.yourserver.com/SomeProductName. The idea is that end users should be able to guess the structure of your web site down two levels. Microsoft does an excellent job of helping the end user in this way. Try typing http://www.microsoft.com/iis or www.microsoft.com/frontpage   www.microsoft.com/ntserver . See how easy they make it for end users to navigate to the area they want?
40. Test your web application / site for a site map. Make sure that your site contains either a text outline of all the images or a graphical tree diagram that is an image map. This provides an excellent way for users to find information quickly.
41. Load test all your database web applications. Remember that your web site will probably experience over 1000 hits a day and up to 500,000+ hits a day. Now consider that around 70% of the traffic will occur between 12 and 8pm. This makes a strong case for load testing your web database application. You should look for the maximum number of users your site can support before performance becomes unacceptable. (Normally unacceptable in a web application is anything which takes more than 30 seconds to process.)
42. Test your web application for appropriate graphics usage. The web application should use many small images 6K and less that load very quickly v. larger images 30K+. Sometimes this is impossible to avoid, but try to adhere to this simple rule and users will enjoy your page much more. (Even Intranets benefit from bandwidth conservation. Remember that most Intranets already have local network traffic; you don’t want to crash the Intranet with your bandwidth hungry web application that you are selling!)
43. Suggestion: For web applications with many pictures (ex. Photo Gallery Online) , use thumbnails to reduce load times and allow users to selectively view the images in larger formats.
44. If you are developing a web application to sell photographs, calendars, and other copyright printed material, then look into digital watermark technology to protect you and your clients.
45. Test your web application for notification about plug-ins that may be installing. Remember that MSIE just starts downloading helper applications automatically. Inform the end user when this may be happening. (Often your web developers can use jscript or vbscript to probe the client browser to see if they have a plug-in which you require.)
46. Test your web application for a search function. Search functions and directory trees are essential to finding information within any web application.
47. Analyze your web site with a tool such as Mercury’s web site analysis tool to check for too many URL cross links. You don’t want spaghetti web sites!
48. Test your application for spawning an extra browser window. This occurs when the web developer creates HTML which specifies a target frame which doesn't exist. Target frames are used by HTML to tell the browser which window to display a HTML page in when frames are in use. So imagine a user clicks on a link in the left hand frame of a two frame web page. The target frame tells the web browser to load the web page in the frame on the right hand side.
49. Test your web application with a test only browser to ensure that it is at least useable by one. Remember that there are statistics which suggest that up to 20% of the web community browses by default with graphics turned off.
50. Test your web application to ensure that it always uses text alternatives to graphics. You can see this by the text names that often appear before a graphic loads on a web page. You should use these text messages to entice a user to load the graphics for your web application.
51. Do NOT EVER use under construction icons on your web application. This looks very unprofessional and it is an understood fact that the web is always under construction.
52. Test your web application for links and options which do nothing. Don’t promise the end user upcoming information unless you can provide a solid time frame for them to check back. This will just frustrate the end user. (They will have ended up at your site through a search engine and now they will be mad because you don’t have information you promised through the search engine.)
53. Did you test your web application using dial up connections? Good Internet testing should include a report which gives a break down of load times for every web page under ISDN, 56K, 28.8K, 14.4K. (Include time for downloads of required plug-ins and custom controls.) You can use a null modem cable to do this testing if you don’t have enough modems, but set the speed of the null modem cable to the appropriate speed. (This will still be faster than a modem connection because of less line noise.)
54. Ensure that all company logos, trademarks, and products are appropriately copyrighted in your web application. Check with the marketing department of your company to get information about what needs to be protected.
55. Locate the source of all the images that web developers have used. Ask the developers to provide you with a list of image sources. Make sure that the images weren’t lifted from copyrighted sources. If you do copy an image from a web page, email and get permission. Most web sites won’t mind, but it is better to ask!