How to go for Web Application testing

--

Web Applications Testing


I) Overview:

Web Applications are most popular in the IT Industry, having so many advantages like supporting more clients, no client side installation and accessing from anywhere etc…

Types of Web Application

We can categorize web applications in two ways

a) Business Classification
1) Web Sites (They provide information about Organizations or Industries or persons)
2) Web Portals (They are Business gateways, ex: Online Shopping sites, Job portals etc.)
3) Web Applications (They are Service providers (both Free and Paid), apart from information) Ex: Net Banking Applications, Insurance Applications etc…)

b) Technical Classification
1) Intranet Applications (They are private applications, uses local area network (LAN))
2) Internet Applications (They are Public applications, uses Wide area network (WAN)
3) Extranet Applications (They also Private applications over Internet (WAN))

Browser:


It is a Software Application, which retrieves, and Presents information in text, image and voice like different file formats.

The browser is the viewer of a Web Site and there are so many different browsers and browser options that a well-done Web Site is probably designed to look good on as many browsers as possible.

Popular Browsers:
1) Internet Explorer
2) Mozilla Firefox
3) Google Chrome
4) Safari
5) Opera
Etc…

II) Web Technologies:
Ø HTML (Hyper Text Markup Language) – for displaying web pages
Ø XML (Extensible Markup Language) –for Transporting the Data
Ø Java Script – for Client Side Validations
Ø VB Script – for Server side Validations
Ø IIS, Apache, Tomcat, Pramathi – as Web servers
Ø JBoss, WebLogic, WebSpeare, COM+ - as Application Servers
Ø Java, C#.NET, VB.NET, VC++.NET for Components development
Ø SQL Server, Oracle, MySQL as Database Servers
Ø HTTP, SOAP – as Protocols


III) Web Testing

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.

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 crawl able to different search engines.

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.

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

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

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.

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?

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.

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,

Security Testing:

Following are some tests 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 log in user. Access should deny for this user to view others stats.
Try some invalid inputs in input fields like login username, password and 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.
Web Testing is an essential topic now a days


Taken from "http://www.gcreddy.com/2010/10/web-testing.html"

How much testing is enough?

When we go market to buy a product, which product would you like to buy, a completed tested or a partially tested. No body wants to have a partially or no tested product. But is it possible to test the whole product? Let’s understand this with a login page example; a login page has generally two textboxes, one for user name and other for password. Now, if you have given 2 valid username and password to test then you can try entering both and can test the application. But what if you have thousands of username and password? Are you going to test the system with each and every username and password?

Exhaustive testing is impossible, but we can always try to design our test cases in such a way that they are as per time, budget and other technical aspects of the product.

Testing and quality

Testing help us to measure the quality of software in terms of the number of defects found, the tests run, and the system covered by the tests. Testing can give confidence in the quality of the software.

Of course, a poor test may uncover few defects and leave us with a false sense of security. A well-designed test will uncover defects if they are present and so, if such a test passes, we will rightly be more confident in the software and be able to assert that the overall level of risk of using the system has been reduced and we can gain confidence on the quality of the software.

what is Retesting and Regression Testing

Regression testing

Throughout all testing cycles, regression test cases are run. Regression testing is

selective retesting of a system or component to verify that modifications have not caused

unintended effects and that the system or component still complies with its specified

requirements.

Regression tests are a subset of the original set of test cases. These

test cases are re-run often, after any significant changes (bug fixes or enhancements) are

made to the code. The purpose of running the regression test case is to make a “spot

check” to examine whether the new code works properly and has not damaged any

previously-working functionality by propagating unintended side effects.

Retesting

Retesting is testing of system or component to verify that modifications of the system or component still complies with its specified requirements.

Re-testing is performed after any modification to verify if the new code is working correctly. In re-testing tester re-execute the testcases on same application build with diferent inputs or testdata.

What are Exit Criteria?

The testing strategy or high-level test plan document is quite often used as the exit criteria. The exit criteria would also include other details such as how well that tests needs to have been done. For example it may state that you need to have tested everything and have found no serious errors but minor errors are acceptable.

Testing is an iterative process and as it is impossible to test everything we could just keep going round the loop indefinitely.

If the exit criteria has been stated in advance then testing can stop when the exit criteria has been met. In other words we can thus say that the exit criteria are the criteria to be met in other to stop testing.

The exit criteria will therefore depend on the following: -

· The risk to the business process of the project.

· The time constraints within the project.

· The resource constraints within the project.

· The budget of the project.

What is root cause analysis?

Root cause analysis (RCA) is a class of problem solving methods aimed at identifying the root causes of problems or events. The practice of RCA is predicated on the belief that problems are best solved by attempting to correct or eliminate root causes, as opposed to merely addressing the immediately obvious symptoms. By directing corrective measures at root causes, it is hoped that the likelihood of problem recurrence will be minimized. However, it is recognized that complete prevention of recurrence by a single intervention is not always possible. Thus, RCA is often considered to be an iterative process, and is frequently viewed as a tool of continuous improvement.

V-Model

The V-model was developed to address some of the problems experienced using the traditional waterfall approach. Defects were being found too late in the life cycle, as testing was not involved until the end of the project. Testing also added lead time due to its late involvement. The V-model provides guidance that testing needs to begin as early as possible in the life cycle, which, as we've seen in Chapter 1, is one of the fundamental principles of structured testing. It also shows that testing is not only an execution based activity. There are a variety of activities that need to be performed before the end of the coding phase. These activities should be carried out in parallel with development activities, and testers need to work with developers and business analysts so they can perform these activities and tasks and produce a set of test deliverables. The work products produced by the developers and business analysts during development are the basis of testing in one or more levels. By starting test design early, defects are often found in the test basis documents. A good practice is to have testers involved even earlier, during the review of the (draft) test basis documents.

The V-model is a model that illustrates how testing activities (verification and validation) can be integrated into each phase of the life cycle. Within the V-model, validation testing takes place especially during the early stages, e.g. reviewing the user requirements, and late in the life cycle, e.g. during user acceptance testing. Although variants of the V-model exist, a common type of V-model uses four test levels.

The four test levels used, each with their own objectives, are:
• Component testing: searches for defects in and verifies the functioning of software components (e.g. modules, programs, objects, classes etc.) that are separately testable;
• Integration testing: A test interfaces between components, interactions to different parts of a system such as an operating system, file system and hard ware or interfaces between systems;
• System testing: concerned with the behavior of the whole system/product as defined by the scope of a development project or product. The main focus of system testing is verification against specified requirements;
• Acceptance testing: validation testing with respect to user needs, requirements, and business processes conducted to determine whether or not to accept the system.

In practice, a V-model may have more, fewer or different levels of development and testing, depending on the project and the software product. For example, there may be component integration testing after component testing and system integration testing after system testing. Test levels can be combined or reorganized depending on the nature of the project or the system architecture. For the integration of a commercial off-the-shelf
(COTS) software product into a system, a purchaser may perform only integration testing at the system level (e.g. integration to the infrastructure and other systems) and at a later stage acceptance testing.



Note that the types of work products mentioned in Figure 2.2 on the left side of the V-model are just an illustration. In practice they come under many different names. References for generic work products include the Capability Maturity Model Integration (CMMi) or the 'Software life cycle processes' from ISO/IEC 12207. The CMMi is a framework for process improvement for both system engineering and software engineering. It provides guidance on where to focus and how, in order to increase the level of process maturity