Section 1 – Use InterfaceTesting1.1 Site1.2 Site Map and Navigation bar1.3Site Content

Section 2 – FunctionalityTesting2.1 Application Specific2.2 Cookies

Section 3 – InterfaceTesting3.1 Server3.2 Error handling

Section 4 – CompatibilityTesting

Section 5 – Load/StressTesting

Section 6 – SecurityTesting6.1 General6.2Logins

_______________________________________________________________________

*************** 1. User Interface Testing***************

1.1 SiteA. Easy to useB.

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

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

1.3 Site ContentA. Correctness of wordingB. No overuse of bold text,big fonts and blinking (user acceptance testing)C. Hyperlinked referencesare workingD. Are patterns, background colour and pictures distract theuser?E. Does all images add value to respective page?F. Do these imageswaste bandwidth? In general use small pictures to reduce load. G. Doeswrap-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.2Cookies

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 skewinformation

******************* 3. Interface Testing *******************

3.1 ServerA. 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 transactiondata is being retrieve and store properly.

3.2 Error HandlingA. 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 systemsB. Browsers C. Video settingsD. 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 GeneralA. 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 LoginsA. Inorder 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 FilesA. Does the serverlog 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 SSLA. 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.

Let’s have first web testing checklist.1) Functionality Testing2) Usability testing3) Interface testing4) Compatibility testing5) Performance testing6) 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.

Let’s 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 interfaceApplication 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 API’s 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 TestingWeb 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 websites1.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 input1.2.2 Optional versus mandatory fields1.2.3 Input longer than field allows1.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 fed1.3.3 Check to see what happens if a user deletes cookies while in site1.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          All Internal Links1.1.2          All External Links1.1.3          All mail to links1.1.4          Check for orphan Pages1.1.5          Check for Broken Links 1.2               Forms

 Test for the integrity of submission of all forms. 

1.2.1          All Field Level Checks1.2.2          All Field Level Validations.1.2.3          Functionality of Create, Modify, Delete & View.1.2.4          Handling of Wrong inputs (Both client & Server)1.2.5          Default Values if any1.2.6          Optional versus Mandatory fields.

 1.3               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          Meta Tags1.4.2          Frames1.4.3          HTML syntax.

  

1.5               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          Application navigation is proper through tab2.1.2          Navigation through Mouse2.1.3          Main features accessible from the main/home page.2.1.4          Any hot keys, control keys to access menus.

 2.2               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          Spellings and Grammars2.2.2          Updated information

 2.3               General Appearance

 2.3.1          Page appearance2.3.2          Color, font and size2.3.3          Frames2.3.4          Consistent design

 3. Server Side Interfaces: 

3.1               Server Interface 

3.1.1          Verify that communication is done correctly, Web server-application server, application server-database server and vice versa.

3.1.2          Compatibility of server software, hardware, network connections.3.1.3          Database compatibility (SQL, Oracle etc.)

 3.2               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. Linuxe. 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) AOLBrowser settings (security settings, graphics, Java etc.)Frames and Cascade Style sheetsApplets, 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 alignmentb. Colours of text, foreground and backgroundc. Scalability to fit paper sized. 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, T3b. 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               Valid and Invalid Login6.2               Limit defined for the number of tries.6.3               Can it be bypassed by typing URL to a page inside directly in the browser?6.4               Verify Log files are maintained to store the information for traceability.6.5               Verify encryption is done correctly if SSL is used (If applicable)6.6               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 Expected Actual Remarks Ticket

Reference1. Functionality        1.1 Links        Internal Links Should be

present     

External Links Should be present

     

Mail to links Should open mailbox

     

Orphan pages Should not be present

     

Broken links Should not be present

     

         1.2 Forms        Field Level checks Checked for

length, special characters, numerical characters etc.,

     

Field Level Validation

Checked Unique records, Date validation

     

Functional checks Create, modify, view and delete are working.

     

Error Handling for wrong inputs or actions.

Appropriate error messages to be displayed.

     

Optional and mandatory fields.

Mandatory field should not be left blank.Optional should allow the user to skip the field.

     

         1.3 Cookies        Check whether cookies are enabled.

**Depends on project

     

         1.4 Web Indexing        Meta tags Should be

present.     

Html Syntax Should be valid      Frames To be found ok               1.5 Database        Data Integrity Should not be

any missing or wrong data in the database

     

Output Errors Errors in writing, reading or editing

     

operations should not be present

         2. Usability        2.1 Navigation        Navigation through Mouse

Should be proper

     

Navigation through Tab

Should be proper

     

Main features access

Should be accessed from home/Main page

     

Hot Keys, Control Keys for menu or action

Should be present

     

         2.2 Content        Spelling and Grammar

To be proper      

Updated information’s.

Past events/ information’s to be removed.

     

         2.3 General Appearance

       

Page Appearance Should not be any overlapping, missing etc.,

     

Colour, font and size

Should be as per 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

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

     

Compatibility with server hardware, Sw, network connections

Should be proper.

     

Database compatibility[s1]

Should be easily portable to other database.

     

         4. Client side        

Compatibility4.1 Platform        Windows2000, NT Should be

working     

Unix Should be working

     

Linux Should be working

     

Solaris Should be working

     

Macintosh Should be working

     

         4.2 Browsers        I.E Should work in

all versions above 4.x

     

Netscape Navigator

Should work in all versions above 3.x

     

AOL        Any ActiveX controls

       

         Graphics Load of images,

graphics should be proper

     

         4.3 Printing                 Text and alignment Should be

proper     

Colours of text, foreground and background

Should be readable.

     

Scalability to fit paper size.

Should print in A4, Letter size.

     

Tables and borders.

Should be proper.

     

         5. Performance        5.1 Connection speed

       

Should be measured in 14.4, 28.8, 33.6, 56.6, ISDN, Cable and DSL

       

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

     

         5.2 Load        

Estimated users. Per requirements

     

Peak load Should withstand

     

Large amount of data from users

Should accept      

         5.3 Stress        System Crash Should not be

present     

Error in Sw, HW, Memory

Leakage, overwrite should not happen.

     

         5.4 Continuous use

       

Estimate whether available for 24 Hrs, 7 days a week

Try with various timings.

     

Downtime Measure the downtime

     

Memory or disk space

Should not run out of memory or disk space.

     

         6. Security        6.1 Valid and Invalid

Should not enter with Invalid login

     

Number of tries Should not be more than 3 times for invalid try.

     

Enter url directly without logging in.

Should not display information.

     

Log files Should be maintained

     

Access to server scripts

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 sites—especially those with more limited budgets—may 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 browsers—including several versions of Internet Explorer for Windows—on 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 CSS-driven 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 advance—including protocols for supporting old browsers.

Use Annotated Screenshots to Determine Display ProtocolsAt 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 SitesLarger 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 ValidatorsSome 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 run—tests 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 LoadsYour 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 software—many 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 cross-browser, cross-platform testing. Stay informed of the release of new or updated browsers and operating systems so that you can keep your cross-browser, cross-platform tests current.

Which Browsers and Platforms to Test?Check your server logs—as well as other on- and offline resources—that 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 site—new content, new images, or new web pages—check 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 ToolsSome 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 ResolutionsScreen 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 page—less if the browser window isn't maximized. Be sure to conduct testing that accounts for this wide range of variability—not 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 tools—such as BrowserCam, an online subscription service—which 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 available—try 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 location—be 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 TestDownload 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 integrity—especially in terms of your confidential data, including customer credit card information—is 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 expectationsThe 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 toolsAs 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 perspectivePerform 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 weaknessesOne 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 findingsAs 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 weaknessesDon'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 codeUntil 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 it’s ready for public viewing? Well, based on a lot of the web-sites I’ve 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 won’t bother other browsers or a validator.

Check for broken links

Obviously you don’t 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 don’t worry too much about the very long lines of text that appear at large screen sizes when small fonts are used. If the reader doesn’t 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 %, didn’t 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.) Don’t 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 can’t yet get broadband. By the way, don’t make the mistake of assuming that you don’t 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 doesn’t (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 don’t 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 work-arounds 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 needn’t 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 can’t 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 shouldn’t 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 aligned1.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 site’s intended users?