Web Testing: Complete Reference

Let’s have first web testing checklist:

1) Functionality Testing
2) Cookies testing
3) Usability testing
4) Interface testing
5) Compatibility testing
6) Performance testing
7) 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. In this kind of 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.

2) 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.

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.

3) 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.

4) Usability Testing:
i) 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.

ii) 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.

iii) 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

iv) 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.

5) Interface Testing:
The main interfaces are:
Web server and application server interface
Application 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?

6) 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.

7) Performance testing:
Web application should sustain to heavy load. Web performance testing should include:
Web Load Testing
Web 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,

8) 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.

REMEMBER SOFTWARE TESTING 10 RULES
1. Test early and test often.
2. Integrate the application development and testing life cycles. You’ll get better results and you won’t have to mediate between two armed camps in your IT shop.
3. Formalize a testing methodology; you’ll test everything the same way and you’ll get uniform results.
4. Develop a comprehensive test plan; it forms the basis for the testing methodology.
5. Use both static and dynamic testing.
6. Define your expected results.
7. Understand the business reason behind the application. You’ll write a better application and better testing scripts.
8. Use multiple levels and types of testing (regression, systems, integration, stress and load).
9. Review and inspect the work, it will lower costs.
10. Don’t let your programmers check their own work; they’ll miss their own errors.

Software Testing @ glance

Steps to perform software testing: 

• Understand requirements and business logic
• Determine required standards and processes
• Set priorities, and determine scope and limitations of tests
• Determine test approaches and methods
• Determine test environment, test ware, test input data requirements
• Set milestones and prepare test plan document
• Write test cases
• Have needed reviews/inspections/approvals of test cases
• Set up test environment
• Execute test cases
• Evaluate and report results
• Bug Tracking and fixing
• Retesting or regression testing if needed
• Update test plans, test cases, test results, tractability matrix etc.

 

Components of a Bug Report: 

• Application name
• The function, module, name
• Bug ID
• Bug reporting date
• Status
• Test case ID
• Bug description
• Steps needed to reproduce the bug
• Names and/or descriptions of file/data/messages/etc. used in test
• Snapshot that would be helpful in finding the cause of the problem
• Severity estimate
• Was the bug reproducible?
• Name of tester
• Description of problem cause (filled by developers)
• Description of fix (filled by developers)
• Code section/file/module/class/method that was fixed (filled by developers)
• Date of fix (filled by developers)
• Date of retest or regression testing
• Any remarks or comments

Web based applications testing guidelines:

Apart from functionality consider the following:

• What are the expected loads on the server and what kind of performance is expected on the client side?
• Who is the target audience?
• Will down time for server and content maintenance / upgrades be allowed?
• What kinds of security will be required and what is it expected to do?
• How reliable are the site's Internet / intranet connections required to be?
• How do the internet / intranet affect backup system or redundant connection requirements and testing?
• What variations will be allowed for targeted browsers?
• Will there be any standards or requirements for page appearance and / or graphics throughout a site or parts of a site?
• How will internal and external links be validated and updated?
• How are browser caching and variations in browser option settings?
• How are flash, applets, java scripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested?

From the usability point of view consider the following:

• Pages should be 3-5 screens longer.
• The page layouts and design elements should be consistent throughout the application / web site.
• Pages should be as browser-independent or generate based on the browser-type.
• There should be no dead-end pages. A link to a contact person or organization should be included on each page.

Security Testing

If you are thinking about Security Testing, here we go:

Security testing:

Security testing is a process to determine that an information system protects data and maintains functionality as intended. The security testing is performed to check whether there is any information leakage in the sense by encrypting the application or using wide range of software’s and hardware's and firewall etc.

The six basic security concepts that need to be covered by security testing are: confidentiality, integrity, authentication, availability, authorization and non-repudiation. Security testing as a term has a number of different meanings and can be completed in a number of different ways.

• Authentication - Testing the authentication schema means understanding how the authentication process works and using that information to circumvent the authentication mechanism. Basically, it allows a receiver to have confidence that information it receives originated from a specific known source.

• Authorization - Determining that a requester is allowed to receive a service or perform an operation.

• Availability- Assuring information and communications services will be ready for use when expected. Information must be kept available to authorized persons when they need it.

• Confidentiality - A security measure which protects the disclosure of data or information to parties other than the intended.

• Integrity – Whether the intended receiver receives the information or data which is not altered in transmission.

• Non-repudiation - Interchange of authentication information with some form of provable time stamp e.g. with session id etc.

Types:

There are two types of security testing that can be performed on Web applications: static analysis and dynamic analysis. In addition, there are two ways of performing security tests: automated and manual.

Dynamic analysis involves performing tests on a running instance of an application and is also known as black box testing. The security test will involve sending requests to the application and observing the responses to see if there was any indication that security vulnerability may be present. Dynamic analysis can be an effective way to test applications, but it is important to understand some limitations. First of all, because the testing is based on analyzing request and response patterns, the results obtained are really only a guess about the internal state of the application -- the tester typically has no knowledge of the actual application source code and what the actual internal state of the application is. In addition, because the tester is only looking at the observable behavior of the application and cannot know the entire attack surface, there is a chance that areas of the application and components of its functionality will be excluded from the test.

Dynamic analysis can either be performed in an automated manner or manually. Web application scanning tools like those from Watch fire and SPI Dynamics are good example of automated dynamic analysis tools. Automated tools are good for finding much common vulnerability such as SQL injection and cross-site scripting (XSS).

Manual testing of Web applications is typically performed using a Web browser and a Web proxy tool like Paros or OWASP's Web Scarab. The commercial scanning tools also typically come with proxies as well so that analysts using their scanners can augment the scanner results with manual tests. Proxies allow the security analyst to create and send arbitrary requests to the application and inspect the results to look for evidence of security issues. As mentioned above, these manual tests to look for data leakage, failures to authorize activities and so on are required for a credible application security assessment.

Where dynamic analysis is performed against an actually running installation of an application, static analysis involves reviewing application assets like source code, configuration files and so on when they are static -- or at rest. This is also known as source code analysis or white box testing. Static analysis opens up opportunities for a more thorough analysis because the analysis being performed has access to the "ground truth" of the source code. Analysts do not have to observe the behavior of an application and make guesses about the internal state of the system; instead the analyst has access to the actual instructions the software will follow when put into production.

Security testing approach:

In order to perform a useful security test of a web application, the security tester should have good knowledge of the HTTP protocol. It is important to have an understanding of how the client (browser) and the server communicate using HTTP. Additionally, the tester should at least know the basics of SQL injection and XSS.

1. Password cracking:

The security testing on a web application can be kicked off by “password cracking”. In order to log in to the private areas of the application, one can either guess a username/ password or use some password cracker tool for the same. Lists of common usernames and passwords are available along with open source password crackers. If the web application does not enforce a complex password (e.g. with alphabets, number and special characters, with at least a required number of characters), it may not take very long to crack the username and password.

If username or password is stored in cookies without encrypting, attacker can use different methods to steal the cookies and then information stored in the cookies like username and password

2. URL manipulation through HTTP GET methods:

The tester should check if the application passes important information in the query string. This happens when the application uses the HTTP GET method to pass information between the client and the server. The information is passed in parameters in the query string. The tester can modify a parameter value in the query string to check if the server accepts it.

Via HTTP GET request user information is passed to server for authentication or fetching data. Attacker can manipulate every input variable passed from this GET request to server in order to get the required information or to corrupt the data. In such conditions any unusual behavior by application or web server is the doorway for the attacker to get into the application.

3. SQL Injection:

The next thing that should be checked is SQL injection. Entering a single quote (‘) in any textbox should be rejected by the application. Instead, if the tester encounters a database error, it means that the user input is inserted in some query which is then executed by the application. In such a case, the application is vulnerable to SQL injection.

SQL injection attacks are very critical as attacker can get vital information from server database. To check SQL injection entry points into your web application, find out code from your code base where direct MySQL queries are executed on database by accepting some user inputs.

If user input data is crafted in SQL queries to query the database, attacker can inject SQL statements or part of SQL statements as user inputs to extract vital information from database. Even if attacker is successful to crash the application, from the SQL query error shown on browser, attacker can get the information they are looking for. Special characters from user inputs should be handled/ escaped properly in such cases.

4. Cross Site Scripting (XSS):

The tester should additionally check the web application for XSS (Cross site scripting). Any HTML e.g. <HTML> or any script e.g. <SCRIPT> should not be accepted by the application. If it is, the application can be prone to an attack by Cross Site Scripting.

Attacker can use this method to execute malicious script or URL on victim’s browser. Using cross-site scripting, attacker can use scripts like JavaScript to steal user cookies and information stored in the cookies.

Many web applications get some user information and pass this information in some variables from different pages.

E.g.: http://www.domain.com/index.php?userid=123&query=xyz

Attacker can easily pass some malicious input or <script> as a ‘&query’ parameter which can explore important user/server data on browser.

Important: During security testing, the tester should be very careful not to modify any of the following:

• Configuration of the application or the server

• Services running on the server

• Existing user or customer data hosted by the application

Additionally, a security test should be avoided on a production system.

The purpose of the security test is to discover the vulnerabilities of the web application so that the developers can then remove these vulnerabilities from the application and make the web application and data safe from unauthorized actions.

When do we use Security Testing?

Security testing is carried out when some important information and assets managed by the software application are of significant importance to the organization. Failures in the software security system can be serious especially when not detected, thereby resulting in a loss or compromise of information without the knowledge of that loss.

The security testing should be performed both prior to the system going into the operation and after the system is put into operation.

Rigorous security testing activities are performed to demonstrate that the system meets the specified security requirements & identify the left out security vulnerabilities, if any.

The extent of testing largely depends upon the security risks, and the test engineers assigned to conduct the security testing are selected according to the estimated sophistication that might be used to penetrate the security.

What are the objectives of Security Testing?

Security defects do not come to surface that easily as other types of defects. Thus security testing is carried out to identify defects that are quite difficult to identify. The security testing is carried out to ensure that the software under test is sufficiently robust and functions in an acceptable manner even in the event of a malicious attack.

The objectives of security testing can be:

1) To ensure that adequate attention is provided to identify the security risks

2) To ensure that a realistic mechanism to define & enforce access to the system is in place

3) To ensure that sufficient expertise exists to perform adequate security testing

4) To conduct reasonable tests to confirm the proper functioning of the implemented security measures

Who should do the Security Testing?

Majority of the security testing techniques are manual, requiring an individual to initiate and conduct the test. Automation tools can be helpful in executing simple tasks, whereas complicated tasks continue to depend largely on the intelligentsia of the test engineer.

Irrespective of the type of testing, the testing engineers that plan and conduct security testing should have significant security and networking related knowledge, including expertise of following areas:

1) Network security

2) Firewalls

3) Intrusion detection system

4) Operating systems

5) Programming and networking protocols like TCP/IP

Security Testing versus Conventional Software Testing

– A Quick Comparison:

Security testing has following attributes:

• It emphasizes what an application should not do rather than what it should do.
• It sometimes tests conformance to positive requirements for instance - "User accounts getting disabled after five unsuccessful login attempts" etc.
• It is aimed to test the negative requirements stating something that should never occur. For example "An external attacker should not be able to modify the contents of the Web page" and "Unauthorized users should not be able to access the data."

Conventional testing has following attributes:

• It is aimed to test a positive requirement i.e. to create the conditions in which the requirement is intended to hold true and verify that the requirement is satisfied by the software.
• To apply conventional testing approach to the negative requirements, we need to create every possible set of non-feasible conditions.

Methods of Security Testing:

To confirm if a particular software application meets the security requirements, usually following two methods of testing are adopted

1) Functional security testing: It is meant to ensure that the software behaves according to certain specified functional requirements and is expected to demonstrate that the specified requirements are totally satisfied at the acceptable level. Functional requirement generally have a form like - "When a certain thing takes place, then the software must respond in a particular way."

2) Risk-based security testing: The first step in risk-based testing is the identification of the security risks and the potential loss associated with those risks. It tries to confirm the immunity against specific risks that have been identified through risk analysis effort. Risk-based testing addresses negative requirements, which state what a software system should not do. Tests for negative requirements are derived from a risk analysis, and generally cover not only the high-level risks identified during the design process but also address low-level risks derived from the software itself.

What are the common techniques for Security Testing?

Few of the security testing techniques commonly used are:

• Network scanning
• Vulnerability scanning
• Password cracking
• Log review
• Integrity checkers
• Virus detection
• War dialing
• War driving (wireless LAN testing)
• Penetration testing

In actual practice combination of many such techniques may be used to have a more comprehensive assessment of the overall security aspect.

How to write Security test cases?

I shall deal with the approach and the style for writing security test cases.

Before you begin writing your test cases, note that

1) It is important to segregate based on Roles (something like Admin, Manager, Supervisor etc.)

2) You will need to delve into the negative scenario for a particular event initially before taking up the positive scenarios. This will ensure continuity of the test cases and will greatly help.

—0—x—0—0—0—x—0—0—0—x—0—0—0—x—0—0—0—x—0—0—0—x—0—0—0—x—0—0

Given below is a very simple example for the approach to write security test cases. Once you are aware of the knack of writing simple ones like this, you can graduate to writing larger and complex ones. Yes, It is a great aid to novice and intermediate testers to follow these and test the security for any kind of application.

NO.	Action	Test Steps	Pass/ Fail	Comments
1	Invoke the application by typing the URL “http://abhi/myProj/Default.asp”	The browser should be invoked and the application login page should appear.
	Verify the login security for the Project Lead.
2	Login with loginname as “abhilash” and password as “password56″.	The user should be logged in and be directed to the Home page.
3	Verify the menu structure on the Home page.	The home page should contain the following menu structure. - Projects - Tasks - Dashboard - Reports - Skills
4	Verify the menu dropdown for the “Projects” menu.	The “Projects” menu should contain the following menu items. - Create Task - Create Build - Create Module
***	Like this you will need to cover the other menus too.
	End of verification for the Project Lead.
	Verify the login security for a Team Member
1	Login with loginname “anoop” and password as “anooppass”.	The user should be logged in and navigated to the Home page.
2	Verify the menu structure on the Home page.	The home page should contain the following menu structure. - Projects - Tasks - Dashboard - Reports - Skills
3	Verify that the user cannot select the menu item “Projects”.	The user should NOT be able to select the menu item “Projects”. The menu should be displayed as disabled.
4	Verify that the user can select the menu item “Tasks”.	The user should be able to select the menu item “Tasks”. The menu should be displayed as enabled.
5	Verify that the user cannot select the menu item “Dashboard”.	The user should NOT be able to select the menu item “Dashboard”. The menu should be displayed as disabled.
6	Verify that the user can select the menu item “Reports”.	The user should be able to select the menu item “Reports”. The menu should be displayed as enabled.
7	Verify that the user cannot select the menu item “Skills”.	The user should NOT be able to select the menu item “Skills”. The menu should be displayed as disabled.
	like this you will need to tackle each content on respective pages.
	End of verification for the team member.

—-0—x—0——0—x—0—0—0—x—0—0—0—x—0—0—0—x—0—0—0—x—0—0—0—x—0—0

Web Security Testing Checklist:

1. Try to directly access bookmarked web page without login to the system.

2. Do not sign-on system, directly try to download the file from the available download url, such as the input http://url/download?name=file and check if the systems restrict you to download the file.

3. sign out and then press the Back button to access the page accessed before.

4. ID / password authentication method: check with valid and invalid passwords, password rules say cannot be less than 6 characters, user id and password cannot be the same etc.

5. Important information (such as passwords, ID numbers, credit card numbers, etc.) should not get displayed in the input box when typing. They should be all encrypted and in asterix format.

6. Manually change the parameter value in the URL to check if you can access special pages. For example, suppose in a web system If ordinary users access the corresponding url in the parameters l = e and the corresponding url for advanced users in the parameters l = s. Now if a user manually changes the value from e to s it should not allow you to access the page.

7. In the url, enter the following address to check if it can be downloaded restricted files: http://url/download.jsp?file=C: \ windows \ system32 \ drivers \ etc \ hosts,

http://url/download.jsp?file = / etc / password

8. after session time out try to access restricted page.

9. Error messages whether they contain SQL statements, SQL error messages, as well as web server's absolute path, etc.

10. ID / password authentication, the same account on different machines cannot log on at the same time. So at a time only one user can login to the system with a user id.

11. ID / password authentication methods, entered the wrong password several times and check if the account gets locked.

12. Add or modify important information (passwords, ID numbers, credit card number, etc.). Check if it gets reflected immediately or caching the old values.