What are different stages involved in web application testing?

Web application is a dynamic extension of an application server. Testing of a web application is done by a web application tester. Testing a web application involves different stages as follows:

Functionality testing:
In functionality testing, tests are made to check the links in web pages, database connection, forms used in web pages to submit or retrieve information from users.

Testing the links involves the following:
- Checking the outgoing links in all the pages from the specific domain under test.
- Internal links testing.
- Checking the links that jump on the same pages.
- The Links through which the email will be sent to the admin or to other users from different web pages must be checked.
- All the above mentioned links must be checked for broken links.

Testing the forms in all the web pages:
- Each field in a form must be checked for validity.
- Default values of each field must be checked.
- Options for creating, modifying, viewing or deleting a form must be verified during testing.

Testing of cookies:
The application must be tested by enabling or disabling cookies in browser options. The cookies must be tested for encryption before writing to user system. The session cookies must be tested for login sessions and user status after session ends.

Testing of database:
Data integrity must be monitored every time when data is created, modified, viewed or deleted within a database. Every database related functionality must be tested.

Usability testing:
Usability determines the ease with which a user can handle the application. The webpage designed must be user friendly with appropriate main menu in each page. It is very important to ensure that the application is readable and understandable by a user. It is recommended to use commonly accepted standards for font, frames and colors. Anchor text links must be analyzed.

Interface testing:
Web server, application server and database server are the main interfaces. Ensure whether each interaction between each of the interfaces is executed without any errors. Errors when occurred must be handled appropriately.

Compatibility testing:
Compatibility of a web application is a very important testing aspect. A web application must be compatible mainly with Browser and Operating System.

Browser compatibility:
A web application must be tested with different browsers to ensure its compatibility. Various browsers have different settings and configurations with which the application must be compatible. Web coding must be compatible with cross browser platform. If java scripts or AJAX calls are used for UI functionality and performing security checks or validations, browser compatibility must be given importance.

OS compatibility:
New technologies such as graphic designs, interface calls used in web development must be compatible with various browsers, which are popularly used.

Performance testing:
Performance of an application is measured by its ability to sustain load and stress. Load testing and stress testing are two main types of performance testing.

Load testing:
When large number of users requests the same page, the application must have the ability to sustain the load and perform appropriately. Performance of an application must be tested on different internet connections with varying speed.

Stress testing:
In stress testing the application is put beyond its limit of sustainability, to check the reaction of the application to stress or to check how the system recovers from crash.

Security testing:
Security testing must ensure that only authorized users can use the application and none of the internal pages must be opened for non registered users. CAPTCHA can be utilized to improve security in application.

Estimation technique for an Agile Development

In previous posts, we have discussed various methods of estimation such as lines of code and function point. These are typically used for most software projects. But when you consider a project of very short software duration(consider a project which last just a few weeks) and also where there can be changes in requirements during the timeline of the project, it is difficult to use the lines of code or function point method. In such cases, one of the possible estimation technique is called estimation for agile development.

In a typical agile project, requirements are captured as stories or user scenarios; a different estimation method can be used for such projects. Some of the steps that are to be followed in such an agile project are:

- The estimation of each of the user stories is done on a standalone basis. Suppose the overall project has ten different user stories, we would need to do, at the minimum ten separate rounds of estimation.

- Each user story is further sub-divided into functions and tasks. Typically, each task is a separate discrete engineering unit, the start and end of which can be tracked separately from other tasks.

- Each task is a lowest unit at which estimation is done; at the end of the activity all the tasks have estimates. The engineering team is thus expected to provide estimates for each individual tasks.

- All these estimates for a user story are sum to create the total estimate for each user story.

- At a higher level, the estimates of all the user stories are summed to create the overall estimate.

Automated Estimation Techniques and Tools - Functions and types of tools

Automated estimation techniques and tools allows the planner to estimate the cost and effort and to perform what-if analysis for important project variables such as delivery date or staffing. If applying different estimation tools on the same project data, variation in estimated results are encountered. Sometimes, the predicted values are different from the actual values. The output of estimation tools should be used as one data point from which estimates are derived.

The six functions performed by the automated estimation tools are:

- Sizing of project deliverable.
- Selecting project activities.
- Predicting staffing levels.
- Predicting software effort.
- Predicting software cost.
- Predicting software schedules.

These automated tools require an estimate of project size for example LOC and FP. They require qualitative project characteristics such as complexity, reliability, or business criticality. They also require description of the development staff and/or development environment.

- Tools like BYL (Before You Leap) and WICOMO (Wang Institute Cost Model) require the user to provide lines of code estimates and these estimates are categorized by programming language and type. These tools produces estimated elapsed project duration (in months), effort in staff-months, average staffing per month, average productivity in LOC/pm, and cost per month.
- SLIM is an automated costing system based on the Rayleigh-Putnam Model.
- ESTIMACS uses function point estimation method. It helps the planner to estimate system development effort, cost and staff, the risk and the hardware configuration.
- SPQR/20 developed by Software Productivity Research Inc. It has the user complete a simple set of multiple choice questions.

Estimation techniques - estimation using use cases

We have read about estimation techniques like problem and process based estimation techniques. There is another estimation approach that uses use cases which provide insight into software scope and requirements. However, it is somewhat difficult to develop an estimation technique using use cases.

- There is no standard format or style in which use cases can be described because there are many different formats and styles that a use case can use.
- The complexity of the functions are not addressed by the use cases.
- Complex behavior like interactions among many functions and features are not described by the use cases.
- Use cases are used to represent the user's view of the software.

Use case estimation technique for one person can require a lot of effort while use case estimation technique for some other person can be done in a day or two. According to Smith, use cases can be used for estimation but it is only possible and considered within the context of structural hierarchy that the use case describe.

- structural hierarchy can have not more than 10 use cases.
- each use case can have not more than 30 different scenarios.
- before using use case estimation, level within structural hierarchy is established, average length of each use case is computed, type of software is defined, rough architecture is considered.
- empirical data is used to establish lines of code or function point for each level.

Estimation techniques - Process based Estimation

Another technique that is used is estimating a project on the basis of estimating the base on the process that will be used. A process is decomposed into small tasks and effort that is required to fulfill each task is estimated. As apart of this process one is required to take the project scope and derive software functions from the scope. Now typically, for each function, there are a series of framework activities that must be performed. A 2*2 table would typically be constructed which maps these functions and the related framework activities.

Once you get the problem functions and the process activities, the table is filled by estimating the effort for each software activity for each software function. Once you are done with all the estimation, you have a complete table that forms an input for an estimation of the total cost. As a part of this step, you need to have values for the costing for the various activities. As an example, initial architectural and design activities are done by more senior and experienced people, with the costing for these resources being significantly more than the costing for future coding and testing.

Based on the above, we can generate a total cost. We can also generate the total cost through the lines of code and function point methods. Now, we have three methods of costing and can compare one against the other. If these are close to each other, then the estimates are reliable. If this is not so, then more investigation is required. This would require that the steps that have been taken to research and estimate through the lines of code, function point, or process based estimation would need to be re-examined in much more detail until possible errors are detected and estimates re-calculated.

Estimation techniques - Problem based Estimation

In software estimation, lines of code and function point metrics can be used in two ways:
- it can be used as an estimation variable that could size each element of the software.
- it can be used as baseline metrics that are collected from past projects and are used with the estimation variables to develop cost and effort.

Lines of code and function point are different techniques but there are some characteristics that are common. Project planning begins with scope of the software and software is decomposed into problem functions and are estimated individually and then lines of code and function point are estimated for each function.

Baseline metrics are applied to estimation variable and cost and effort is derived. It should be kept in mind when collecting productivity metrics for projects, one should be sure to establish a taxonomy of project types. This will enable to compute domain specific averages making estimation more accurate.

LOC and FP techniques differ in how decomposition is used. Consider a case when LOC is used, it is essential to use decomposition and that too to a fairly detailed level. In order to get a higher level of accuracy, it is necessary to have a high degree of partitioning.

Now considering the case of FP, the usage of decomposition is different. It is required to get the five information domain characteristics, and the complexity adjacent values. Once these are available, and using past data, an estimate can be generated.

Alongside, a project planner estimates a range of values using historical data; these are the optimistic, most likely, and pessimistic sizes for each function. Based on these, an expected value for the estimation variable can be calculated.

Project Estimation - Decomposition techniques - Estimating the software size

In the estimation of software cost and effort, many variables that include human, technical, environmental, political can affect final cost and effort applied to software. It is a complex process. Decomposing the problem and re-characterization it into a set of smaller problems is an approach for software project estimation.

Decomposition approach has two point of views :
- problem decomposition
- process decomposition

Before estimating, estimating the size of the software is very important. The size of the software to be built can be estimated using lines of code which is a direct measure or through function point which is an indirect measure. Estimating software size is a major challenge. Size is the quantifiable outcome of software project.

Approaches to sizing problems are:
- Fuzzy logic sizing: Identify the application, its magnitude and refining the magnitude within original range.
- Function point sizing: Estimates of information domain characteristics are developed.
- Standard component sizing: The number of occurrences of each standard component
is estimated and project data is used to calculate the delivered size per standard component.
- Change sizing: Suppose an existing software is modified in some way. In this approach, the number and type of modifications are estimated.

These approaches were suggested by Putnam and Myers.