How to Test a Website or Web Application?
In this post you will learn the guidelines and checklist for testing a Web application.
Objective is to check for all the links in the website.
1.1.1 All Internal Links
1.1.2 All External Links
1.1.3 All mail to links
1.1.4 Check for orphan Pages
1.1.5 Check for Broken Links
Test for the integrity of submission of all forms.
1.2.1 All Field Level Checks
1.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 any
1.2.6 Optional versus Mandatory fields.
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.3 HTML syntax.
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.
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 tab
2.1.2 Navigation through Mouse
2.1.3 Main features accessible from the main/home page.
2.1.4 Any hot keys, control keys to access menus.
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 Grammars
2.2.2 Updated information
2.3 General Appearance
2.3.1 Page appearance
2.3.2 Color, font and size
2.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:
Check for the compatibility of
- Windows (95, 98, 2000, NT)
- Unix (different sets)
- Macintosh (If applicable)
- Solaris (If applicable)
Check for the various combinations:
- Internet Explorer (3.X 4.X, 5.X)
- Browser settings (security settings, graphics, Java etc.)
- Frames and Cascade Style sheets
- Applets, ActiveX controls, DHTML, client side scripting
- HTML specifications.
Loading of images, graphics, etc.,
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.1 Connection speed
a. Try with Connection speed: 14.4, 28.8, 33.6, 56.6, ISDN, cable, DSL, T1, T3
Check/Measure the following:
- What is the estimated number of users per time period and how will it be divided over the period?
- Will there be peak loads and how will the system react?
- Can your site handle a large amount of users requesting a certain page?
- Large amount of data from users.
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
- 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?
- Will downtime be allowed or is that out of the question?
- Verify that the application is able to meet the requirements and does not run out of memory or disk space.
6.1 Valid and Invalid Login
6.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.