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 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
1.2 Forms
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.
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 Tags
1.4.2 Frames
1.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 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.
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 Grammars
2.2.2 Updated information
2.3 General Appearance
2.3.1 Page appearance
2.3.2 Color, font and size
2.3.3 Frames
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:
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:
- 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.
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
- 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. Security:
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.
Session cookie
A session cookie only lasts for the duration of users using the website. A web browser normally deletes session cookies when it quits. A session cookie is created when no Expires directive is provided when the cookie is created.
Persistent cookie
A persistent cookie will outlast user sessions. If a persistent cookie has its Max-Age set to 1 year, then, within the year, the initial value set in that cookie would be sent back to the server every time the user visited the server. This could be used to record a vital piece of information such as how the user initially came to this website. For this reason, persistent cookies are also called tracking cookies.
Secure cookie
A secure cookie is only used when a browser is visiting a server via HTTPS, ensuring that the cookie is always encrypted when transmitting from client to server. This makes the cookie less likely to be exposed to cookie theft via eavesdropping.
HttpOnly cookie
The HttpOnly session cookie is supported by most modern browsers.[13] On a supported browser, an HttpOnly session cookie will be used only when transmitting HTTP (or HTTPS) requests, thus restricting access from other, non-HTTP APIs (such as JavaScript). This restriction mitigates but does not eliminate the threat of session cookie theft via Cross-site scripting.[14]. It is important to realize this feature applies only to session-management cookies, and not other browser cookies.
Third-party cookieFirst-party cookies are cookies set with the same domain (or its subdomain) in your browser's address bar. Third-party cookies are cookies being set with different domains than the one shown on the address bar.
For example: Suppose a user visits www.example1.com, which sets a cookie with the domain ad.foxytracking.com. When the user later visits www.example2.com, another cookie is set with the domain ad.foxytracking.com. Eventually, both of these cookies will be sent to the advertiser when loading their ads or visiting their website. The advertiser can then use these cookies to build up a browsing history of the user across all the websites this advertiser has footprints on.
Zombie cookie
Main article: Zombie cookie
A zombie cookie is any cookie that is automatically recreated after a user has deleted it. This is accomplished by a script storing the content of the cookie in some other locations, such as the local storage available to Flash content, HTML5 storages and other client side mechanisms, and then recreating the cookie from backup stores when the cookie's absence is detected.
How can I tell if a web page is secure?
The below takes you ssl.com aritcle on web page secure. This brilliantly written article answers almost everything you need to know bout how to tell if a website is secure.
Also read the below releated articles on subject:
http://www.lloydstsb.com/security/web_page_security.asp [click 'check a site certificate' link at the end of description]
Below article explains the process of procuring and installing a SSL server certificate [article focus on SSL.com products, but worth to read as the process should be common to all vendors]
http://info.ssl.com/article.aspx?id=10694
What are Load, Stress, Volume, etc. testing?
A:
- Volume testing is a way to test functionality.
- Stress testing is a way to test reliability.
- Load testing is a way to test performance.
Testing an application under heavy but expected loads is known as load
testing. It generally refers to the practice of modeling the expected usage of a software program by simulating multiple users accessing the system's services concurrently. As such, load testing is most relevant for a multi-user system, often one built using a client/server model, such as a web server tested under a range of loads to determine at what point the system's response time degrades or fails. Although you could perform a load test on a word processor by or graphics editor forcing it read in an extremely large document; on a financial package by forcing to generate a report based on several years' worth of data, etc.
When the load placed on the system is accelerated beyond normal usage
patterns, in order to test the system's response at unusually high or peak loads, it is known as stress testing. Stress testing is often incorrectly used interchangeably with load and performance testing.
In a stress test, the load is usually so great that error conditions are the expected result, although there is a grey area between the two domains and no clear boundary exists where you could say that an activity ceases to be a load test and becomes a stress test.
There is little agreement on what the specific goals of load testing are. The term is often used synonymously with performance testing, reliability testing, and volume testing.
Performance testing is usually performed to determine how fast some aspect of a system performs under a particular workload. It can serve different purposes: to demonstrate that the system meets performance criteria; to compare two systems to find which performs better; to measure what parts of the system or workload cause the system to perform badly.
In the diagnostic case, software engineers use tools such as profilers to measure what parts of a device or software contribute most to the poor performance. In performance testing, it is often crucial (and often difficult to arrange) for the test conditions to be similar to the expected actual use.
A reliability test determines how likely a piece of hardware (or sometimes software) is to fail. It is part of reliability theory, used originally as a tool to help nineteenth century insurance companies compute profitable rates to charge their customers. Statistical models appropriate for any of these are generically called "time-to-event" models. Death or failure is called an "event", and the goal is to project or forecast the rate of events for a given population or probability of an event for an individual.
Volume testing is used to determine if the system under test can handle the required amounts of data, user requests, etc.
Soak testing occurs when running a system at normal to high levels of load for prolonged periods of time. A soak test would normally execute several times more transactions in an entire day than would be expected in a busy day. This should identify any performance problems that appear after a large number of transactions have been executed.
For some of the basics on this type of testing, please read the following series:
Web Page Response Time 101
http://www.stickyminds.com/r.asp?F=DART_5030
Web Load Test Planning
http://www.stickyminds.com/r.asp?F=DART_5084
The Science and Art of Web Site Load Testing
http://www.stickyminds.com/r.asp?F=DART_1939
Getting Started : Stressing Web Applications Stress Early -- Stress Often
http://www.amibug.com/getinfo.shtm?present=webstress
http://www.perftestplus.com
http://www.performancetester.com Testing an application under heavy but expected loads is known as load
testing. It generally refers to the practice of modeling the expected usage of a software program by simulating multiple users accessing the system's services concurrently. As such, load testing is most relevant for a multi-user system, often one built using a client/server model, such as a web server tested under a range of loads to determine at what point the system's response time degrades or fails. Although you could perform a load test on a word processor by or graphics editor forcing it read in an extremely large document; on a financial package by forcing to generate a report based on several years' worth of data, etc.
When the load placed on the system is accelerated beyond normal usage
patterns, in order to test the system's response at unusually high or peak loads, it is known as stress testing. Stress testing is often incorrectly used interchangeably with load and performance testing.
In a stress test, the load is usually so great that error conditions are the expected result, although there is a grey area between the two domains and no clear boundary exists where you could say that an activity ceases to be a load test and becomes a stress test.
There is little agreement on what the specific goals of load testing are. The term is often used synonymously with performance testing, reliability testing, and volume testing.
Performance testing is usually performed to determine how fast some aspect of a system performs under a particular workload. It can serve different purposes: to demonstrate that the system meets performance criteria; to compare two systems to find which performs better; to measure what parts of the system or workload cause the system to perform badly.
In the diagnostic case, software engineers use tools such as profilers to measure what parts of a device or software contribute most to the poor performance. In performance testing, it is often crucial (and often difficult to arrange) for the test conditions to be similar to the expected actual use.
A reliability test determines how likely a piece of hardware (or sometimes software) is to fail. It is part of reliability theory, used originally as a tool to help nineteenth century insurance companies compute profitable rates to charge their customers. Statistical models appropriate for any of these are generically called "time-to-event" models. Death or failure is called an "event", and the goal is to project or forecast the rate of events for a given population or probability of an event for an individual.
Volume testing is used to determine if the system under test can handle the required amounts of data, user requests, etc.
Soak testing occurs when running a system at normal to high levels of load for prolonged periods of time. A soak test would normally execute several times more transactions in an entire day than would be expected in a busy day. This should identify any performance problems that appear after a large number of transactions have been executed.
For some of the basics on this type of testing, please read the following series:
Web Page Response Time 101
http://www.stickyminds.com/r.asp?F=DART_5030
Web Load Test Planning
http://www.stickyminds.com/r.asp?F=DART_5084
The Science and Art of Web Site Load Testing
http://www.stickyminds.com/r.asp?F=DART_1939
Getting Started : Stressing Web Applications Stress Early -- Stress Often
http://www.amibug.com/getinfo.shtm?present=webstress
http://www.perftestplus.com
Cookie Terminologies......
A session cookie only lasts for the duration of users using the website. A web browser normally deletes session cookies when it quits. A session cookie is created when no Expires directive is provided when the cookie is created.
Persistent cookie
A persistent cookie will outlast user sessions. If a persistent cookie has its Max-Age set to 1 year, then, within the year, the initial value set in that cookie would be sent back to the server every time the user visited the server. This could be used to record a vital piece of information such as how the user initially came to this website. For this reason, persistent cookies are also called tracking cookies.
Secure cookie
A secure cookie is only used when a browser is visiting a server via HTTPS, ensuring that the cookie is always encrypted when transmitting from client to server. This makes the cookie less likely to be exposed to cookie theft via eavesdropping.
HttpOnly cookie
The HttpOnly session cookie is supported by most modern browsers.[13] On a supported browser, an HttpOnly session cookie will be used only when transmitting HTTP (or HTTPS) requests, thus restricting access from other, non-HTTP APIs (such as JavaScript). This restriction mitigates but does not eliminate the threat of session cookie theft via Cross-site scripting.[14]. It is important to realize this feature applies only to session-management cookies, and not other browser cookies.
Third-party cookieFirst-party cookies are cookies set with the same domain (or its subdomain) in your browser's address bar. Third-party cookies are cookies being set with different domains than the one shown on the address bar.
For example: Suppose a user visits www.example1.com, which sets a cookie with the domain ad.foxytracking.com. When the user later visits www.example2.com, another cookie is set with the domain ad.foxytracking.com. Eventually, both of these cookies will be sent to the advertiser when loading their ads or visiting their website. The advertiser can then use these cookies to build up a browsing history of the user across all the websites this advertiser has footprints on.
Zombie cookie
Main article: Zombie cookie
A zombie cookie is any cookie that is automatically recreated after a user has deleted it. This is accomplished by a script storing the content of the cookie in some other locations, such as the local storage available to Flash content, HTML5 storages and other client side mechanisms, and then recreating the cookie from backup stores when the cookie's absence is detected.
