This section discusses about the checklists for Website Testing. The website checklists to be taken care are the following:
1. User Interface Testing
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.
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
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
C. Video settings
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 Testing***************
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.
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)
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?