Requirement Analysis & Definition:

• All possible requirements of the system to be developed are captured in this phase.
Requirements are set of functionalities and constraints that the end-user (who will be
using the system) expects from the system.
• The requirements are gathered from the end-user by consultation.
• The requirements are analyzed for their validity and the possibility of incorporating
the requirements in the system to be development is also studied.
• Finally, a Requirement Specification document is created.

System & Software Design:

• The requirement specifications from first phase are studied in this phase and system
design is prepared.
• System Design helps in specifying hardware and system requirements and also
helps in defining overall system architecture.
• The system design specifications serve as input for the next phase of the model.

Implementation & Unit Testing:

• Once receiving system design documents, the work is divided in modules/units and
actual coding is started.
• The system is first developed in small programs called units, which are integrated in
the next phase.
• Each unit is developed and tested for its functionality; this is referred to as Unit
Testing.
• Unit testing mainly verifies if the modules/units meet their specifications.

Integration & System Testing:

• These units are integrated into a complete system during Integration phase and
tested to check if all modules/units coordinate between each other and the system as
a whole behaves as per the specifications.
• After successfully testing the software, it is delivered to the customer.

Operations & Maintenance:

This phase of "The Waterfall Model" is virtually never ending phase (Very long). Generally,
problems with the system developed (which are not found during the development life cycle)
come up after its practical use starts, so the issues related to the system are solved after
deployment of the system. Not all the problems come in picture directly but they arise time to
time and needs to be solved; hence this process is referred as Maintenance.

There are some disadvantages of the Waterfall Model:

1) As it is very important to gather all possible requirements during the Requirement

Gathering and Analysis phase in order to properly design the system, not all requirements
are received at once, the requirements from customer goes on getting added to the list even
after the end of "Requirement Gathering and Analysis" phase, this affects the system
development process and its success in negative aspects.
2) The problems with one phase are never solved completely during that phase and in fact
many problems regarding a particular phase arise after the phase is signed off, this results in
badly structured system as not all the problems (related to a phase) are solved during the
same phase.

3) The project is not partitioned in phases in flexible way.

4) As the requirements of the customer goes on getting added to the list, not all the
requirements are fulfilled, this results in development of almost unusable system. These
requirements are then met in newer version of the system; this increases the cost of system
development.

Prototype Model:

Step 1: identify the user’s basic requirements

At this stage the systems person works with the user to understand user’s basic needs and
requirements as regards the output from the systems. The systems person establishes
realistic user expectation, estimates the cost of developing the working proto type, defines
data elements required and determines data availability.

Step2: Develop the initial/Working proto type:

The systems person develops the initial working/interactive prototype quickly, which meets
the user’s stated basic requirements. The prototype, performing only the basic functions is
then handed over to the user. While developing the proto type, the systems person may use
the latest tools available to speed up the application development.

Step3: Use the proto type for further refinements:

The user already received the initial proto type which he now puts to use. This working with
the proto type enables the user to gain hands on experience with the proposed system and
helps him to determine as to what extent the proto type meets the user
needs/expectations/requirements. The user rather than systems person, decides the desired
changes for further improving the proto type.

Step4: Revise and enhance proto type:

The systems person takes due notice of the changes suggested by the user and revises,
enhances and refines the proto type accordingly. The proto type is then returned to the user
and the process follows steps 3 and 4 in an interactive mode till the proto type is finally
approved by the user and become operative.

Advantages of Prototyping:

• Ability to ‘tryout’ ideas without incurring large/ huge costs.

• Lower overall development costs when requirements change frequently
• The ability to get a functioning system into the hands of the user quickly.
• Reduced application development time to achieve a functioning system.
• Effective utilization of scarce human resources.

Disadvantages of Prototyping:
 • Prototyping is better suited for smaller modular applications.
• Rapid prototyping can gross over essential steps in systems development.
• The performance may be rather inefficient.
• As the system can be changed easily, documentation may not be kept up-to-date.

Incremental/Iterative Model:

An iterative lifecycle model does not attempt to start with a full specification of requirements.
Instead, development begins by specifying and implementing
just part of the software, which can then be reviewed in order to identify further requirements.
This process is then repeated, producing a new version
of the software for each cycle of the model.

Consider an iterative lifecycle model which consists of repeating the following four phases in
sequence:

-A Requirements phase, in which the requirements for the software are gathered and
analyzed. Iteration should eventually result in a requirements phase that produces a
complete and final specification of requirements.

- A Design phase, in which a software solution to meet the requirements is designed. This
may be a new design, or an extension of an earlier design.

- An Implementation and Test phase, when the software is coded, integrated and tested.

- A Review phase, in which the software is evaluated, the current requirements are reviewed,
and changes and additions to requirements proposed.

For each cycle of the model, a decision has to be made as to whether the software produced
by the cycle will be discarded, or kept as a starting point for the next cycle (sometimes
referred to as incremental prototyping). Eventually a point will be reached where the
requirements are complete and the software can be delivered, or it becomes impossible to
enhance the software as required, and a fresh start has to be made.

The iterative lifecycle model can be likened to producing software by successive

approximation. Drawing an analogy with mathematical methods that use successive
approximation to arrive at a final solution, the benefit of such methods depends on how
rapidly they converge on a solution.

The key to successful use of an iterative software development lifecycle is rigorous validation
of requirements, and verification (including testing) of each version of the software against
those requirements within each cycle of the model. The first three phases of the example
iterative model is in fact an abbreviated form of a sequential V or waterfall lifecycle model.
Each cycle of the model produces software that requires testing at the unit level, for software
integration, for system integration and for acceptance.

As the software evolves through successive cycles, tests have to be repeated and extended
to verify each version of the software.

V- Model
There are two phases in the V model development. They are

1. Verification

2. Validation.

Verification Phases:

Requirements analysis

In this phase, the requirements of the proposed system are collected by analyzing the needs
of the user(s). This phase is concerned about establishing what the ideal system has to
perform. However, it does not determine how the software will be designed or built. Usually,
the users are interviewed and a document called the user requirements document is
generated. The user requirements document will typically describe the system’s functional,
physical, interface,performance, data, security requirements etc as expected by the user.The
users carefully review this document as this document would serve as the guideline for the
system designers in the system design phase. The user acceptance tests(UAT) are
designed in this phase.

System Design

System engineers analyze and understand the business of the proposed system by studying
the user requirements document. They figure out possibilities and techniques by which the
user requirements can be implemented. If any of the requirements is not feasible, the user is
informed of the issue. A resolution is found and the user requirement document is edited
accordingly.The software specification document which serves as a blueprint for the
development phase is generated. This document contains the general system organization,
menu structures, data structures etc. It may also hold examples business scenarios, sample
windows, reports for the better understanding. Other technical documentation like entity
diagrams, data dictionary will also be produced in this phase. The documents for system
testing is prepared in this phase.

Architecture Design

This phase can also be called as high-level design (HLD). The baseline in selecting the
architecture is that it should realize all the requirements within the given time, cost and
resources. Software architecture is commonly represented as two-tier, three-tier or multi-tier
models which typically comprises of the database layer, user-interface layer and the
application layer. The modules and components representing each layer, their inter-
relationships, subsystems, operating environment and interfaces are laid out in detail.The
output of this phase is the high-level design document which typically consists of the list of
modules, brief functionality of each module, their interface relationships, dependencies,
database tables, architecture diagrams, technology details etc. The integration testing design
is carried out in this phase.

Module Design

This phase can also be called as low-level design (LLD). The designed system is broken up
in to smaller units or modules and each of them is explained so that the programmer can
start coding directly. The low level design document or program specifications will contain a
detailed functional logic of the module, in pseudocode - database tables, with all elements,
including their type and size - all interface details with complete API references- all
dependency issues- error message listings- complete input and outputs for a module. The
unit test design is developed in this stage.

Coding

It is the process of writing, testing, and maintaining the source code of computer programs.
The source code is written in a programming language.

Validation Phases

Unit Testing

In the V-model of software development, unit testing implies the first stage of dynamic testing
process.It involves analysis of the written code with the intention of eliminating errors. It also
verifies that the codes are efficient and adheres to the adopted coding standards. Testing is
usually white box. It is done using the Unit test design prepared during the module design
phase. This may be carried out by software testers, software developers or both.

Integration Testing

In integration testing the separate modules will be tested together expose faults in the
interfaces and in the interaction between integrated components. Testing is usually black
box as the code is not directly checked for errors. It is done using the integration test design
prepared during the architecture design phase. Integration testing is generally conducted by
software testers.

System Testing

System testing will compare the system specifications against the actual system. The system
test design derived from the system design documents and is used in this phase. Sometimes
system testing is automated using testing tools. once all the modules are integrated several
erros may rise.Testing done at this stage is called system test.

User Acceptance Testing

Acceptance Testing checks the system against the requirements of the user. It uses black
box testing using real data, real people and real documents to ensure ease of use and
functionality of systems. Users who understand the business functions run the tests as given
in the acceptance test plans, including installation and Online help. Hardcopies of user
documentation are also being reviewed for usability and accuracy. The testers formally
document the results of each test, and provide error reports, correction requests to the
developers

Verification typically involves:

1)Reviews
2)Meetings to evaluate documents
3)Plans
4)Code requirements
5)Walkthroughs and inspections

“Validation” checks whether we are building the system right.

1)Validation typically involves actual testing

2)Takes place after verifications are completed
Web Testing
1. Introduction to Web Application

In software engineering, a Web application is an application that is accessed via

Web browser over a network such as the Internet or an intranet. It is also a
computer software application that is coded in a browser-supported language
(such as HTML, JavaScript, Java, etc.) and reliant on a common web browser to
render the application executable.

Web applications are popular due to the ubiquity of a client, sometimes called a
thin client. The ability to update and maintain Web applications without
distributing and installing software on potentially thousands of client computers
is a key reason for their popularity. Common Web applications include Webmail,
online retail sales, online auctions, wikis, discussion boards, Weblogs, MMORPGs
and many other functions.

2. Testing of Web Applications

As more and more web applications are being developed the need for testing
these is also growing. Here are some important points to be considered while
testing a Web site:

Web sites are essentially¬ client/server applications - with web servers and
‘browser’ clients.

Consideration should be given to the¬ interactions between html pages, TCP/IP

communications, Internet connections, firewalls, applications that run in web
pages (such as applets, JavaScript, plug-in applications), and applications that
run on the server side (such as CGI scripts, database interfaces, logging
applications, dynamic page generators, asp, etc.).

Additionally, there are a wide¬ variety of servers and browsers, various versions
of each, small but sometimes significant differences between them, variations in
connection speeds, rapidly changing technologies, and multiple standards and
protocols. The end result is that testing for web sites can become a major
ongoing effort.

Other considerations include:

What are the expected loads on the¬ server (e.g., number of hits per unit
time?), and what kind of performance is required under such loads (such as web
server response time, database query response times). What kinds of tools will
be needed for performance testing (such as web load testing tools, other tools
already in house that can be adapted, web robot downloading tools, etc.)?

Who is the target audience? What kind¬ of browsers will they be using? What
kinds of connection speeds will they be using? Are they intra- organization (thus
with likely high connection speeds and similar browsers) or Internet-wide (thus
with a wide variety of connection speeds and browser types)?

What kind of performance is expected¬ on the client side (e.g., how fast should
page appears, how fast should animations, applets, etc. load and run)?
Will down time for server and content¬ maintenance/upgrades be allowed? How
much?

What kinds of security (firewalls,¬ encryptions, passwords, etc.) will be required

and what is it expected to do? How can it be tested?

How reliable are the site’s Internet¬ connections required to be? And how does
that affect backup system or redundant connection requirements and testing?

What processes will be required to¬ manage updates to the web site’s content,
and

What are the requirements for¬ maintaining, tracking, and controlling page
content, graphics, links, etc.?

Which HTML specification will be¬ adhered to? How strictly? 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 often?

Can testing be done on the production system, or will a separate test system be
required? How the browser caching, variations in browser are option settings,
dial-up connection variability’s, and real-world internet ‘traffic congestion’
problems to be accounted for in testing?

How extensive or customized are the¬ server logging and reporting

requirements; are they considered an integral part of the system and do they
require testing?

How are CGI programs, applets, java¬ scripts, ActiveX components, etc. to be
maintained, tracked, controlled, and tested?

Pages should be 3-5 screens max unless content is tightly focused on a single
topic. If larger, provide internal links within the page.

The page layouts and design elements¬ should be consistent throughout a site,
so that it’s clear to the user that they’re still within a site.

Pages should be as¬ browser-independent as possible, or pages should be

provided or generated based on the browser-type.

All pages should have links external¬ to the page; there should be no dead-end
pages.

The page owner, revision date, and a¬ link to a contact person or organization
should be included on each page.

3. Checklist for web testing

Functionality¬ Testing.
Usability Testing.¬

Interface Testing.¬

Compatibility¬ Testing.

Performance¬ Testing.

Security Testing.¬

Database Testing.¬

3.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 currently I am working on, in
this 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.

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 session’s ends) check for login sessions and user stats
after session end. Check effect on application security by deleting the cookies. (I
will soon write separate article on cookie testing)

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

3.3 Interface Testing:

Traditionally the incorrect mapping of data between the systems causes these
bugs and these may result in the following types of bug:

Data is inconsistent between systems¬ due to truncation or misinterpretation of

the information.

The software that interfaces between¬ the two systems fails - and no data is
transferred - (this often results in the entire interface failing).

Normally, this is done in two phases:

1. When the interfaces are tested individually during system testing (essentially
using a “dummy” system or stub to mimic the distant system or a closed-loop
system) and

2. When the two systems are tested together with the systems communicating
with one another during integration testing.

The main interfaces are: Web server and application server interface

3.4 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 and 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.

3.5 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,

3.6 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 be denied 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.

3.7 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, this is addressed in web load or performance testing.

Data base testing generally deals with the following:

Checking the integrity of UI data¬ with Database Data

Checking whether any junk data is¬ displaying in UI other than that stored in
Database

Checking execution of stored¬ procedures with the input values taken from the
database tables

Checking the Data¬ Migration.

Execution of jobs if any¬