Checklist for Website Testing

Here you can find the checklist for web testing. By using the checklist for web application testing, user can create test cases for any web based application:

Step 1 - User Interface Testing (GUI Testing):

a. Content wording used in the web pages should be correct.

b. Wrap-around should occur properly.

c. Instructions used in web pages should be correct (i.e. if you follow each instruction does the expected result occur?)

d. Check image size specifications: Check that at least the text of the page appears quickly.

e. View in text browser: Test each web page in text-only browser, or text-browser emulator. It will help you pick up on badly-chosen or missing ALT texts. 

f. Switch images off: Check that sensible ALT texts have been provided for images.

g. Check sensible page titles.

h. Resolution change effect on web pages.

i. Image spacing – To verify that images are displaying properly with text.

j. Print – Pinting should be proper.

For more information about GUI testing, kindly refer to http://puretest.blogspot.com/2009/11/gui-testing.html

Step 2 - Functional Testing

a. Check for broken links (Broken link refers to a hyperlink which does not work): Manually its very difficult to find broken links. There are various tools available to find these, such as:

- Broken Link Check

- Firefox Add-on Pinger 1.0.2

b. Validate the HTML: Make sure that you have valid HTML (or XHTML). This can be done with a W3C validator

c. Disable the cookies from your browser settings. If you are using cookies on your site, your sites major functionality will not work by disabling the cookies. See if appropriate messages are displayed.

(A cookie is a small piece of information stored as a text file on your computer that a web server uses when you browse certain web sites that you've visited before).

d. Switch JavaScript off: It is important to check that your site still functions with Javascript disabled or provide proper Javascript error message: 
e.g. “enable Javascript to see animation of Intelligaia Technologies”.

e. Warning messages: Error/warning messages should be flash to user for incorrect inputs.

Step 3 - Interface Testing

a. Data display on browser should match with data available on server: To test browser and server interface, run queries on the database to make sure the transaction data is being retrieve and store properly.

b. Error Handling: Make sure system can handle application errors.

Step 4 - Compatibility Testing

a. Test on different Operating systems: Test your web application on different operating systems like Windows (XP, Vista, Win7 etc), Unix, MAC, Linux, Solaris with different OS flavors.

b. Test on different Browsers: Test web application on different browsers like:

- Firefox, as that has the best standards compliance and is the second most-used browser.

- Internet Explorer for Windows – currently the most widely used browser (IE6, IE7, IE8).

- Opera – growing in popularity due to its speed and pretty good standards compliance.

c. 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.

Step 5 - Security Testing

a. Limit should be defined for the number of tries: Is there a maximum number of failed logins allowed before the server locks out the current user?

b. Verify rules for password selection.

c. Is there a timeout limit?

d. Test by pasting internal url directly into browser address bar without login. Internal pages should not open.

e. Test the CAPTCHA for automates scripts logins.

f. 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.

g. All transactions, error messages, security breach attempts should get logged in log files somewhere on web server.

h. Clear your Cache: Be sure to clear the browser cache, including cookies, before each test.

i. SQL injection: To test for SQL injection bugs, find places where users can enter text, such as where the text is used to perform a lookup function, according to Breach. Then type a single quote character and some text. If the application shows an error message from your database, then you're likely housing an SQL injection bug.

(SQL injection is an attack in which malicious code is inserted into strings that are later passed to an instance of SQL Server for parsing and execution.)

j. Cross-site scripting (XSS): Find areas in your application that accept user input, such as a page where users can send in their feedback or reviews of a product, for example. Try submitting following: 
1. >"'><script>alert(‘XSS')</script>
2. >%22%27><img%20src%3d%22javascript:alert(%27XSS%27)%22>
3. >"'><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26%23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26%23x3a;alert(%26quot;XSS%26quot;)>
4. AK%22%20style%3D%22background:url(javascript:alert(%27XSS%27))%22%20OS%22
5. %22%2Balert(%27XSS%27)%2B%22
6. <table background="javascript:alert(([code])"></table>
7. <object type=text/html data="javascript:alert(([code]);"></object>
8. <body onload="javascript:alert(([code])"></body> 

If that text displays where you reload the page, then your site has an XSS vulnerability.

(Cross-site scripting attacks occur when a malicious person, the attacker, can force an unknowing user, the victim, to run client-side script of the attacker’s choice. The term cross-site scripting is sort of a misnomer, because it’s not just about scripting and it doesn’t even have to be cross-site. It’s a name that was branded upon its discovery and it has just stuck.)

k. Session hijacking: If your application has a session identifier number in the URL decrease that number by one and reload the page. The app has a session hijacking vulnerability if the app then "sees" you as a different user.

(Session hijacking, also known as TCP session hijacking, is a method of taking over a Web user session by surreptitiously obtaining the session ID and masquerading as the authorized user. Once the user's session ID has been accessed (through session prediction), the attacker can masquerade as that user and do anything the user is authorized to do on the network.)

Step 6 - Performance testing

a. Can your site handle a large amount of users requesting a certain page.

b. Long period of continuous use: Is site able to run for long period, without downtime.

For more information about Load testing, kindly refer to: http://puretest.blogspot.com/2009/11/performance-testing-1.html

c. Web page performance (speed) - Page Speed generates its results based on the state of the page at the time you run the tool. To ensure the most accurate results, you should wait until the page finishes loading before running Page Speed. Otherwise, Page Speed may not be able to fully analyze resources that haven't finished downloading.

Free Tools which plays very important role in web site testing:
1. Bug Tracking Tool: Bugzilla

2. Recording the bug in video format: Screencast-o-matic
3. Tool for taking Screen-shots for reporting the bug: Fireshot
4. Compatibility testing tools: Browser Sandbox and Adobe BrowserLab
5. Tool to Monitor CSS and HTML: Firebug
6. Tool to ensure valid HTML: HTML Validator
7. Performance Testing tool: Page Speed by Google
8. To find Broken Links: Pinger Ad-on and brokenlinkcheck
9. For checking the spelling of content: Spell Check




Related Testing Topics: 
a. Desktop App Testing Checklist
b. Test Cases
c. Testing Tools