Section 1 Use Interface Testing 1.1 Site 1.2 Site Map and Navigation bar 1.

3 Site Content

Section 2 Functionality Testing 2.1 Application Specific 2.2 Cookies

Section 3 Interface Testing 3.1 Server 3.2 Error handling

Section 4 Compatibility Testing

Section 5 Load/Stress Testing

Section 6 Security Testing 6.1 General 6.2 Logins _____________________________________________________________________ __ *************** 1. User Interface Testing *************** 1.1 Site A. Easy to use B.

Instructions are simple and clear. Additionally, test that instructions are correct (i.e. if you follow each instruction does the expected result occur?)

1.2 Site map or navigation bar (if provided) A. Is the site map is correct? B. Does each link on the map actually exist? C. Are there links on the site that are not represented on the map? D. Is the navigational bar present on every screen? E. Is it consistent? F. Does each link work on each page? G. Is it organized in an intuitive manner?

1.3 Site Content A. Correctness of wording B. No overuse of bold text, big fonts and blinking (user acceptance testing) C. Hyperlinked references are working D. Are patterns, background colour and pictures distract the user? E. Does all images add value to respective page? F. Do these images waste bandwidth? In general use small pictures to reduce load. G. Does wrap-around occurs properly?

******************* 2. Functionality Testing ******************* 2.1 Application Specific A. Correctness of the functionality of the website i.e. the part that interfaces with the server and actually "does stuff. B. No internal and external broken links. C. User submitted information through forms, needs to work properly. In order to test this, verify that the server stores the information properly and that systems down the line can interpret and use that information. D. User input should get verified at system level according to business rules and error/warning messages should be flash to user for incorrect inputs.

2.2 Cookies If the system uses cookies, make sure the cookies work. . If cookies store login information, make sure the information is encrypted in the cookie file. If the cookie is used for statistics, make sure those cookies are encrypted too, Otherwise people can edit their cookies and skew information

******************* 3. Interface Testing ******************* 3.1 Server A. If site calls external servers for additional data, verify that the software can handle every possible message returned by the external server. B. To test browser and server interface, run queries on the database to make sure the transaction data is being retrieve and store properly.

3.2 Error Handling A. Make sure system can handle application errors. B. Make sure that system can handle other systems errors. e.g. losing the internet connection from server to the external server. C. How the transaction is handled, if user does not initiate interruption. ******************* 4. Compatibility Testing ******************* A. Operating systems B. Browsers C. Video settings D. Printers

******************* 5. Load/Stress Testing ******************* A. How many users at the same time can access without getting busy signal? B. Can system handle large amount of data from multiple users? C. Long period of continuous use: is site able to run for long period, without downtime. ******************* 6. Security ******************* 6.1 General A. Each directory should have an index.html or main.html page so a directory listing doesn't appear.

B. Historical pages should be removed from directories. 6.2 Logins A. In order to validate users, if site requires user to login; verify that the system does not allow invalid usernames/password. B. Is there a maximum number of failed logins allowed before the server locks out the current user? C. Verify rules for password selection. 6.3 Log Files A. Does the server log track every transaction? B. Does it track unsuccessful login attempts? C. What does it store for each transaction? (IP address and User name) 6.4 SSL A. If SSL is used, make sure that there is an alternate page for browser with versions less than 3.0, since SSL is not compatible with those browsers. B. Make sure that there are warnings when user enter and leave the secured site. C. Is there a timeout limit? D. What happens if the user tries a transaction after the timeout?

In my previous post I have outlined points to be considered while testing web applications. Here we will see some more details on web application testing with web testing test cases. Let me tell you one thing that I always like to share practical knowledge, which can be useful to users in their career life. This is a quite long article so sit back and get relaxed to get most out of it. Lets have first web testing checklist. 1) Functionality Testing 2) Usability testing 3) Interface testing 4) Compatibility testing 5) Performance testing 6) Security testing 1) Functionality Testing:

Test for - all the links in web pages, database connection, forms used in the web pages for submitting or getting information from user, Cookie testing. Check all the links:

Test the outgoing links from all the pages from specific domain under test. Test all internal links. Test links jumping on the same pages. Test links used to send the email to admin or other users from web pages. Test to check if there are any orphan pages. Lastly in link checking, check for broken links in all above-mentioned links.

Test forms in all pages: Forms are the integral part of any web site. Forms are used to get information from users and to keep interaction with them. So what should be checked on these forms?

First check all the validations on each field. Check for the default values of fields. Wrong inputs to the fields in the forms. Options to create forms if any, form delete, view or modify the forms.

Lets take example of the search engine project currently I am working on, In this project we have advertiser and affiliate signup steps. Each sign up step is different but dependent on other steps. So sign up flow should get executed correctly. There are different field validations like email Ids, User financial info validations. All these validations should get checked in manual or automated web testing. Cookies testing: Cookies are small files stored on user machine. These are basically used to maintain the session mainly login sessions. Test the application by enabling or disabling the cookies in your browser options. Test if the cookies are encrypted before writing to user machine. If you are testing the session cookies (i.e. cookies expire after the sessions ends) check for login sessions and user stats after session end. Check effect on application security by deleting the cookies. (I will soon write separate article on cookie testing) Validate your HTML/CSS: If you are optimizing your site for Search engines then HTML/CSS validation is very important. Mainly validate the site for HTML syntax errors. Check if site is crawlable to different search engines. Database testing: Data consistency is very important in web application. Check for data integrity and errors while you edit, delete, modify the forms or do any DB related functionality. Check if all the database queries are executing correctly, data is retrieved correctly and also updated correctly. More on database testing could be load on DB, we will address this in web load or performance testing below. 2) Usability Testing:

Test for navigation: Navigation means how the user surfs the web pages, different controls like buttons, boxes or how user using the links on the pages to surf different pages. Usability testing includes: Web site should be easy to use. Instructions should be provided clearly. Check if the provided instructions are correct means whether they satisfy purpose. Main menu should be provided on each page. It should be consistent. Content checking: Content should be logical and easy to understand. Check for spelling errors. Use of dark colors annoys users and should not be used in site theme. You can follow some standards that are used for web page and content building. These are common accepted standards like as I mentioned above about annoying colors, fonts, frames etc. Content should be meaningful. All the anchor text links should be working properly. Images should be placed properly with proper sizes. These are some basic standards that should be followed in web development. Your task is to validate all for UI testing Other user information for user help: Like search option, sitemap, help files etc. Sitemap should be present with all the links in web sites with proper tree view of navigation. Check for all links on the sitemap. Search in the site option will help users to find content pages they are looking for easily and quickly. These are all optional items and if present should be validated. 3) Interface Testing: The main interfaces are: Web server and application server interface Application server and Database server interface. Check if all the interactions between these servers are executed properly. Errors are handled properly. If database or web server returns any error message for any query by application server then application server should catch and display these error messages appropriately to users. Check what happens if user interrupts any transaction in-between? Check what happens if connection to web server is reset in between? 4) Compatibility Testing: Compatibility of your web site is very important testing aspect. See which compatibility test to be executed:

Browser compatibility Operating system compatibility Mobile browsing Printing options

Browser compatibility: In my web-testing career I have experienced this as most influencing part on web site testing. Some applications are very dependent on browsers. Different browsers have different

configurations and settings that your web page should be compatible with. Your web site coding should be cross browser platform compatible. If you are using java scripts or AJAX calls for UI functionality, performing security checks or validations then give more stress on browser compatibility testing of your web application. Test web application on different browsers like Internet explorer, Firefox, Netscape navigator, AOL, Safari, Opera browsers with different versions. OS compatibility: Some functionality in your web application is may not be compatible with all operating systems. All new technologies used in web development like graphics designs, interface calls like different APIs may not be available in all Operating Systems. Test your web application on different operating systems like Windows, Unix, MAC, Linux, Solaris with different OS flavors. Mobile browsing: This is new technology age. So in future Mobile browsing will rock. Test your web pages on mobile browsers. Compatibility issues may be there on mobile. Printing options: If you are giving page-printing options then make sure fonts, page alignment, page graphics getting printed properly. Pages should be fit to paper size or as per the size mentioned in printing option. 5) Performance testing: Web application should sustain to heavy load. Web performance testing should include: Web Load Testing Web Stress Testing Test application performance on different internet connection speed. In web load testing test if many users are accessing or requesting the same page. Can system sustain in peak load times? Site should handle many simultaneous user requests, large input data from users, Simultaneous connection to DB, heavy load on specific pages etc. Stress testing: Generally stress means stretching the system beyond its specification limits. Web stress testing is performed to break the site by giving stress and checked how system reacts to stress and how system recovers from crashes. Stress is generally given on input fields, login and sign up areas. In web performance testing web site functionality on different operating systems, different hardware platforms is checked for software, hardware memory leakage errors, 6) Security Testing: Following are some test cases for web security testing:

Test by pasting internal url directly into browser address bar without login. Internal pages should not open. If you are logged in using username and password and browsing internal pages then try changing url options directly. I.e. If you are checking some publisher site statistics with publisher site ID= 123. Try directly changing the url site ID parameter to different site ID which is not related to logged in user. Access should denied for this user to view others stats. Try some invalid inputs in input fields like login username, password, input text boxes. Check the system reaction on all invalid inputs. Web directories or files should not be accessible directly unless given download option. Test the CAPTCHA for automates scripts logins. Test if SSL is used for security measures. If used proper message should get displayed when user switch from non-secure http:// pages to secure https:// pages and vice versa. All transactions, error messages, security breach attempts should get logged in log files somewhere on web server.

Web Application - Functional Testing Checklist Templates - Checklist Guidelines Testing web application is certainly different than testing desktop or any other application. With in web applications, there are certain standards which are followed in almost all the applications. Having these standards makes life easier for use, because these standards can be converted into checklist and application can be tested easily against the checklist. 1. FUNCTIONALITY 1.1 LINKS 1.1.1 Check that the link takes you to the page it said it would. 1.1.2 Ensure to have no orphan pages (a page that has no links to it) 1.1.3 Check all of your links to other websites 1.1.4 Are all referenced web sites or email addresses hyperlinked? 1.1.5 If we have removed some of the pages from our own site, set up a custom 404 page that redirects your visitors to your home page (or a search page) when the user try to access a page that no longer exists. 1.1.6 Check all mailto links and whether it reaches properly 1.2 FORMS 1.2.1 Acceptance of invalid input 1.2.2 Optional versus mandatory fields 1.2.3 Input longer than field allows 1.2.4 Radio buttons 1.2.5 Default values on page load/reload(Also terms and conditions should be disabled) 1.2.6 Is Command Button can be used for HyperLinks and Continue Links ? 1.2.6 Is all the datas inside combo/list box are arranged in chronolgical order?

1.2.7 Are all of the parts of a table or form present? Correctly laid out? Can you confirm that selected texts are in the "right place? 1.2.8 Does a scrollbar appear if required? 1.3 DATA VERIFICATION AND VALIDATION 1.3.1 Is the Privacy Policy clearly defined and available for user access? 1.3.2 At no point of time the system should behave awkwardly when an invalid data is fed 1.3.3 Check to see what happens if a user deletes cookies while in site 1.3.4 Check to see what happens if a user deletes cookies after visiting a site 2. APPLICATION SPECIFIC FUNCTIONAL REQUIREMENTS 2.1 DATA INTEGRATION 2.1.1 Check the maximum field lengths to ensure that there are no truncated characters? 2.1.2 If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers? 2.1.3 If a particular set of data is saved to the database check that each value gets saved fully to the database. (i.e.) Beware of truncation (of strings) and rounding of numeric values. 2.2 DATE FIELD CHECKS 2.2.1 Assure that leap years are validated correctly & do not cause errors/miscalculations. 2.2.2 Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations. 2.2.3 Is copyright for all the sites includes Yahoo co-branded sites are updated 2.3 NUMERIC FIELDS 2.3.1 Assure that lowest and highest values are handled correctly. 2.3.2 Assure that numeric fields with a blank in position 1 are processed or reported as an error. 2.3.3 Assure that fields with a blank in the last position are processed or reported as an error an error. 2.3.4 Assure that both + and - values are correctly processed. 2.3.5 Assure that division by zero does not occur. 2.3.6 Include value zero in all calculations. 2.3.7 Assure that upper and lower values in ranges are handled correctly. (Using BVA) 2.4 ALPHANUMERIC FIELD CHECKS 2.4.1 Use blank and non-blank data. 2.4.2 Include lowest and highest values. 2.4.3 Include invalid characters & symbols. 2.4.4 Include valid characters.

2.4.5 Include data items with first position blank. 2.4.6 Include data items with last position blank.

Guidelines and Checklist for Website Testing

1. Functionality:
1.1 Links

Objective is to check for all the links in the website. 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.2 All Internal Links All External Links All mail to links Check for orphan Pages Check for Broken Links Forms

Test for the integrity of submission of all forms. 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.2.6 1.3 All Field Level Checks All Field Level Validations. Functionality of Create, Modify, Delete & View. Handling of Wrong inputs (Both client & Server) Default Values if any Optional versus Mandatory fields. Cookies

Check for the cookies that has to be enabled and how it has to be expired. 1.4 Web Indexing

Depending on how the site is designed using Meta tags, frames, HTML syntax, dynamically created pages, passwords or different languages, our site will be searchable in different ways. 1.4.1 1.4.2 1.4.3 1.5 Meta Tags Frames HTML syntax. Database

Two types of errors that may occur in Web applications: A. Data Integrity: Missing or wrong data in table. B. Output Error: Errors in writing, editing or reading operations in the tables.

The issue is to test the functionality of the database, not the content and the focus here is therefore on output errors. Verify that queries, writing, retrieving or editing in the database is performed in a correct way.

2. Usability:
2.1 Navigation

Navigation describes the way users navigate within a page, between different user interface controls (buttons, boxes, lists, windows etc.), or between pages via e.g. links. 2.1.1 2.1.2 2.1.3 2.1.4 2.2 Application navigation is proper through tab Navigation through Mouse Main features accessible from the main/home page. Any hot keys, control keys to access menus.

Content

Correctness is whether the information is truthful or contains misinformation. The accuracy of the information is whether it is without grammatical or spelling errors. Remove irrelevant information from your site. This may otherwise cause misunderstandings or confusion . 2.2.1 2.2.2 2.3 Spellings and Grammars Updated information

General Appearance 2.3.1 2.3.2 2.3.3 2.3.4 Page appearance Color, font and size Frames Consistent design

3. Server Side Interfaces:

3.1 Server Interface 3.1.1 3.1.2 3.1.3 3.2 Verify that communication is done correctly, Web server-application server, application server-database server and vice versa. Compatibility of server software, hardware, network connections. Database compatibility (SQL, Oracle etc.)

External Interface (if any)

4. Client Side Compatibility:

4.1 Platform

Check for the compatibility of a. Windows (95, 98, 2000, NT) b. Unix (different sets) c. Macintosh (If applicable) d. Linux e. Solaris (If applicable) 4.2 Browsers

Check for the various combinations:

Internet Explorer (3.X 4.X, 5.X) Netscape Navigator (3.X, 4.X, 6.X) AOL Browser settings (security settings, graphics, Java etc.) Frames and Cascade Style sheets Applets, ActiveX controls, DHTML, client side scripting HTML specifications. Graphics: Loading of images, graphics, etc., 4.3 Printing

Despite the paperless society the web was to introduce, printing is done more than ever. Verify that pages are printable with considerations on: a. Text and image alignment b. Colours of text, foreground and background c. Scalability to fit paper size d. Tables and borders

5. Performance:
5.1 Connection speed

a. Try with Connection speed: 14.4, 28.8, 33.6, 56.6, ISDN, cable, DSL, T1, T3 b. Time-out 5.2 Load

Check/Measure the following: a. What is the estimated number of users per time period and how will it be divided over the period? b. Will there be peak loads and how will the system react? c. Can your site handle a large amount of users requesting a certain page? d. Large amount of data from users. 5.3 Stress

Stress testing is done in order to actually break a site or a certain feature to determine how the system reacts. Stress tests are designed to push and test system limitations and determine whether the system recovers gracefully from crashes. Hackers often stress systems by providing loads of wrong in-data until it crash and then gain access to it during start-up. a. Typical areas to test are forms, logins or other information transaction components. b. Performance of memory, CPU, file handling etc. c. Error in software, hardware, memory errors (leakage, overwrite or pointers) 5.4 Continuous use

a. Is the application or certain features going to be used only during certain periods of time or will it be used continuously 24 hours a day 7 days a week? b. Will downtime be allowed or is that out of the question? c. Verify that the application is able to meet the requirements and does not run out of memory or disk space.

6. Security:
6.1 6.2 6.3 6.4 6.5 6.6 Valid and Invalid Login Limit defined for the number of tries. Can it be bypassed by typing URL to a page inside directly in the browser? Verify Log files are maintained to store the information for traceability. Verify encryption is done correctly if SSL is used (If applicable) No access to edit scripts on the server without authorization.

Checklist before hosting a website:

** Enter Not Applicable whichever test not carried out. Test Carried out 1. Functionality 1.1 Links Internal Links External Links Mail to links Orphan pages Broken links Expected Actual Remarks Ticket Reference

Should be present Should be present Should open mailbox Should not be present Should not be present

1.2 Forms Field Level checks Checked for length, special characters, numerical characters etc., Field Level Checked Unique Validation records, Date validation Functional checks Create, modify, view and delete are working. Error Handling for Appropriate error wrong inputs or messages to be actions. displayed. Optional and Mandatory field mandatory fields. should not be left blank. Optional should allow the user to skip the field. 1.3 Cookies Check whether cookies are enabled. 1.4 Web Indexing Meta tags Html Syntax Frames 1.5 Database Data Integrity

**Depends on project

Should be present. Should be valid To be found ok

Output Errors

Should not be any missing or wrong data in the database Errors in writing, reading or editing operations should not be present

2. Usability

2.1 Navigation Navigation through Mouse Navigation through Tab Main features access Hot Keys, Control Keys for menu or action 2.2 Content Spelling and Grammar Updated informations.

Should be proper Should be proper Should be accessed from home/Main page Should be present

To be proper Past events/ informations to be removed.

2.3 General Appearance Page Appearance

Should not be any overlapping, missing etc., Colour, font and Should be as per size standard Frames All frames to be appeared Consistent Design Everywhere in the website consistent layout and design should be carried out. 3. Server Side Interface 3.1 Server Interface

Compatibility with server hardware, Sw, network connections Database compatibility[s1]

Communication should be correct with respect to Web server, App server and DB server Should be proper.

Should be easily portable to other database.

4. Client side Compatibility 4.1 Platform Windows2000, NT Unix Linux Solaris Macintosh

Should be working Should be working Should be working Should be working Should be working

4.2 Browsers I.E Netscape Navigator AOL Any ActiveX controls Graphics

Should work in all versions above 4.x Should work in all versions above 3.x

Load of images, graphics should be proper

4.3 Printing Text and alignment Colours of text, foreground and background Scalability to fit paper size. Tables and borders. 5. Performance 5.1 Connection speed Should be measured in 14.4, 28.8, 33.6, 56.6, ISDN, Cable and DSL Timeout Should be proper Should be readable. Should print in A4, Letter size. Should be proper.

Should give appropriate time to search. Incorrect message, data loss should not be present.

5.2 Load Estimated users. Peak load Large amount of data from users 5.3 Stress System Crash Error in Sw, HW, Memory

Per requirements Should withstand Should accept

Should not be present Leakage, overwrite should not happen.

5.4 Continuous use Estimate whether Try with various available for 24 timings. Hrs, 7 days a week

Downtime Memory or disk space

Measure the downtime Should not run out of memory or disk space.

6. Security 6.1 Valid and Invalid Number of tries Enter url directly without logging in. Log files Access to server scripts

Should not enter with Invalid login Should not be more than 3 times for invalid try. Should not display information. Should be maintained Authenticated.

The Ultimate Testing Checklist

By Shirley Kaiser
July 26th, 2006 Reader Rating: 8.5 Page: 1 2 Next Testing plays a critical role in the development of your web site and its long-term maintenance. While smaller web sitesespecially those with more limited budgetsmay not need to follow the formal testing procedures that are required for large-scale, commercial web sites, every site needs to be thoroughly tested to ensure that it's error-free, user-friendly, accessible, and standards compliant. Testing should be completed during each phase of a site's development. Two of the most costly web project mistakes are to delay testing until just before launch, or not to

test at all. Testing during production makes it easier to locate and resolve errors, and minimizes the chance of existing bugs being replicated throughout later stages of development. Early and continued testing can eliminate the need for the costly redesigns and other major fixes that can result from overlooked errors. This chapter's checklists, extracted from SitePoint's new release, Deliver First Class Web Sites: 101 Essential Checklists, will help you test your site both during development, and after. Download this checklist, along with others covering SEO and content management -- you'll also receive .pdf versions of the documents for immediate use in your web projects.

Getting Started
Document your baseline web site testing requirements. Make use of the preliminary data you collected in Chapter 2 to help determine and document your baseline site testing requirements. For instance, the information you collected on the browsers and connection speeds that your visitors will use, and those visitors' skills and age groups, can be used as a basis for your testing plan.

Source and install all necessary tools. You can conduct tests very cheaply using free and low-cost testing tools. Most browsers are free or offer conditionally free versions, and you can download and install multiple browsersincluding several versions of Internet Explorer for Windowson one computer. Alternative device simulators and emulators, such as those for cell phones and PDAs, can also be downloaded and used for free, and most shareware and commercial software creators allow a 30-day trial of their products for testing purposes. Some web design-related discussion lists, as well as the SitePoint Forums, welcome testing requests and posts that solicit bug reports and feedback. Provide acceptable testing protocols.

Ultimately, the design and layout for each page of the site must be both aesthetically pleasing and functionalacross multiple platforms and browsers. One of the difficulties associated with testing design elements on different platforms is that the test results can be subjective. For example, a designer may create a CSSdriven site that works perfectly on newer browsers, but doesn't look that hot in older browsers such as Netscape 4. The tester may interpret this as a failure point rather than acceptable "design degradation." To avoid the time and effort involved in re-submitting pages for testing, spell out acceptable cross-browser, cross-platform differences in advanceincluding protocols for supporting old browsers. Use Annotated Screenshots to Determine Display Protocols At the end of the final prototyping stage, ask the designer to provide a series of screenshots that have been annotated to identify the differences in the ways the site displays on different browsers and platforms. These screenshots can be used in later testing to identify the displays that are deemed acceptable on each platform. Testers can then compare the protocols and screenshots with their findings. Set up a staging server. A staging or test server that's identical to your web site's live server environment should be used for testing and development purposes prior to your site's launch. Automated Programs for Larger Sites Larger web sites typically require more robust testing procedures that test large sets of records, values, and content. You might consider using an automated program, such as Badboy, eValid, or TestComplete for such purposes.

Good Testing Practice

Systematically test individual pages. Thoroughly test your site one page at a time, making sure each page is solid before proceeding. Carry out a comprehensive test of the final version of the site in the same way. Track bugs and confirm fixes. Document the details of discovered bugs and their resolutions. Regression test, especially when fixing bugs. Regression testing, which is also known as verification testing, is the process of retesting pages or sections of a site to make sure that a recent bug fix hasn't broken some other aspect of the site, or reinstated bugs that were fixed previously. Conducting and documenting regression tests will allow you to identify any parts of the site that break, and document the causes of those errors and how you resolved them. If a bug resurfaces at some point, it will be spotted immediately and resolved quickly. (See Regression Testing, Webopedia Computer Dictionary).

Validate the markup for each individual web page. Validate the markup for all your web pages to ensure that each uses structural, compliant markup. This will allow you to confirm that you've used the correct markup for the specified DOCTYPE, fix any typos you may have made, and resolve any syntax errors. Validating your markup as you build a page, rather than waiting until you've created an entire page (or worse, an entire web site), makes it easier to isolate, find, and correct markup problems. Using Markup Validators Some HTML editors integrate validation tools such as W3C's HTML and CSS validators, the WDG HTML Validator, and the CSE HTML Validator (an HTML/XHTML syntax checker and validator), which allow you to validate your markup conveniently while you work. The CSE and WDG HTML Validators also include helpful batch processing features. So, for example, although I validate each page with the CSE HTML Validator and the W3C's validators as I work, I use CSE HTML Validator's batch processing to recheck multiple pages simultaneously. I also use batch processing as a final check when I've finished developing all the pages of the site. Ensure that the validation tool you use is based on W3C Recommendations. Validate all CSS. Validate all the CSS you use on the site, including each external style sheet, plus all embedded and inline CSS. Conduct load testing to stress-test programming technologies and server hardware capacities. You need to make sure that the programming technologies you've used, and the capacities of your server hardware, can cater to higher levels of traffic than you expect the site to receive. Taking this approach will help you ensure that your site remains online and fully functional at all times. Load testing procedures should include a trial runtests that usually involve the use of automated scripts that emulate multiple simultaneous user sessions. The trial run will reveal how the programming technologies and server hardware you've used will cope with traffic spikes. Matching Hosting with Projected Server Loads Your ISP should match your hosting package with your projected server loads if you're using a web hosting service, so you should let them know what your loads will be. Your web host might recommend a different web hosting package that offers greater capacity if your load testing reveals that your existing setup has the potential for problems as traffic levels increase. If you're managing your own server(s), check whether your server software provider offers free load testing softwaremany do. You might also consider using dedicated load-testing software products, such as those offered by WebPerformance and NetMechanic. In addition, numerous open-source performance analysis software

tools are available to help you assess, monitor, and manage your web site's performance. (See also Stress Tools to Test your Web Server, Microsoft.com.)

General Testing
Test your web site on multiple browsers and platforms. The fact that your web site looks good and works well in one browser doesn't mean it will look as good or function as well on other browsers and/or platforms. Even if you're developing an intranet web site for an organization whose employees use the same browser and operating system, the hardware and software used by those employees can and will vary. In the long run, it's better to develop your web site on the basis of the W3C recommendations, then to follow up with extensive crossbrowser, cross-platform testing. Stay informed of the release of new or updated browsers and operating systems so that you can keep your cross-browser, crossplatform tests current. Which Browsers and Platforms to Test? Check your server logsas well as other on- and offline resourcesthat cover browser statistics, operating systems, and emerging Web use trends, so that you know which browsers, versions, and operating systems your web site visitors use now, and are likely to use in future. As part of your approach to site maintenance in the long term, plan to check your server logs weekly (monthly checks might be fine if you run a smaller web site with low traffic volumes) to follow changes and trends in your browser statistics. Take this data into account as your hone you your cross-browser, cross-platform testing procedures, to ensure that you're testing all of the browsers and operating systems that your visitors use. Here's a list of the popular operating systems and browsers on which you might test your site. Operating systems

Macintosh OS X Macintosh OS 9 Windows XP SP1 and SP2 Windows 2000 Windows 98 Linux

Browsers for Macintosh OS X

Safari 1.2 Mozilla 1.6 Firefox 1.0 Opera 9 Opera 8 Opera 7 Internet Explorer 5.2

Browsers for Macintosh OS 9

iCab Internet Explorer 5

Browsers for Windows XP

Opera 9 Opera 8 Opera 7 Mozilla 1.7 Firefox 1.0 Netscape 7.1 Internet Explorer 6.0 Lynx browser

Browsers for Windows 2000

Opera 9 Opera 8 Opera 7 Mozilla 1.7.3 Firefox 1.0 Netscape 7.1 Netscape 7.0 Netscape 6.2 Netscape 4.78 Internet Explorer 6 Internet Explorer 5.5 Internet Explorer 5.0 Lynx browser

Browsers for Windows 98

Internet Explorer 4.0 Lynx browser

Browsers for Linux

Konqueror 3.0.5 Mozilla 1.6 Opera 8 Opera 7 Emacs/W3 Netscape 7 Netscape 4.8

Test page optimization with every update.

Optimizing your pages right from the start can help ensure that your site design and images support fast page load times, and that the site's development is smooth and efficient. Whenever you add anything to your web sitenew content, new images, or new web pagescheck that content's optimization to help keep the site streamlined. If you're not yet familiar with web site optimization, see Chapter 11, Web Site Optimization. Document Weight and Load Time Tools Some HTML editors include features that tell you a document's weight, or a page's load time at various connection speeds, and most image editing software products indicate file size load times at various connection speeds. There are also free online tools that calculate document weight, composition, and page load times, and even offer recommendations for optimizing web documents. Siteoptimization.com's helpful Web Page Analyzer is one such tool. View pages on a variety of displays. You may find that your beautiful design, which is wonderfully contrasted on an LCD monitor, is impossible to read on a CRT monitor, and completely unusable on alternative devices. Different displays will not always interpret your site's design and colors consistently, so it's worth testing your initial design, as well as the site's ongoing development, in a variety of displays. View pages on different screen resolutions and with various color settings. Some HTML editors provide a feature that allows you to check your pages at various screen resolutions and with a range of color settings. Similar tools can also be downloaded as plug-ins for some browsers. For example, the highly recommended Web Developer Toolbar extension for Firefox includes a customizable window resizing tool, among many other useful features. (For more on Firefox's tools for web developers, see Chris Pederick's article, Web Developer Extensions for FireFox and Mozilla.) Consider Nonstandard Resolutions Screen display sizes may or may not reflect the actual dimensions of the viewable web page. Many users don't expand browser windows to fill the entire screen (especially on larger monitors), and various toolbars and side panels can take up portions of the screen width and height. For example, on an 800x600 display, a browser that has a side panel and a couple of custom toolbars across its top would display only 500x400 pixels of a web pageless if the browser window isn't maximized. Be sure to conduct testing that accounts for this wide range of variabilitynot just the standard maximum screen resolutions. Table 14.1, which shows screen resolutions of various devices, and Table 14.2, which shows the color depth settings of different displays, should help your testing.

Table 14.1. Typical screen resolutions and displays (in pixels)

[a] Lisa Gade, palmOne Treo 650 Palm OS Smartphone, Mobile Tech Review (December 10, 2004). Table 14.2. Typical display color depth settings

[a] Browser Statistics: What Is the Trend in Browser Usage, Operating Systems and Screen Resolution? W3Schools (January 2005). [b] What is a Pocket PC (PPC)? What models are out there? Mobile Tech Review (no date). In addition to the displays mentioned in Table 14.1 and Table 14.2, there are standalone toolssuch as BrowserCam, an online subscription servicewhich provide screenshots depicting the way your content will appear in a wide range of screen resolutions and browsers. Check for adequate color contrast. A good way to check color contrast is to change your browser display to grayscale, or print the web page in black and white. A tool that can be very helpful for checking your design's color contrasts is Vischeck, which simulates colorblind vision, allowing you to see your pages as a colorblind user might. Test the functionality of external and embedded scripts and functions. Some scripts and functions might work fine in one browser, though they may not work correctly, if at all, in other browsers or devices. Minor tweaking can resolve many cross-browser, cross-platform functionality issues. If older browsers or alternative and adaptive technologies don't support some functions, you may wish to provide alternative methods to allow those users to access those capabilities some other way. Test all links, including navigation. Ensure that all links work properly, and point to the correct location. Link checking software can check for valid, broken, and redirected links. Some HTML editors, such as Macromedia Dreamweaver and HomeSite, offer link checking capabilities. Free

tools are also availabletry Xenu's LinkSleuth and W3C Link Checker. See WebsiteTips.com's section, "Link Checkers, Maintenance" for more. Note, though, that link checkers aren't intuitive enough to check whether links direct to the correct locationbe sure to check for this manually. Check error pages. Intentionally enter incorrect URLs into the browser's address bar to check that the appropriate error pages (404 errors, etc.) are in place. Make sure that the error pages include helpful information and links that help users find what they seek. Keep in mind that, sometimes, visitors will incorrectly guess a domain name or slightly misspell a URL. Help those visitors by accepting common misspellings, typos, incorrect case sensitivity, different terminology for the same items, and predictable domain name errors: provide suggestions to redirect users to the proper page. (Matthew Linderman with Jason Fried, Defensive Design for the Web: How to Improve Error Messages, Help, Forms, and Other Crisis Points (Indianapolis: New Riders, 2004), 99, 224.) Test all downloads. Check to ensure that all your download links point to the correct files, and that the download files exist. Test the search feature Ensure that the search feature functions correctly, and that search results are accurate and helpful. Solid Security Clear your Cache! Be sure to clear the browser cache, including cookies, before each test. Check that digital certificates and SSL URLs work correctly. Your SSL URLs should begin with https://. Also, when a visitor accesses a web page protected by SSL, most browsers will show a "lock" icon at the bottom of the browser, like that being shown by IE 6 for Windows in Figure 14.1. Figure 14.1. The "lock" icon displaying at the bottom of the browser window

SSL is commonly used to encrypt online transactions and other sensitive data, as well as intranets and extranets. Verisign and Thawte are two popular companies that issue SSL certificates. Check that all pages requiring SSL access are accessible only via SSL. Test the security of restricted areas. Users might share or try to guess the URLs of content and downloads in protected areas of your site. Restricted content URLs might appear within publicly available referrer logs. People might even share usernames and passwords without authorization or permission. As such, it's critical that you anticipate the kinds of security breaches that might take place, and test methods for their prevention. Hack your Site: the Ultimate Security Test Download popular hacking tools to use in testing, to see if your protected areas can easily be comprised. Those managing larger-scale web sites might even consider outsourcing or hiring a hacking expert for testing purposes. Ensuring security and data integrityespecially in terms of your confidential data, including customer credit card informationis critical for promoting and maintaining trust among your site's visitors. Don't assume that your web site's security is always okay. Test regularly to make sure it remains secure. Test forms and form controls. Check to ensure that forms are submitted correctly, and that they're only submitted when the correct information is entered and required fields have been completed. Review form error messages to ensure that they are helpful and informative within the context of the form itself. Test online shopping facilities. If your web site includes a shopping cart or similar functionality, thoroughly test back-end operations to ensure that all transactions are secure, and everything runs smoothly.

Testing Web applications for security vulnerabilities can be exciting. There are neat tools and interesting ways you can make a Web application hiccup, crash or otherwise give out information you shouldn't be able to see. As fun as it may be, testing your Web application security is also something that needs be taken seriously. The best way to be successful is to prepare in advance and know what to look for. Here's an essential elements checklist to help you get the most out of your Web application security testing.

Set everyone's expectations The Golden Rule of performing security assessments is to make sure that everyone affected by your testing is on the same page. Start by working with your project sponsor (i.e., CIO, VP of audit, IT director or compliance manager) and determine the business goals for what you're doing. It sounds trite, but it's important that everyone understands what outcomes are expected and what the next steps will be. It's also extremely important to select testing dates and timeframes that will minimize the impact on the business. There'll likely never be an ideal time, so go for the next best thing by figuring out when the network bandwidth and processor cycles consumed by your testing will hurt the least. Also, don't be afraid to tell others that problems such as locked accounts, performance hits and server reboots may occur. Better to get it out on the table now rather than let it fester and become a major issue later when people are caught off guard. Finally, keep people in the know during your testing and follow up with them when you're done to share how things transpired, what was found, and what they may need to do to help fix any security vulnerabilities. Gather good tools As with all things security-related, your tools will make or break your assessments. In fact, the number of legitimate vulnerabilities discovered is directly proportional to the quality of your security tools. There are several open source Web application testing tools that I depend on in my work -- most of which are available in the BackTrack suite of tools. Outside of that, you usually get what you pay for. There are low-cost Web application security testing tools and several others with much higher price tags. I've found out the hard way that, by and large, high-end equals high quality. Good tools translate into more (and more complex) security flaws discovered, as well as less time and effort wasted trying to track them down. The reporting capabilities of commercial tools are unmatched as well. The tools I've come to depend on are HP's WebInspect and Acunetix Web Vulnerability Scanner. When I can I use both tools, because they tend to find different things that I don't want to overlook. Keep in mind that tools aren't everything, though. (There's more on this below.) Look at your application from every perspective Perform a reconnaissance on your Web application and see what the world can see using Google and its hacking tools such as Foundstone's SiteDigger. Odds are you won't find a lot of stuff, but you'll never know until you check. Next, run a Web vulnerability scanner such as the ones I mentioned above. Where you can, be sure to run your scans as both an unauthenticated and untrusted outsider as well as an authenticated and trusted user (via basic HTTP, NTLM or form authentication). Web abuse knows no boundaries. By looking at your application from different angles, you'll undoubtedly find different types of vulnerabilities that can be exploited from both outside and inside your network. With your authenticated scans, test out every role level or user type if possible, since some vulnerabilities will be available only to users with certain privileges.

Test for underlying weaknesses One of the most commonly overlooked areas of Web application testing is failing to scan the underlying operating system and installed applications. With tools such as Nessus and QualysGuard, you'll be able to root out problems such as missing patches and misconfigurations in your operating system and other software you have installed (including the Web server itself) that can lead to a Web application compromise. If you want to get the entire picture, you should also look at your back-end databases and related network infrastructure systems. A single weakness outside of the Web application that's overlooked can put everything at risk. Go back and verify your scanner findings As much as the marketing machine wants us to think that security testing tools are void of any shortcomings, they aren't. Don't believe what you see and hear. Get in and validate that the security weaknesses they discovered are legitimate. Validating and reporting on genuine security vulnerabilities in the proper context will save everyone time and effort in the long run. It will also instill confidence in others and make them want to take you seriously. Verifying your results simply requires going back to your original scanner data or exported reports and seeing if you can reproduce the problems the tools found. For certain issues, you may need only a simple Web browser for validation. For others, you may need the power of a Web proxy tool or HTTP editor, such as the free Paros proxy tool or the tools bundled with many commercial scanners. Check to see if you can reproduce the problem. If you can, take a screenshot of your findings and stick it in your report. If you can't and you're confident it's a false-positive, move on to the next issue

Manually check for weaknesses Don't stop now. Your security testing tools may have uncovered a lot of weaknesses in your Web application, but there are likely several more things left to exploit. This is where your human context and Web usage expertise come into play. Get in and poke around in the application a bit more to see what else can be done from a malicious point of view. I can't tell you how many times I've found flaws in login mechanisms, form input validation and sensitive information buried in HTML and server directories that automated tools would never uncover. Test your source code Until you look at your Web application's source code, you won't be able to say with conviction that everything's been tested. Sure, timing, politics and the old security budget tend to overshadow what's important in a situation like this. At least make it a priority on your to-do list for the next go around. Source code analysis tools have matured greatly over the past few years, and they're not just for developers anymore. Tools such as DevInspect and Checkmarx can help both developers and security professionals check for software flaws at the source. I'll admit, static analysis tools are not the simplistic point and click tools that general Web application vulnerability scanners are -- especially when setting things up and

getting the source code loaded in. But once you get rolling, they are easy to use and can find flaws that you'd likely never know about until someone exploited them. With the detailed findings and beneficial reports that these tools can produce, more and more I'm hearing seasoned developers say such things as, "Interesting -- I hadn't thought about that." Plan your testing, cover all your bases when looking for flaws, and -- most important of all -- use good old-fashioned common sense and you're sure to improve your Web application security.

Website Checklist
So your new web-site looks wonderful. Nice colours, gorgeous images, lots of interesting content. And the Javascript is finally debugged. So its ready for public viewing? Well, based on a lot of the web-sites Ive seen, probably not yet! Here is a checklist of things to run though before going public with your web-site. Most of them are things which seem to have been overlooked by large numbers of web developers. This checklist is oriented towards matters which can be more or less objectively determined. It does not attempt to cover matters which are very subjective, such as clarity of layout or text, though these are of course just as important. It covers only matters which affect the readability of your site not those which affect how easy it will be for you to maintain it. A useful resource to help with further checking of your site, including the more subjective matters, is the alt.html.critique Usenet newsgroup.

The Checklist
The links in the checklist lead to a discussion of each issue. 1. Validation 1. Validate the HTML 2. Validate the CSS 3. Check for broken links 2. Flexibility 1. Try varying window sizes 2. Try varying font sizes 3. Speed 1. Access the site via a modem 2. Check image size specifications 4. Accessibility 1. Test accessibility 2. View in text browser

5. Browser independence 1. Try different browsers 2. Check printed pages 3. Switch Javascript off 4. Switch plug-ins off 5. Switch images off 6. Other checks 1. Check non-reliance on mailto 2. Check no orphan pages 3. Check sensible page titles

Validation
Validate the HTML
The first stage of checking a web-site is to make sure that you have valid HTML (or XHTML). This can be done with a validator such as the W3C validator or WDG validator. Your own browser may ignore certain errors, but there is a significant risk that markup errors will result in display problems in some browser or other. There are sometimes reasons for including invalid HTML. For example some pages on my own site use the non-standard NOINDEX element, for the benefit of my site search engine. But you should only tolerate HTML validation errors if there is a clear need for the non-standard markup, and if you have tested the result in a variety of browsers.

Validate the CSS

CSS can be validated with for example the W3C CSS validator. The considerations here are much the same as HTML validation. It may sometimes be necessary to use something non-standard to get Internet Explorer to work, but such rules can be placed in a separate CSS file and hidden in an Internet Explorer conditional comment, where they wont bother other browsers or a validator.

Check for broken links

Obviously you dont want broken links on your site. There are various tools available to help find these, such as the Link Valet (which is convenient for checking a few pages) or Xenulink (convenient for checking a whole site).

Flexibility
Try varying window-sizes
A very important aspect of web design is coping with different window sizes. Window widths may vary from about 200 pixels on a web-enabled telephone to 2000+ pixels on a technical workstation in full-screen mode. While providing a readable site to the very smallest screens is something of a challenge, your site should at least be readable on a wide variety of sizes. As of mid 2006, nearly 20% of all

readers are still using screens of 800x600 pixels or smaller, and if the reader wishes to compare the contents of your site with another document, it is entirely possible that he/she may want to use a window-width of around 400 pixels. Fortunately, at least as far as the text goes, this is not very difficult just refrain from specifying sizes in pixels or points and you are most of the way. See my flexible design page for further thoughts. It is obviously easy to test window-sizes smaller than your own screen-size. Testing larger window-sizes might seem impossible, but you can do a rough simulation using the zoom facility of the Opera browser zoom down to 50% and you get a screen twice the size. It may not be very readable, but any major layout errors should be obvious. Incidentally dont worry too much about the very long lines of text that appear at large screen sizes when small fonts are used. If the reader doesnt use a large font, he can always reduce the window size to something comfortable that is, after all, half the point of having windowing user interfaces in the first place. But if you wish to, you can also use the CSS2 max-width property to limit column width, just as this page does. (Only discerning readers are currently able to benefit from this, as IE does not support it. Rumour has it that it will finally appear in IE 7 I suppose eight years late is better than never.)

Try varying font sizes

Some people use large screen fonts because they have a large screen with a very fine resolution; other people have to use large screen fonts because of declining eyesight. On the other hand, some people like to use microscopic fonts with their nose pressed against the screen (it takes all sorts...) So while doing the above activity, adjust the default text-size in your browser, and check that all the text scales appropriately. (You did specify the text size in ems or %, didnt you? If not, see my font-size page.) One other aspect to consider is that users may impose a minimum font size to make sure that all text is readable for them. This means that font sizes show a smaller range than you had in mind. If you have a complex page with a wide range of font sizes, it would be worth imposing a minimum size larger than your smallest font (this can be done in e.g. Opera or Firefox) and checking that this does not make parts unreadable.

Speed
Access the site via a modem
So you think you have a great site, full of beautiful images. Put your site on the server, then dial in via a modem (a real modem not an ADSL gateway, which is sometimes erroneously referred to as a modem). Does it look so good half a minute later? Or are you still staring at a pretty-much blank screen?

If the opening page of your site takes more than about 15 seconds to appear, then you are losing visitors fast. (Broadband users generally expect a still faster response.) Dont overload it. If you have to include large objects on your site perhaps it revolves around high-resolution reproductions of fine art put them on later pages and tell (or warn?) your users what is coming. Web developers generally have broadband access, and they sometimes forget that the majority of the world's internet connections still run via a modem. Yes, more and more people are getting broadband, but the number of people without it is still large, and many people in rural areas, let alone developing countries, simply cant yet get broadband. By the way, dont make the mistake of assuming that you dont have to worry about bandwidth issues if your site is mainly aimed at companies. I have more than once worked at companies which did have a broadband connection, but had it shared between so many users and applications that the net result was scarcely faster than a dial-up modem.

Check image size specifications

While doing the test above, check that at least the text of the page appears quickly. If it doesnt (or if it dances all over the place while the page is loading) it is probably because you have forgotten to specify HEIGHT and WIDTH attributes on some of your images. Specifying these enables the browser to work out where the text needs to go, and to display it before the images have finished downloading.

Accessibility (for the disabled)

Since I first wrote this page, it has been pointed out to me that actually most of the page is about accessibility: that is, ensuring that a web page is accessible under a wide range of browsing conditions. However accessibility is often used in the narrower sense I use in this section.

Test accessibility
This is mainly important for handicapped users, but also relevant for e.g. people who use a text-only browser, or disable images, because of a slow connection. See the Web Content Accessibility Guidelines. Automated accessibility checking does need to be taken with a pinch of salt. Many aspects of the guidelines require human judgement to say whether a page is accessible or not for example whether HTML Heading tags are used correctly. And even when the guidelines are unambiguous, you dont need to follow them slavishly. For example the absence of a caption on a table is unimportant if the previous paragraph explained what the table is about. Nonetheless it is well worth running a few pages through a checker such as Bobby or Accessibility Valet in order to familiarise yourself with the issues involved. You can then make the necessary improvements.

View in text browser

It is also worth running pages through a text-only browser, or text-browser emulator to see what e.g. a blind person using a text-to-speech converter will encounter. It will help you pick up on badly-chosen or missing ALT texts for example. It also shows you the site pretty much as a search engine will see it. Incidentally the Opera browser has a built-in text-browser emulator.

Browser independence
Your site may be viewed in a large variety of situations: different browsers, different operating systems, different features enabled or disabled. It is important that your site stands up well in these different situations. The first point of attention here is validation described separately above. Then there are the following points.

Try different browsers

Almost all web developers (ahem! perhaps that should read quite a lot of web developers) are aware of the need to check how their site looks in a variety of browsers. How far you go obviously depends on the resources available not everyone is in a position to check Windows, Mac, Unix and Linux platforms. The minimum test would probably be: 1. Firefox, as that has the best standards compliance and is the second most-used browser; 2. Internet Explorer for Windows currently the most widely used browser. It is essential to check both versions 6 and 7 as version 7 fixed quite a lot of bugs in 6 but introduced a new set of its own. (Microsoft is however still kicking developers in the teeth by not making it possible to install both versions on the same computer; you will either need two computers or one of the workarounds available on the net.) Version 5 should preferably also be checked; as of spring 2008 the number of users is not yet negligible. However it is now uncommon enough that you neednt worry about cosmetic issues; as long as the site is readable that should be sufficient. 3. Opera growing in popularity due to its speed and pretty good standards compliance. For some time I also recommended checking Netscape 4 as well, as it often produces radically different results from any other browser, and was very popular for a long time. However the number of users of this bug-ridden browser is now so small (under 0.1% and decreasing) that it can now probably safely be ignored.

Check printed pages

Print some of the pages on a normal printer (i.e. with a paper size of A4 or Letter) and check that they appear sensibly. Due to the somewhat limited formatting options available for printing, you probably cant achieve an appearance comparable to a document produced by a word-processor, but you should at least be able to read the text easily, and not have lines running off the right-hand side of the page. It is truly

extraordinary how many site authors fail to think of this most elementary of operations. You should also consider using CSS to adjust the appearance of the page when printed. For example you could probably should suppress the printing of information which is not relevant to the printed page, such as navigation bars. This can be done using the @media print or @import print CSS features. Some sites provide separate printer friendly versions of their pages, which the user can select and print. While this may occasionally be necessary as a last resort, it significantly increases the amount of work needed to maintain the site, is inconvenient for the reader and shouldnt usually be needed.

Switch Javascript off

There are unfortunately quite a number of Internet sites which abuse Javascript by, for example, generating unwanted pop-ups and irritating animations. There are also a number of Javascript-related security holes in browsers, especially Internet Explorer. As a result a lot of readers switch Javascript off indeed I often do myself. (I have a page giving the reasons in more detail.) Some organisations even block the usage of Javascript completely. Furthermore few, if any, search engines support Javascript. It is therefore important to check that your site still functions with Javascript disabled. A lot of sites rely quite unnecessarily on Javascript for navigation, with the result that the lack of Javascript renders the site unusable. Clearly if you need it for essential content, that functionality will be lost. But there is no reason why the basic text of the site should be unavailable. Avoid nearly-meaningless messages like Javascript needed to view this site. If you have something worth showing, tell the user what it is, e.g. enable Javascript to see animation of solar system.

Switch plug-ins off

The considerations for plug-ins (such as Flash or Java) are very similar to those for Javascript above. Check the site with any plug-ins disabled. The basic text and navigation should still work. Interest the reader sufficiently, and he might just go to the trouble of down-loading the plug-in. Greet him with a blank screen or a You need Flash to read this site message and he will probably go away, never to return.

Switch images off

If scanning a number of sites quickly for information, many readers (including myself) switch images off, for quick loading. Other people cannot view images. So switch images off and check that the site is readable and navigable. This means, in particular, checking that sensible ALT texts have been provided for images. (This check is similar to using a text browser, but not quite the same).

Other checks
Check non-reliance on mailto
In order to give readers a chance to contact them, web authors often include a link of the form mailto:abc@xyz.org. However this unfortunately does not work for anything like all browser/e-mail client combinations. And people in e.g. an Internet cafe cannot use this type of link. Indeed the figure is sometimes circulated that as many as 50% of readers cannot use mailto links. While I doubt whether the true figure is quite this high, it is a substantial number. Many readers prefer a form anyway: most of the responses I get to this site come via the contact form rather than the mailto link. Therefore the best thing is to provide a contact page which has both a mailto link and a contact form; the user can then choose which to use. See my own contact page as an example.

Check for orphan pages

An orphan page is one that contains no links back up to its ancestors i.e. to pages higher in the hierarchy of the site. Once one arrives at an orphan page, the only way to get to the rest of the site is via the back button. Which is fine until people arrive at the page via a search engine, or via a link that someone else gave to them. They cannot then visit the rest of the site. (True, they may be able to get up the hierarchy by lopping off the end of the URL, but this depends on how the site is built, and is in any case not reader-friendly.) So ensure all pages include a link back up the hierarchy. Orphan pages are particularly easy to overlook in sites with frames. Remember that when one addresses the page directly the other frames are absent.

Check sensible page titles

Check that the page titles (i.e. the contents of the <TITLE> elements) are sensible. Page titles are important, as for example they show up prominently in search-engine results, in bookmarks and also on the tabs of multi-tab browsers such as Opera. Generally speaking, each page of a site should have a unique title. They seem to be somewhat prone to the dreaded cut & paste disease. The grep tool is convenient for quickly checking the titles in all your page source files. A quick web search reveals over a million pages with the illuminating title New Page 1, while Untitled pages run into several millions.

Web Application UI Checklist Templates - Checklist Guidelines Testing user interface for web application is slightly different from testing user interface of traditional applications. Irrespective of the web application there are

certain things which should be tested for every web application. Following checklist will give some information on items that should be tested to ensure quality of the user interface of your web application.

1.1 COLORS 1.1.1 Are hyperlink colors standard? 1.1.2 Are the field backgrounds the correct color? 1.1.3 Are the field prompts the correct color? 1.1.4 Are the screen and field colors adjusted correctly for non-editable mode? 1.1.5 Does the site use (approximately) standard link colors? 1.1.6 Are all the buttons are in standard format and size? 1.1.7 Is the general screen background the correct color? 1.1.8 Is the page background (color) distraction free? 1.2 CONTENT 1.2.1 All fonts to be the same 1.2.2 Are all the screen prompts specified in the correct screen font? 1.2.3 Does content remain if you need to go back to a previous page, or if you move forward to another new page? 1.2.4 Is all text properly aligned? 1.2.5 Is the text in all fields specified in the correct screen font? 1.2.6 Is all the heading are left aligned 1.2.7 Does the first letter of the second word appears in lowercase? Eg: 1.3 IMAGES 1.3.1 Are all graphics properly aligned? 1.3.2 Are graphics being used the most efficient use of file size? 1.3.3 Are graphics optimized for quick downloads? 1.3.4 Assure that command buttons are all of similar size and shape, and same font & font size. 1.3.5 Banner style & size & display exact same as existing windows 1.3.6 Does text wrap properly around pictures/graphics? 1.3.7 Is it visually consistent even without graphics? 1.4 INSTRUCTIONS 1.4.1 Is all the error message text spelt correctly on this screen? 1.4.2 Is all the micro-help text(i.e tool tip) spelt correctly on this screen? 1.4.3 Microhelp text(i.e tool tip) for every enabled field & button 1.4.4 Progress messages on load of tabbed(active screens) screens 1.5 NAVIGATION 1.5.1 Are all disabled fields avoided in the TAB sequence?

1.5.2 Are all read-only fields avoided in the TAB sequence? 1.5.3 Can all screens accessible via buttons on this screen be accessed correctly? 1.5.4 Does a scrollbar appear if required? 1.5.5 Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified. 1.5.6 Is there a link to home on every single page? 1.5.7 On open of tab focus will be on first editable field 1.5.8 When an error message occurs does the focus return to the field in error when the user cancels it? 1.6 USABILITY 1.6.1 Are all the field prompts spelt correctly? 1.6.2 Are fonts too large or too small to read? 1.6.3 Are names in command button & option box names are not abbreviations. 1.6.4 Assure that option boxes, option buttons, and command buttons are logically grouped together in clearly demarcated areas "Group Box" 1.6.5 Can the typical user run the system without frustration? 1.6.6 Do pages print legibly without cutting off text? 1.6.7 Does the site convey a clear sense of its intended audience? 1.6.8 Does the site have a consistent, clearly recognizable "look-&-feel"? 1.6.9 Does User cab Login Member Area with both UserName/Email ID ? 1.6.9 Does the site look good on 640 x 480, 600x800 etc.? 1.6.10 Does the system provide or facilitate customer service? i.e. responsive, helpful, accurate? 1.6.11 Is all terminology understandable for all of the sites intended users?