Software Testing Tutorial

Software testing is an integral part of Software Development Life Cycle. Testing software or any
product in day-to-day business applications or in our daily routine work becomes necessary as
going around with these, will mess up things. This session helps you travel through the journey
of software testing in the form of software testing tutorial.

Software Development Life Cycle (SDLC) is a procedural process, in the development of a

software product. The process is carried in a set of steps, which explains the whole idea about
how to go through each product. 
The classification of Software Development Life Cycle process is as follows

Planning

1. Analysis
2. Design
3. Software Development
4. Implementation
5. Software Testing
6. Deployment
7. Maintenance

Software Testing is an important factor in a product's life cycle, as the product will have greater
life, only when it works correctly and efficiently according to the customer's requirements. 

Introduction to Software Testing

Before moving further towards introduction to software testing, we need to know a few

concepts that will simplify the definition of software testing.

 Error: Error or mistake is a human action that produces wrong or incorrect result.
  Defect (Bug, Fault): A flaw in the system or a product that can cause the component to
fail or misfunction.
 Failure: It is the variance between the actual and expected result.
 Risk: Risk is a factor that could result in negativity or a chance of loss or damage.

Thus Software testing is the process of finding defects/bugs in the system, that occurs due to an
error in the application, which could lead to failure of the resultant product and increase in
probability of high risk. In short, software testing have different goals and objectives, which
often include:

1. finding defects;
2. gaining confidence in and providing information about the level of quality;
3. preventing defects.

Scope of Software Testing

The primary function of software testing is to detect bugs in order to correct and uncover it.
The scope of software testing includes execution of that code in various environment and also
to examine the aspects of code - does the software do what it is supposed to do and function
according to the specifications? As we move further we come across some questions such as
"When to start testing?" and "When to stop testing?" It is recommended to start testing from
the initial stages of the software development. This not only helps in rectifying tremendous
errors before the last stage, but also reduces the rework of finding the bugs in the initial stages
every now and then. It also saves the cost of the defect required to find it. Software testing is
an ongoing process, which is potentially endless but has to be stopped somewhere, due to the
lack of time and budget. It is required to achieve maximum profit with good quality product,
within the limitations of time and money. The tester has to follow some procedural way
through which he can judge if he covered all the points required for testing or missed out any.
To help testers to carry out these day-to-day activities, a baseline has to be set, which is done in
the form of checklists.

Software Testing Key Concepts

 Defects and Failures: As we discussed earlier, defects are not caused only due to the
coding errors, but most commonly due to the requirement gaps in the non-functional
requirement, such as usability, testability, scalability, maintainability, performance and
security. A failure is caused due to the deviation between an actual and an expected
result. But not all defects result to failures. A defect can turn into a failure due to the
change in the environment and or the change in the configuration of the system
requirements.
 Input Combination and Preconditions: Testing all combination of inputs and initial state
(preconditions), is not feasible. This means finding large number of infrequent defects is
difficult.
 Static and Dynamic Analysis: Static testing does not require execution of the code for
finding defects, whereas in dynamic testing, software code is executed to demonstrate
the results of running tests.
 Verification and Validation: Software testing is done considering these two factors.
1. Verification: This verifies whether the product is done according to the
specification?
2. Validation: This checks whether the product meets the customer requirement?
 Software Quality Assurance: Software testing is an important part of the software
quality assurance. Quality assurance is an activity, which proves the suitability of the
product by taking care of the quality of a product and ensuring that the customer
requirements are met.

Software Testing Types:

Software test type is a group of test activities that are aimed at testing a component or system
focused on a specific test objective; a non-functional requirement such as usability, testability
or reliability. Various types of software testing are used with the common objective of finding
defects in that particular component. 

Software testing is classified according to two basic types of software testing: Manual Scripted
Testing and Automated Testing.

Manual Scripted Testing:

 Black Box Testing

 White Box Testing
 Gray Box Testing

The levels of software testing life cycle includes :

 Unit Testing
 Integration Testing
 System Testing
 Acceptance Testing
1. Alpha Testing
2. Beta Testing

Other types of software testing are:

 Functional Testing
 Performance Testing
1. Load Testing
2. Stress Testing

 Smoke Testing
 Sanity Testing
 Regression Testing
 Recovery Testing
  Usability Testing
 Compatibility Testing
 Configuaration Testing
 Exploratory Testing

Automated Testing: Manual testing is a time consuming process. Automation testing involves
automating a manual process. Test automation is a process of writing a computer program in
the form of scripts to do a testing which would otherwise need to be done manually. Some of
the popular automation tools are Winrunner, Quick Test Professional (QTP), LoadRunner,
SilkTest, Rational Robot, etc. Automation tools category also includes maintenance tool such as
TestDirector and many other.

Software Testing Methodologies

The software testing methodologies or process includes various models that built the process of
working for a particular product. These models are as follows:

 Waterfall Model
 V Model
 Spiral Model
 Rational Unified Process(RUP)
 Agile Model
 Rapid Application Development(RAD)

Software Testing Artifacts

Software testing process can produce various artifacts such as:

 Test Plan: A test specification is called a test plan. A test plan is documented so that it
can be used to verify and ensure that a product or system meets its design specification.
  Traceability matrix: This is a table that correlates or design documents to test
documents. This verifies that the test results are correct and is also used to change tests
when the source documents are changed.
 Test Case: Test cases and software testing strategies are used to check the functionality
of individual component that is integrated to give the resultant product. These test
cases are developed with the objective of judging the application for its capabilities or
features.
 Test Data: When multiple sets of values or data are used to test the same functionality
of a particular feature in the test case, the test values and changeable environmental
components are collected in separate files and stored as test data.
 Test Scripts: The test script is the combination of a test case, test procedure and test
data.
 Test Suite: Test suite is a collection of test cases.

Software Testing Process

Software testing process is carried out in the following sequence, in order to find faults in the
software system:

1. Create Test Plan

2. Design Test Case
3. Write Test Case
4. Review Test Case
5. Execute Test Case
6. Examine Test Results
7. Perform Post-mortem Reviews
8. Budget after Experience
Here is a sample Test Case for you:

# Software Test Case for Login Page:

 Purpose: The user should be able to go to the Home page.

 Pre-requisite:
1. S/w should be compatible with the Operating system.
2. Login page should appear.
3. User Id and Password textboxes should be available with appropriate labels.
4. Submit and Cancel buttons with appropriate captions should be available.
 Test Data: Required list of variables and their values should be available.eg: User Id:
{Valid UserId, Invalid UserId, empty}, Password:{Valid, Invalid, empty}.

Test
Sr.No Case Test Case Name Steps/Action Expected Results
Id

User views the page to check

whether it includes UserId and
Password textboxes with Screen dispalys user
Checking User Interface
1. TC1. appropriate labels. Also expects interface requirements
requirements.
that Submit and Cancel buttons according to the user.
are available with appropriate
captions

2. TC2. Textbox for UserId i)Error message is

i)User types numbers into the
should: displayed for numeric
textbox.
i)allow only alpha- data.
numeric characters{a-z,
ii)User types alphanumeric data ii)Text is accepted
A-Z}
in the textbox. when user enters
ii)not allow special
alpha-numeric data

characters
like{'$','#','!','~','*',...} 
iii)not allow numeric
Checking functionality of textbox.
the Password textbox:
i)Textbox for Password
should accept more than ii)User enters more than six
3. TC3.
six characters.
ii)Data should be
displayed in encrypted
format.
i)User enters only two
characters in the password
characters in the password
textbox.
ii)User checks whether his data
is displayed in the encrypted
format.
into the textbox.
i)Error message is
displayed when user
enters less than six
characters in the
password textbox.
System accepts data
when user enters more
than six characters into
the password textbox.
System accepts data in
the encrypted format
else displays an error
message.

i)System displays
i)User checks whether 'SUBMIT'
'SUBMIT' button as
button is enabled or disabled.
enabled

Checking functionality of ii)System is redirected

4. TC4.
'SUBMIT' button. ii)User clicks on the 'SUBMIT' to the 'Home' page of
button and expects to view the the application as soon
'Home' page of the application. as he clicks on the
'SUBMIT' button.

5. TC5. Checking functionality of i)User checks whether 'CANCEL' i)System displays

'CANCEL' button. button is enabled or disabled. 'CANCEL' button as
 enabled.

ii)System clears the

ii)User checks whether the data available in the
textboxes for UserId and UserId and Password
Password are reset to blank by textbox when user
clicking on the 'CANCEL' button. clicks on the 'CANCEL'
button.

Fault Finding Techniques in Software Testing

Finding of a defect or fault in the earlier parts of the software not only saves time and money,
but is also efficient in terms of security and profitability. As we move forward towards the
different levels of the software, it becomes difficult and tedious to go back for finding the
problems in the initial conditions of the components. The cost of finding the defect also
increases. Thus it is recommended to start testing from the initial stages of the life cycle.

There are various techniques involved alongwith the types of software testing. There is a
procedure that is to be followed for finding a bug in the application. This procedure is combined
into the life cycle of the bug in the form of contents of a bug, depending upon the severity and
priority of that bug. This life cycle is named as the bug life cycles, which helps the tester in
answering the question - how to log a bug?

Measuring Software Testing

There arises a need of measuring the software, both, when the software is under development
and after the system is ready for use. Though it is difficult to measure such an abstract
constraint, it is essential to do so. The elements that are not able to be measured, needs to be
controlled. There are some important uses of measuring the software:
  Software metrics helps in avoiding pitfalls such as
1. cost overruns,
2. in identifying where the problem has raised,
3. clarifying goals.
 It answers questions such as:
1. What is the estimation of each process activity?,
2. How is the quality of the code that has been developed?,
3. How can the under developed code be improved?, etc.
 It helps in judging the quality of the software, cost and effort estimation, collection of
data, productivity and performance evaluation.

Some of the common software metrics are:

 Code Coverage
 Cyclomatic complexity
 Cohesion
 Coupling
 Function Point Analysis
 Execution time
 Source lines of code
 Bug per lines of code

In short, measurement of a software is for understanding, controlling and improvement of the

software system. Software is subject to changes, with respect to, changing environmental
conditions, varying user requirements, as well as configuration and compatibility issues. This
gives rise to the development of newer and updated versions of software. But, there should be
some source of getting back to the older versions easily and working on them efficiently.
Testers play a vital role in this. Here is where change management comes into picture.
What is DDLC or Document Life Cycle?
DDLC means Document Development Life Cycle. In software industry there are main two types
of cycles SDLC and DDLC. Technical Writers are connected with Document Development Life
Cycle. Following is brief explanation of DDLC.

1. Understanding the Requirements

Understanding requirements is the first phase of the document development life
cycle. In this phase the technical writer is supposed to understand all the
requirements of the project. As per the project or document type technical
writer starts to gather the material that is useful for the project. The necessary
information is gathered and analyzed in this phase. In the beginning of the
project technical writer tries to understand what are the requirements of the
project and gathers material to build the project. 

This process involves lot of efforts. Subject matter expert who is the genesis of
the knowledge provides information regarding the project. Technical writer
meets software developers and learns the features of the new product.
Technical writer resolves all the queries and problems regarding the project with
the help of SME and software developers. The help received from SME and
software developers is not sufficient to work on the project. Technical writer
searches the related information on online libraries and from the company
resource. Previous completed projects also help in building the new project if it
has some connections with the new one. 

This phase can be called study of functional domain. Technical writer needs to
discuss the issues with knowledgeable people for the appropriate information
and guidance. Meeting with important people connected with the project proves
beneficial. This phase involves using and experimenting the product in various
ways that gives an idea about the new product. At the end of this phase
technical writer must have resolved all the problems and queries in terms of
understanding the documentation. Technical writer must study the software
from the technical point of view so that will be able to explain well in the
document for audience. 

2.Audience Analysis
Technical writer writes documents or user manuals for the audience or users.
Audience is inseparable part of the documentation. Technical writer must know
the type of audience group that is going to use the product. There are varieties
of audience available Worldwide. Across the world all the audience are not at
the same level or similar in their usage and understanding of the product.
Audience varies as per the product. All the audience does not use all the
products. There are many types of audience but mainly categorized in two -
General Audience (Novice Audience) and Experienced Audience (Special
Audience). 

These categories are based on the education and knowledge of user about the
product. Novice user is the person who is completely blank about the product
information. Novice user purchases the product on their knowledge that gained
from the society and tries to use it. Experienced users are completely contrary to
the novice audience. Special users have either complete or little bit knowledge of
product. Mostly educated people come under the category of special audience.
There are two sources to know your audience- Internal Source and External
Source. Internal source means to get knowledge about the audience from
software developers for whom they are making the product. You can also ask to
SME about an audience. Believe what the software developers and SME are
telling but don't rely on them. Try to find out the information about your
audience from external sources means vising actual audience who are going to
use the product. 

3.Outlining the Document

This phase helps you to create the outline of the document. Outlining the
document is the overall plan of the document. It is the skeletal framework of
your document. It shows overall structure of the document. Outline of the
document do not contain the elements in explained way but in brief. In this
phase you just put all the elements serially to expand them so that you won't
miss any one of the elements from document. Outlining the document is the
well defined plan that can be discussed explicitly. Outline of the document is
similar to the skeleton without flesh. Outline gives an idea about the placement
of the elements in the Ad. The skeletal information comprises of Preface or
introduction, Table of Contents, Chapter information/sequence, index,
bibliography etc. Technical writer only needs to explain all the elements once the
plan is ready. Outline of the document gives the clear view of the complete
document at a glance. 

4.Preparing Prototype

A style guide or style manual is a set of standards for design and writing of
documents, either for general use or for a specific publication or organization.
Preparing prototype comprises of several important stages such as template
consideration, developing Style Guides etc. 

Template Consideration- Template is the physical appearance of the document.

While deciding template you need to decide all the specifications and standards
regarding the template of the Ad. Page size, page margins, fonts, headings, list
types, alignments, gutter space, etc are to be supposed while contemplating the
template. Once the template is ready develop the contents in main sections and
prepare a detailed design. 

Style Guides- Style guides are particularly important in technical writing projects.

A style guide or style manual is a set of standards for design and writing of
documents, either for general use or for a specific publication or organization.
Where technical writing is undertaken in a large team or project, it is important
that the finished documentation is devoid of any one individual's discernible
personal style. A style guide is just one of the tools that can be used to help
achieve this along with 5the use of specific standards. Style guide is the guide of
rules and regulations that are followed by every person working on the project.
Microsoft style Guide for Technical Publication is the best industry standard style
guide that is used in most of the companies. 

5.Developing Actual Help System

In this phase the actual development of help system starts. Technical writer
explains all the contents that are collected and planned in outlining phase. This
phase gives birth to the document. The duration of this phase is greater than the
other phases. Once the template is defined all the contents are explained
explicitly in the document. Detailed table of contents is created with page
numbers in this stage. Cross references are created and maintained. Glossary
and index is created after completion of the document. In this stage technical
writer needs to perform all the actions that are supposed to build complete
document. 

6.Review
Review means to check the Document for any errors and some other
corrections. There re three types of reviews- Peer Review, Technical review and
Functional Review. 

Peer review- Peer review (also known as refereeing) is the process of subjecting

an author's work, research or ideas to the scrutiny of others who are experts in
the same field. Peer review requires a community of experts in a given field, who
are qualified and able to perform impartial review. Impartial review, especially of
work in less narrowly defined or inter-disciplinary fields, may be difficult to
accomplish; and the significance (good or bad) of an idea may never be widely
appreciated among its contemporaries. Peer review has been criticized as
ineffective, slow, and misunderstood This process encourages authors to meet
the accepted standards of their discipline and prevents the dissemination of
irrelevant findings, unwarranted claims, unacceptable interpretations, and
personal views. Publications that have not undergone peer review are likely to
be regarded with suspicion by scholars and professionals.

Technical Review- The purpose of a technical review is to arrive at a technically

superior version of the work product reviewed, whether by correction of defects
or by recommendation or introduction of alternative approaches. A technical
review is a form of peer review in which "a team of qualified personnel ...
examines the suitability of the documents for its intended use and identifies
discrepancies from specifications and standards. Technical reviews may also
provide recommendations of alternatives and examination of various
alternatives" 

7.Packaging
 Packaging means making the product ready to deliver to the client. There are
two types of Packaging- Book design and binding, Integrating help in Application.
If the help manual is in book format which is supposed to go along with the
product, goes for printing to produce copies. Online help is integrated with the
help of software developers in the respective application. Online help is always
delivered with the help of CD or the devices that can be used to carried out the
data. There are different types of delivering the help to the clients depending on
the product.
2. SDLC

The SDLC process was designed to ensure end-state solutions meet user requirements in
support of business strategic goals and objectives. In addition, the SDLC also provides a detailed
guide to help Program Managers with ALL aspects of IT system development, regardless of the
system size and scope. The SDLC contains a comprehensive checklist of the rules and
regulations governing IT systems, and is one way to ensure system developers comply with all
applicable Government regulations, because the consequences of not doing so are high and
wide ranging. This is especially true in the post 9/11 environment where larger amounts of
information are considered sensitive in nature, and are shared among commercial,
international, Federal, state, and local partners.

The seven-step process contains a procedural checklist and the systematic progression required
to evolve an IT system from conception to disposition. The following descriptions briefly explain
each of the seven phases of the SDLC:

1. Conceptual Planning. This phase is the first step of any system's life cycle. It is during this
phase that a need to acquire or significantly enhance a system is identified, its feasibility and
costs are assessed, and the risks and various project-planning approaches are defined. Roles
and responsibilities for the Asset Manager, Sponsor's Representative, System Development
Agent (SDA), System Support Agent (SSA), and other parties in SDLC policy are designated
during this stage and updated throughout the system's life cycle.
2. Planning and Requirements Definition. This phase begins after the project has been defined
and appropriate resources have been committed. The first portion of this phase involves
collecting, defining and validating functional, support and training requirements. The second
part is developing initial life cycle management plans, including project planning, project
management, Configuration Management (CM), support, operations, and training
management.

3. Design. During this phase, functional, support and training requirements are translated into
preliminary and detailed designs. Decisions are made to address how the system will meet
functional requirements. A preliminary (general) system design, emphasizing the functional
features of the system, is produced as a high-level guide. Then a final (detailed) system design is
produced that expands the design by specifying all the technical detail needed to develop the
system.

4. Development and Testing. During this phase, systems are developed or acquired based on
detailed design specifications. The system is validated through a sequence of unit, integration,
performance, system, and acceptance testing. The objective is to ensure that the system
functions as expected and that sponsor's requirements are satisfied. All system components,
communications, applications, procedures, and associated documentation are
eveloped/acquired, tested, and integrated. This phase requires strong user participation in
order to verify thorough testing of all requirements and to meet all business needs.

5. Implementation. During this phase, the new or enhanced system is installed in the
production environment, users are trained, data is converted (as needed), the system is turned
over to the sponsor, and business processes are evaluated. This phase includes efforts required
to implement, resolve system problems identified during the implementation process, and plan
for sustainment.

6. Operations and Maintenance. The system becomes operational during this phase. The
emphasis during this phase is to ensure that sponsor needs continue to be met and that the
system continues to perform according to specifications. Routine hardware and software
maintenance and upgrades are performed to ensure effective system operations. User training
continues during this phase, as needed, to acquaint new users to the system or to introduce
new features to current users. Additional user support is provided, as an ongoing activity, to
help resolve reported problems.

7. Disposition. This phase represents the end of the system's life cycle. It provides for the
systematic termination of a system to ensure that vital information is preserved for potential
future access and/or reactivation. The system, when placed in the Disposition Phase, has been
declared surplus and/or obsolete and has been scheduled for shutdown. The emphasis of this
phase is to ensure that the system (e.g., equipment, parts, software, data, procedures, and
documentation) is packaged and disposed of in accordance with appropriate regulations and

requirements.

Each column in the graphic represents an individual phase. The documents in each phase are
created and maintained throughout the rest of the development cycles until the final
disposition of the project. Although this indicates the process is linear, it is not. It is iterative
and once a project is deployed, the management of the project may return to requirements
gathering to start all over again.

Avison and Fitzgerald in their book Information Systems Development: Methodologies,

Techniques and Tools describe the Systems Development Life Cycle:

This methodology has the following steps:

 Feasibility study
 System investigation
 Systems analysis
 Systems design
 Implementation
 Review and maintenance
These stages together are frequently referred to simply as [...] the 'waterfall
model'. (see WaterfallModel)

They go on to say:

The term 'life-cycle' indicates the iterative nature of the process...

This methodology, they say, was described completely in 1971 by Daniels and Yeates (Basic
Training in Systems Analysis. 2nd ed., Pitman, London).

It has some interesting features that make it, to my mind, less abstract than the pure (and
perhaps mythical) WaterfallModel. Each phase is considered in the context of the current
system. The second stage is essential grounding for this. Here the systems analyst tries
to see the problems and not just hear them. She tries to become the customer.

The next stage, 'Systems analysis', may go beyond what the customer knows. It explores the
history of the system. It asks how and why is has developed this way. Should the procedures of
today be automated, or should the system take a new direction?

There is a conspicuous lack of references to programming in this model. The idea, I think, is that
certain problems are best fixed at the systems level. You don't always have to dive for the
keyboard. Some other areas that the SDLC thinks important: Legal and social feasibility, the
purchase and installation of hardware and software as an implementation consideration and
the consideration of future scalability. All things I'm happy to see at least mentioned.

What is Software Development Life Cycle?

The Software Development Life Cycle is a step-by-step process involved in the development of a
software product. It is also denoted as Software Development process in certain parts of the
world. The whole process is generally classified into a set of steps and a specific operation will
be carried out in each of the steps.
Classification
The basic classification of the whole process is as follows

 Planning
 Analysis
 Design
 Development
 Implementation
 Testing
 Deployment
 Maintenance

Each of the steps of the process has its own importance and plays a significant part in the
product development. The description of each of the steps can give a better understanding.

Planning
This is the first and foremost stage in the development and one of the most important stages.
The basic motive is to plan the total project and to estimate the merits and demerits of the
project. The Planning phase includes the definition of the intended system, development of the
project plan, and Parallel management of the plan throughout the proceedings of the
development.

A good and matured plan can create a very good initiative and can positively affect the
complete project.

Analysis
The main aim of the analysis phase is to perform statistics and requirements gathering. Based
on the analysis of the project and due to the influence of the results of the planning phase, the
requirements for the project are decided and gathered.
Once the requirements for the project are gathered, they are prioritized and made ready for
further use. The decisions taken in the analysis phase are out and out due to the requirements
analysis. Proceedings after the current phase are defined.

Design
Once the analysis is over, the design phase begins. The aim is to create the architecture of the
total system. This is one of the important stages of the process and serves to be a benchmark
stage since the errors performed until this stage and during this stage can be cleared here.

Most of the developers have the habit of developing a prototype of the entire software and
represent the software as a miniature model. The flaws, both technical and design, can be
found and removed and the entire process can be redesigned.

Development and Implementation

The development and implementation phase is the most important phase since it is the phase
where the main part of the project is done. The basic works include the design of the basic
technical architecture and the maintenance of the database records and programs related to
the development process.

One of the main scenarios is the implementation of the prototype model into a full-fledged
working environment, which is the final product or software.

Testing
The testing phase is one of the final stages of the development process and this is the phase
where the final adjustments are made before presenting the completely developed software to
the end-user.

In general, the testers encounter the problem of removing the logical errors and bugs. The test
conditions which are decided in the analysis phase are applied to the system and if the output
obtained is equal to the intended output, it means that the software is ready to be provided to
the user.

Maintenance
The toughest job is encountered in the maintenance phase which normally accounts for the
highest amount of money. The maintenance team is decided such that they monitor on the
change in organization of the software and report to the developers, in case a need arises.
The information desk is also provided with in this phase. This serves to maintain the
relationship between the user and the creator.

A software development process is a structure imposed on the development of a software

product. Similar terms include software life cycle and software process. There are
several models for such processes, each describing approaches to a variety of tasks or
activities that take place during the process. Some people consider a lifecycle model a more
general term and a software development process a more specific term. For example, there are
many specific software development processes that 'fit' the spiral lifecycle model.

Contents

 [hide]

1 Overview
2 Software development activities
o 2.1 Planning

o 2.2 Implementation, testing and

documenting
o 2.3 Deployment and maintenance

3 Software Development Models

o 3.1 Waterfall Model

o 3.2 Spiral Model

o 3.3 Iterative and Incremental

 Development
o 3.4 Agile Development

4 Process Improvement Models

5 Formal methods
6 See also
7 References
8 External links
[edit]Overview

The large and growing body of software development organizations implement process

methodologies. Many of them are in the defense industry, which in the U.S. requires a rating
based on 'process models' to obtain contracts.

The international standard for describing the method of selecting, implementing and
monitoring the life cycle for software is ISO 12207.

A decades-long goal has been to find repeatable, predictable processes that improve
productivity and quality. Some try to systematize or formalize the seemingly unruly task of
writing software. Others apply project management techniques to writing software. Without
project management, software projects can easily be delivered late or over budget. With large
numbers of software projects not meeting their expectations in terms of functionality, cost, or
delivery schedule, effective project management appears to be lacking.

Organizations may create a Software Engineering Process Group (SEPG), which is the focal point
for process improvement. Composed of line practitioners who have varied skills, the group is at
the center of the collaborative effort of everyone in the organization who is involved with
software engineering process improvement.

[edit]Software development activities

The activities of the software development process represented in the waterfall model. There
are several other models to represent this process.

Planning

The important task in creating a software product is extracting

the requirements or requirements analysis. Customers typically have an abstract idea of what
they want as an end result, but not what software should do. Incomplete, ambiguous, or even
contradictory requirements are recognized by skilled and experienced software engineers at
this point. Frequently demonstrating live code may help reduce the risk that the requirements
are incorrect.

Once the general requirements are gathered from the client, an analysis of the scope of the
development should be determined and clearly stated. This is often called a scope document.

Certain functionality may be out of scope of the project as a function of cost or as a result of
unclear requirements at the start of development. If the development is done externally, this
document can be considered a legal document so that if there are ever disputes, any ambiguity
of what was promised to the client can be clarified.

Implementation, testing and documenting

Implementation is the part of the process where software engineers actually program the code

for the project.
Software testing is an integral and important part of the software development process. This
part of the process ensures that defects are recognized as early as possible.

Documenting the internal design of software for the purpose of future maintenance and
enhancement is done throughout development. This may also include the writing of an API, be
it external or internal. It is very important to document everything in the project.

Deployment and maintenance

Deployment starts after the code is appropriately tested, is approved for release and sold or

otherwise distributed into a production environment.

Software Training and Support is important and a lot of developers fail to realize that. It would
not matter how much time and planning a development team puts into creating software if
nobody in an organization ends up using it. People are often resistant to change and avoid
venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to
have training classes for new clients of your software.

Maintaining and enhancing software to cope with newly discovered problems or new

requirements can take far more time than the initial development of the software. It may be
necessary to add code that does not fit the original design to correct an unforeseen problem or
it may be that a customer is requesting more functionality and code can be added to
accommodate their requests. If the labor cost of the maintenance phase exceeds 25% of the
prior-phases' labor cost, then it is likely that the overall quality of at least one prior phase is
poor.[citation needed] In that case, management should consider the option of rebuilding the system
(or portions) before maintenance cost is out of control.

Bug Tracking System tools are often deployed at this stage of the process to allow development
teams to interface with customer/field teams testing the software to identify any real or
perceived issues. These software tools, both open source and commercially licensed, provide a
customizable process to acquire, review, acknowledge, and respond to reported issues.
(software maintenance)
Waterfall Model Diagram
Since the time it was first published by Winston W. Royce in 1970, the waterfall model has been
used widely in the field of software development. Here, in this article, we will take a look at the
waterfall model diagram and try to understand how software development takes place, while
following this model...

Because of its various advantages, the waterfall model diagram has been in use in the field of
software development for ages. No doubt there are certain disadvantages in this system too.
However, we can understand the advantages and disadvantages of the system better in
getting the waterfall model explained by taking a brief look at the waterfall diagram. 
Waterfall Model Diagram
Waterfall Model Diagram - Explained

Let us now take a look at the different phases of the waterfall model diagram. One important
aspect that is worth mentioning before we start off with the waterfall model life cycle is that
the waterfall model is designed such that, until the preceding phase is complete, you cannot
move over to the next phase of development.
Requirement
Unless you know what you want to design, you cannot proceed with the project. Not only big
projects, but even a small code of adding two integer numbers also needs to be written with
the output in mind. Here, in this stage, the requirements which the software is going to satisfy
is specified. All requirements are presented to the team of programmers. If this phase is
completed successfully, it ensures a smooth working of the remaining waterfall model phases,
as the programmer is not burdened to make changes at later stages because of changing
requirements.

Analysis
As per the requirements, the software and hardware for the proper completion of the project is
analyzed in this phase. Right from the point of which computer language should be used for the
designing of the software, to the database system that can be used for the smooth functioning
of the software is decided at this stage.

Design
The algorithm or flowchart of the program or the software code to be written in the next stage
is created now. It is a very important stage, which relies on the previous two stages for its
proper implementation and the proper execution of the same ensures a smooth working of the
next stage. If during the design phase it can be made out that there are some more
requirements for designing the code, it is added up to the list in the analysis phase and the
design phase is carried out according to the new set of resources.

Coding
Based on the algorithm or flowchart designed, the actual coding of the software is carried out.
This is the stage where the entire idea of the software of program to be designed is
materialized. A proper execution of the previous stages ensures a smooth implementation of
this stage.
Testing
With the coding complete, the testing department now comes into scene. It checks out if there
are any flaws in the designed software and if the software has been designed as per the
specifications. A proper execution of this stage ensures that the client for which the software
has been designed, will be satisfied with the work. If there are any flaws, the problem is
reverted back to the design phase. In the design phase, the changes are implemented and then
its succeeding stages, coding and testing are again carried out. Read more on software testing.

Acceptance
This is the last stage of the software development, using the waterfall model. A proper
execution of all the preceding stages ensures a software as per the requirements and most
importantly, it ensures a satisfied client. However, at this stage you may need to provide the
client with some support regarding the software you have developed. If the client demands
some further enhancements to be made to the existing software, then the process again needs
to be started, right from the first phase, i.e., requirements.

Read more on

 Waterfall - Software Development Model

 Waterfall Model - Advantages and Disadvantages

The waterfall model in software engineering continues to remain one of the most commonly

used methodologies. No doubt, new systems have been used, but the widespread use of
waterfall model is still the reason why it is studied in various software management subjects.
With the waterfall model diagram in hand, you will not have much difficulty in understanding
the process of software development using this method. This is not only one of the simple
software process models for application development, but it is also known for its ease of
implementation in the field of software development.
Software development, like any other business process, has certain targeted goals which must
be achieved in a fixed frame of time. There are various strategies for achieving these software
development goals. Two of the most popular software development models are the 'Waterfall
Model' and the 'Agile Model'. This article makes a waterfall model vs agile model comparison,
that will serve to point out the differences in the two different methods of software
development. 

Waterfall Model Vs Agile Model: History

Before we get into comparing waterfall model vs agile model, let us have a look at the
developmental history of these two models. Waterfall model in software engineering got
formally introduced as an idea, through a paper published by Winston Royce in 1970. However,
ironically, he himself had introduced it as a flawed method of software development,
vulnerable due to its many shortcomings. Every methodology has takers and waterfall model
has been successfully implemented by many software companies. The waterfall model
philosophy was inherited from the hardware manufacture strategies and construction
strategies that were in practice during the 1970s. That is why it has a very structured approach
to software development. Waterfall model explained later will clarify what I am trying to say
here.

On the other hand, the agile model of software development evolved in the 1990s when
developers decided to break away from traditional structured, segmented, bureaucratic
approaches to software development and move towards more flexible development styles. The
'Agile' or 'Light Weight' methods as they were called, were formally defined in a research paper
by Edmonds in 1974. Some of the most prominent and popular agile methods of software
development, that subsequently evolved are 'Scrum' in 1995, 'Crystal Clear', 'Extreme
Programming' in 1996, 'Adaptive Software Development', 'Dynamic Systems Development
Method' in 1995 and 'Feature Driven Development'. In 2001, a group of pioneers in agile
software development came together and declared the 'Agile Manifesto', which is a set of
canonical rules of sorts for, agile software development methods. 
Waterfall Model Vs Agile Model: Conceptual Difference
After the short interlude of history, let us start the actual waterfall model vs agile model
comparison, by starting with the major conceptual differences in the two approaches. Then we
will compare the difference in software development life cycle, involved in both approaches.
Let us discuss the waterfall model advantages and disadvantages after delving into the main
concept. Waterfall model of software development, as the name itself signifies, is a sequential
process of software development. Like in a waterfall, the water progressively falls from one
altitude to the lower, in a similar way, the production cycle progresses sequentially, from one
stage to the other (illustrated by a waterfall model diagram in textbooks). The waterfall model
phases of software development are as follows: requirement specification, conception, analysis,
design, coding, testing & debugging, installation and finally maintenance. In this sequentially
structured approach, the development team goes ahead to the next stage of development only
after the first is fully accomplished. Software development companies adopting this model
spend considerable amount of time in each stage of development, till all doubts are cleared and
all requirements are met. The belief that drives this kind of software development model is that
considerable time spent in initial design effort corrects bugs in advance. Once the design stage
is over, it is implemented exactly in the coding stage, with no changes later. Often the analysis,
design and coding teams are separated and work on small parts in the whole developmental
process. Emphasis is placed on documentation of every stage of software development. 

Now let us have a look at the agile software development method. Compared to the 'set-in-
stone' approach of waterfall development models, the agile models, as the title suggest,
focuses on 'agility' and 'adaptability' in development. Instead of one time consuming and rigid
development schedule, agile models involve multiple iterative development schedules that
seek to improve the output with every iteration. Each iteration goes through the all the steps of
design, coding and testing. The design is not set in stone and is kept open to last minute
changes due to iterative implementation. The team structure is cross functional, closely knit
and self-organizing. The design idea is never totally frozen or set in stone but is allowed to
evolve as new ideas come in with each release. Less importance is given to documentation than
speed of delivering a working program.

Waterfall Model Vs Agile Model: Efficiency

In the ongoing comparison of waterfall model vs agile model, let us see how these two
ideologies compare with respect to development efficiency. Efficiency is decided by the quality
of ultimate software product, the number of bugs and the development time consumed.
Through my own research into the working of both these models, I found the agile models to
be more efficient than the waterfall model, due to its adaptability to the real world. The 'One
Phase' and 'Rigid' development cycle makes it difficult to make last minute changes in
requirements or design. While the agile methods, due to their iterative and adaptable nature,
can incorporate changes and release a product in lesser time. Of course, agile models are not
perfect either, but they are certainly more widely applicable than the waterfall model.

Waterfall Model Vs Agile Model: Suitability

The water fall model is suited for development of programs that are already stable. That is,
their design does not need a major makeover. In situations where the designers of a software
can accurately predict the flaws that may arise can be developed through a waterfall model.
Despite all its flaws, a waterfall model design is easier to manage and the development costs
can be ascertained before hand.

Agile models are applicable in every area of software development. It depends a lot more on
the team effort of above average programmers, than relying on a few expert programmers. It is
best suited for web based applications where its iterative nature helps in incorporating and
correcting the various bugs that arise over time.

So, this was a waterfall model vs agile model comparison, that tried to compare the basic
differences between the two. What is ideally needed is a model which combines the
accountability and predictability of a waterfall model with the agility and adaptability of the
agile model. That is, an effective balance between the two ideologies can create a more
efficient software development model.

Waterfall Model Life Cycle

One of the oldest model used in software development is the waterfall software development
life cycle model. The origin of this model is in the manufacturing and construction industry.
Since formal software development methods did not exist at that time, this hardware oriented
model was adapted for software development as well. Scroll down to know more about
waterfall model life cycle.

Enlarge Image

Software Development Model - Waterfall Model Life Cycle

The waterfall model in software engineering was originally designed in 1970 by Winston W.

Royce. However, the model was not named as ‘waterfall’ model. In this model there is
sequential progression from one phase to another. To elaborate this further, after the first
phase is completed, it is considered as a stepping stone to the next phase. The phases in
the waterfall - software development model are requirement analysis and project planning,
system design and specification, coding and verification, system integration and testing and not
to forget deployment and maintenance phase. Here is the the waterfall model explained.

Requirement Analysis and Project Planning

In this first stage of waterfall model diagram, there is a meeting with the customer, to
understand the requirements. The first stage, this is said to be the most crucial stage, as any
miscommunication and misinterpretation at this stage may give rise to the software, that is
been developed. When the requirements are been noted, it is important to make sure the
requirements are detailed and accurate and there is no place for any ambiguity. Understanding
the requirements and expectations of the customer properly will ensure, that the end product
meets the specification.

System Design
The requirements, that are gathered in the previous phase are broken down into logical units,
so that the software process becomes easy for implementation. This is the stage, when the
software requirements along with the hardware requirements for every unit are identified.
Then the designs are made accordingly. The interrelation between the various units of the
software are identified and the connections are made, using algorithms and diagrams. To sum it
up, this is the phase, where the fundamental work for actual programming and implementation
is done.

System Implementation
In this phase the actual development of the software takes place. This phase is also known as
coding and verification phase. Based on the algorithms written in the previous phase, software
program is written. For every module, software code is written and tested, to check if the
correct output is received.

System Integration and Testing

Now all the modules are integrated, after which the software is tested for correct output. All
the bugs, that are made, due to integration are removed. Then software testing is carried out
again. They are normally a series of tests, which are run to check the performance of the
software, and also to find if any new bugs were introduced into the system, after the previous
bugs were fixed. If any more errors do exist, the bugs are fixed only to be retested.
The waterfall model in testing is followed, to make the software bug free, as far as possible.

System Deployment and Maintenance

This makes for the final phase of the waterfall model, where the software is deployed at the
clients side, after it has undergone thorough testing. After the deployment of the software,
routine maintenance work is carried out. Once the software has been deployed, in case the
customer asks for any changes or enhancements, then the entire process is restarted. You may
want to read on waterfall model vs agile.

There are various waterfall model advantages and disadvantages. The biggest advantage of this
model is that, the phases are completed one at a time. However, the biggest disadvantage is
that it is laborious, when any changes are to be made to the system. To sum up waterfall model
life cycle in short, this model requires, that one moves from one phase to another, only after
the preceding phase is completed satisfactorily. At the same time, it should not be forgotten,
that various waterfall models may include slight or major variations in the process.

Waterfall Model Phases

Waterfall model is one of the most preferred and widely implemented software design
principles. The ease of implementation and the systematic approach at various phases in
waterfall model make it the most sought after model among software professionals. Read on to
know more on waterfall model phases.
What is the Waterfall Model

Waterfall model in software engineering is basically a development approach which follows a

'top down' mechanism. The development process goes through several phases to meet the
customer's specifications and requirements. One distinguishing feature of waterfall model that
sets it apart from other software development models is that, in this method there is no
simultaneous execution of two phases. The second phase begins only when the preceding
phase has been completely implemented. This approach is very simple to implement and there
is transparency at every stage. Review meetings are conducted at the end of every stage to
verify whether the development process is on track and meets the customer requirements.
Systematic documentation is done at every phase of waterfall model. More on waterfall model
vs agile.

Waterfall Model Phases

Given below are the various phases of waterfall model. Although, the phase name may differ
for every software organization, the basic implementation steps remain the same. Also
refer waterfall model diagram.

Requirement Analysis and Software Definition

This is the first phase of waterfall model which includes a meeting with the customer to
understand his requirements. This is the most crucial phase as any misinterpretation at this
stage may give rise to validation issues later. The software definition must be detailed and
accurate with no ambiguities. It is very important to understand the customer requirements
and expectations so that the end product meets his specifications. 

System Design
The customer requirements are broken down into logical modules for the ease of
implementation. Hardware and software requirements for every module are identified and
designed accordingly. Also the inter relation between the various logical modules is established
at this stage. Algorithms and diagrams defining the scope and objective of each logical model
are developed. In short, this phase lays a fundamental for actual programming and
implementation.

System Implementation
This is the software process in which actual coding takes place. A software program is written
based upon the algorithm designed in the system design phase. A piece of code is written for
every module and checked for the output.

System Testing
The programmatically implemented software module is tested for the correct output. Bugs,
errors are removed at this stage. In the process ofsoftware testing, a series of tests and test
cases are performed to check the module for bugs, faults and other errors. Erroneous codes are
rewritten and tested again until desired output is achieved. More on waterfall model in testing.

System Deployment and Maintenance

This is the final phase of the waterfall model, in which the completed software product is
handed over to the client after alpha, beta testing. After the software has been deployed on the
client site, it is the duty of the software development team to undertake routine maintenance
activities by visiting the client site. If the customer suggests changes or enhancements the
software process has to be followed all over again right from the first phase i.e requirement
analysis. This is the biggest shortcoming of the waterfall model.
Thus, waterfall model is easy to implement and more often than not produces desired results.
The inter-dependence of waterfall model phases may lead to developmental issues, if a
systematic approach is not followed at each step. However, in spite of these shortcomings,
waterfall model is adopted all across the world.
Waterfall Model Advantages and Disadvantages
Anyone working in the field of software development will of course be aware of the famous
waterfall model. It is nothing but the life cycle through which a project goes. Here, in this
article, we will try to be aware of the waterfall model advantages and disadvantages...

The original waterfall model, published by Winston W. Royce in 1970, was in fact not identified
by the very name with which we know it today. Royce, in fact, presented the model as a flawed
and non-working model. But because of the various advantages that this approach towards
software designing and implementation presented, it soon became very popular in the world of
software development. However, before going into the waterfall model advantages and
disadvantages, here is the waterfall model explained briefly. Read more on waterfall - software
development model.

Waterfall Model - Software Development Model

The most important aspect of the waterfall model is that none of the stages can be started off
with before the preceding stage is complete. The software life cycle has to follow the sequence.
The original waterfall model designed by Royce consisted of the following seven stages:

 Specification of Requirements
 Design
 Construction
 Integration
 Testing and Debugging
 Installation
 Maintenance

However, various modifications were brought over to this waterfall model as and when
required. Here, in this article, we will try to understand a simple waterfall model, broken into
six stages. There is a seventh stage which is same as that of the first stage, requirements, but it
follows the last stage and is referred to as updated maintenance. Let us try to understand each
of these stages one by one. 

Stage 1: Requirement Phase

Whether you design a small program to add two numbers or you are into developing a software
system for the automation of an entire airline company, this is the first stage which can never
be overridden. Unless you know what you are going to design, you cannot approach the
problem. Here, the specifications of the output or the final product is studied and marked. If
the software that is going to be designed should not contain certain features, for reasons like
security, then it is also mentioned in this stage. 

Stage 2: Specification Phase

With all the requirements and constraints in hand, a final view of how the product should
exactly be, is decided. The exact way in which the software should function is mentioned in this
stage.

Stage 3: Design Phase

Well, here the actual work begins. Every type of resource which will be required for the smooth
designing of the software is mentioned here in this phase. What type of database will be
required, what type of data should be supported, etc. are some of the important aspects that
are decided in this phase. The algorithm of the process in which the software needs to be
designed is made in this phase. This algorithm forms the backbone for the actual coding part in
the next phase.

Stage 4: Implementation and Testing Phase

Now starts the coding part. Here, the software is designed as per the algorithm. Hence it
becomes very important that the algorithm should be properly designed. The software
designed as per the algorithm needs to go through constant software testing and error
correction processes to find out if there are any flaw or errors. The output of this stage should
be a well designed software which is at par with the algorithm designed. 

Stage 5: Integration and Testing Phase

Here the various codes designed by different programmers are integrated together and is
tested if the software works as per the specifications provided. The setup of the final software
which needs to be installed at the clients system is also designed and tested so that the client
does not face any problem during the installation of the software. The product is then handed
over to the client.

Stage 6: Maintenance Phase

The work of software development does not end with the handing of the software to the client.
The software designers may have to constantly provide support to the client to resolve any of
the issues which may arise. There may be some flaws which get detected during the actual
implementation of the project. During the maintenance phase, support and debugging is
provided for all such problems.

Stage 7: New Requirements Phase

Changing times may require that the product requirements be changed. The client company
may be expanding into other fields and it may want new features to be added over to the
existing software. Hence, it is very important that the updated requirements be taken from the
client. This requires the entire product life cycle to start all over again.

Now, I hope that the small explanation given above must have helped you in understanding the
waterfall model. With this knowledge in hand, let us try to understand the advantages and
disadvantages of waterfall model. Read more on waterfall model in software engineering.

Waterfall Model Advantages and Disadvantages

Let us now try to answer the basic question, what are the advantages and disadvantages of
waterfall model?

Advantages of Waterfall Model

The waterfall model is the oldest and most widely used model in the field of software
development. There are certain advantages of the waterfall model, which causes it to be the
most widely used model as yet. Some of them can be listed as under.

 Needless to mention, it is a linear model and of course, linear models are the most
simple to be implemented.
 The amount of resources required to implement this model is very minimal.
 One great advantage of the waterfall model is that documentation is produced at every
stage of the waterfall model development. This makes the understanding of the product
designing procedure simpler.
 After every major stage of software coding, testing is done to check the correct running
of the code.

Disadvantages of Waterfall Model

The question that must be bothering you now is that with so many advantages at hand, what
could be the possible disadvantages of the waterfall model. Well, there are some disadvantages
of this widely accepted model too. Let us look at a few of them.

 Ironically, the biggest disadvantage of the waterfall model is one of its greatest
advantage. You cannot go back, if the design phase has gone wrong, things can get very
complicated in the implementation phase.
 Many a times, it happens that the client is not very clear of what he exactly wants from
the software. Any changes that he mentions in between may cause a lot of confusion.
 Small changes or errors that arise in the completed software may cause a lot of
problem.
  The greatest disadvantage of the waterfall model is that until the final stage of the
development cycle is complete, a working model of the software does not lie in the
hands of the client. Thus, he is hardly in a position to mention if what has been designed
is exactly what he had asked for

The waterfall model, as already mentioned, is of course the most widely used model. There are
various versions of the same, which allow some waterfall model phases to overlap or feedback
to be taken after each phase, which make designing the software a lot more simpler. So this, in
short, was all about waterfall model advantages and disadvantages. In spite of the
disadvantages, the many advantages of this model ensure that it remains one of the most
popular models used in the field of software development.

Waterfall model

The waterfall model is a sequential software development process, in which progress is seen as

flowing steadily downwards (like a waterfall) through the phases of Conception,
Initiation, Analysis, Design, Construction, Testing andMaintenance.

The unmodified "waterfall model". Progress flows from the top to the bottom, like a waterfall.
 Software development process

Activities and steps

Requirements · Specification
Architecture · Design
Implementation · Testing
Deployment · Maintenance

Methodologies

Agile · Cleanroom ·
Iterative · RAD  · RUP  · Spiral
Waterfall · Lean
V-Model  · TDD

Supporting disciplines

Configuration management
Documentation
Quality assurance (SQA)
Project management
User experience design

Tools

Compiler  · Debugger  · Profiler
GUI designer

Integrated development environment

v • d • e
The waterfall development model has its origins in
the manufacturing and construction industries; highly structured physical environments in
which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software
development methodologies existed at the time, this hardware-oriented model was simply
adapted for software development.

The first formal description of the waterfall model is often cited to be an article published in
1970 byWinston W. Royce,[1] although Royce did not use the term "waterfall" in this article.
Royce was presenting this model as an example of a flawed, non-working model (Royce 1970).
This is in fact the way the term has generally been used in writing about software development
—as a way to criticize a commonly used software practice.[2]

Contents

 [hide]

1 Model
2 Supporting
arguments
3 Criticism
4 Modified models
5 See also
6 References
7 Further reading
8 External links
[edit]Model

In Royce's original waterfall model, the following phases are followed in order:

1. Requirements specification

2. Design

3. Construction (AKA implementation or coding)

 4. Integration
5. Testing and debugging (AKA Validation)

6. Installation

7. Maintenance

To follow the waterfall model, one proceeds from one phase to the next in a sequential
manner. For example, one first completes requirements specification, which after sign-off are
considered "set in stone." When the requirements are fully completed, one proceeds to design.
The software in question is designed and a blueprint is drawn for implementers (coders) to
follow — this design should be a plan for implementing the requirements given. When the
design is fully completed, an implementation of that design is made by coders. Towards the
later stages of this implementation phase, separate software components produced are
combined to introduce new functionality and reduced risk through the removal of errors.

Thus the waterfall model maintains that one should move to a phase only when its preceding
phase is completed and perfected. However, there are various modified waterfall
models (including Royce's final model) that may include slight or major variations upon this
process.

[edit]Supporting arguments

Time spent early in the software production cycle can lead to greater economy at later stages. It
has been shown that a bug found in the early stages (such as requirements specification or
design) is cheaper in terms of money, effort and time, to fix than the same bug found later on in
the process. ([McConnell 1996], p. 72, estimates that "a requirements defect that is left
undetected until construction or maintenance will cost 50 to 200 times as much to fix as it
would have cost to fix at requirements time.") To take an extreme example, if a program design
turns out to be impossible to implement, it is easier to fix the design at the design stage than to
realize months later, when program components are being integrated, that all the work done so
far has to be scrapped because of a broken design.

This is the central idea behind Big Design Up Front (BDUF) and the waterfall model - time spent
early on making sure that requirements and design are absolutely correct will save you much
time and effort later. Thus, the thinking of those who follow the waterfall process goes, one
should make sure that each phase is 100% complete and absolutely correct before proceeding
to the next phase of program creation. Program requirements should be set in stone before
design is started (otherwise work put into a design based on incorrect requirements is wasted);
the program's design should be perfect before people begin work on implementing the design
(otherwise they are implementing the wrong design and their work is wasted), etc.

A further argument for the waterfall model is that it places emphasis on documentation (such
as requirements documents and design documents) as well as source code. In less designed and
documented methodologies, should team members leave, much knowledge is lost and may be
difficult for a project to recover from. Should a fully working design document be present (as is
the intent of Big Design Up Front and the waterfall model) new team members or even entirely
new teams should be able to familiarize themselves by reading the documents.

As well as the above, some prefer the waterfall model for its simple approach and argue that it
is more disciplined. Rather than what the waterfall adherent sees as chaos, the waterfall model
provides a structured approach; the model itself progresses linearly through discrete, easily
understandable and explainable phases and thus is easy to understand; it also provides easily
markable milestones in the development process. It is perhaps for this reason that the waterfall
model is used as a beginning example of a development model in many software engineering
texts and courses.

It is argued that the waterfall model and Big Design up Front in general can be suited to
software projects which are stable (especially those projects with unchanging requirements,
such as with shrink wrap software) and where it is possible and likely that designers will be able
to fully predict problem areas of the system and produce a correct design before
implementation is started. The waterfall model also requires that implementers follow the well
made, complete design accurately, ensuring that the integration of the system proceeds
smoothly.

[edit]Criticism
The waterfall model is argued by many to be a bad idea in practice. This is mainly because of
their belief that it is impossible for any non-trivial project to get one phase of a software
product's lifecycle perfected, before moving on to the next phases and learning from them.

For example, clients may not be aware of exactly what requirements they need before
reviewing a working prototype and commenting on it; they may change their requirements
constantly. Designers and programmers may have little control over this. If clients change their
requirements after the design is finalized, the design must be modified to accommodate the
new requirements. This effectively means invalidating a good deal of working hours, which
means increased cost, especially if a large amount of the project's resources has already been
invested in Big Design Up Front.

Designers may not be aware of future implementation difficulties when writing a design for an
unimplemented software product. That is, it may become clear in the implementation phase
that a particular area of program functionality is extraordinarily difficult to implement. If this is
the case, it is better to revise the design than to persist in using a design that was made based
on faulty predictions and that does not account for the newly discovered problem areas.

Even without such changing of the specification during implementation, there is the option
either to start a new project from scratch, "on a green field", or to continue some already
existing, "a brown field" (from construction again). The waterfall methodology can be used for
continuous enhancement, even for existing software, originally from another team. As well as in
the case when the system analyst fails to capture the customer requirements correctly, the
resulting impacts on the following phases (mainly the coding) still can be tamed by this
methodology, in practice: A challenging job for a QA team.

Steve McConnell in Code Complete (a book which criticizes the widespread use of the waterfall
model) refers to design as a "wicked problem" — a problem whose requirements and
limitations cannot be entirely known before completion. The implication of this is that it is
impossible to perfect one phase of software development, thus it is impossible if using the
waterfall model to move on to the next phase.

David Parnas, in "A Rational Design Process: How and Why to Fake It", writes: [3]
“Many of the [system's] details only become known to us as we progress in the [system's]
implementation. Some of the things that we learn invalidate our design and we must
backtrack.”

Expanding the concept above, the project stakeholders (non-IT personnel) may not be fully
aware of the capabilities of the technology being implemented. This can lead to their
expectations, and requirements, being defined by what they "think is possible". Which may not
take advantage of the full potential of what the new technology can deliver, or simply be trying
to replicate the existing application or process with the new technology. This can result in
substantial changes to the implementation requirements once the stakeholders become more
aware of the functionality available from the new technology. An example is where an
organisation is migrating from a paper based process to an electronic process. While the key
deliverables of the paper process should be maintained, the benefits of real-time data input
validation, traceability, and automated decision point routing may not be anticipated at the
early planning stages of the project.

The idea behind the waterfall model may be "measure twice; cut once", and those opposed to
the waterfall model argue that this idea tends to fall apart when the problem being measured is
constantly changing due to requirement modifications and new realizations about the problem
itself. A potential solution is for an experienced developer to spend time up front
on refactoring to consolidate the software, and to prepare it for a possible update, no matter if
such is planned already. Another approach is to use a design
targeting modularity with interfaces, to increase the flexibility of the software with respect to
the design.

Modified models

In response to the perceived problems with the pure waterfall model, many modified waterfall
models have been introduced. These models may address some or all of the criticisms of the
pure waterfall model.[citation needed] Many different models are covered by Steve McConnell in the
"lifecycle planning" chapter of his book Rapid Development: Taming Wild Software Schedules.
While all software development models will bear some similarity to the waterfall model, as all
software development models will incorporate at least some phases similar to those used
within the waterfall model, this section will deal with those closest to the waterfall model. For
models which apply further differences to the waterfall model, or for radically different models
seek general information on the software development process.

The Waterfall Model Explained

  

There are various software development approaches defined and designed which are
used/employed during development process of software, these approaches are also referred as
"Software Development Process Models". Each process model follows a particular life cycle in
order to ensure success in process of software development.

One such approach/process used in Software Development is "The Waterfall Model". Waterfall
approach was first Process Model to be introduced and followed widely in Software Engineering
to ensure success of the project. In "The Waterfall" approach, the whole process of software
development is divided into separate process phases. The phases in Waterfall model are:
Requirement Specifications phase, Software Design, Implementation and Testing &
Maintenance. All these phases are cascaded to each other so that second phase is started as
and when defined set of goals are achieved for first phase and it is signed off, so the name
"Waterfall Model". All the methods and processes undertaken in Waterfall Model are more
visible.

The stages of "The Waterfall Model" are:

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, these 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 which serves the purpose of guideline
for the next phase of the model.

System & Software Design: Before a starting for actual coding, it is highly important to
understand what we are going to create and what it should look like? 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: On 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: As specified above, the system is first divided in units which are
developed and tested for their functionalities. 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.
The Waterfall Model: IT Project Management Solutions
The waterfall model is an information technology system development type model initially
published in 1970 by Winston W. Royce. Prior to this time, there had been a number of
significant malfunctions of IT system type projects; this is due to a lack of proper parameters,
procedural approaches and procedural controls of IT project management tasks.

The purpose of this model is to introduce modus operandi into the system design process; as a
skeleton for system development it advances consecutively through a succession of phases,
preliminarily with system feasibility analysis and concluding up to system release and
maintenance.

The name "waterfall" portrays system progress flows from the top to the bottom, like water
falling down steps in a waterfall panorama, one phase at a time towards the bottom in a
cascading effect.

In the present day, the waterfall model is considered classical and conservative system type
model; however, it is indispensable for a fundamental understanding of system development in
IT project systems management.

In the waterfall model, system design is broken down into a number of linear and sequential
stages, in which system evolution is seen as flowing progressively downwards, through the
phases. The waterfall model has distinct goals for each phase of development. In this
development method it is not allowed to journey onto the succeeding phase until the operation
of the preceding phase has been accomplished.

The output from each phase formed the input to the next phase; therefore, each phase had to
be accomplished in turn to maintain the linkage between the inputs and outputs.
A detail waterfall model can be represented as in the following system development life
cycle:

Phase I [SYSTEM FEASIBILITY / Justification]

{-----------------------||----------------------------}

Phase II [SYSTEM PLAN / Justification]

{-----------------------||----------------------------}

Phase III [OUTLINE DESIGN / Confirmation]

{-----------------------||----------------------------}

Phase IV [DETAIL DESIGN / Confirmation]

{-----------------------||----------------------------}

Phase V [CODING/ Unit Test]

{-----------------------||----------------------------}

Phase VI [INTEGRATION / Product Confirmation]

{-----------------------||----------------------------}

Phase VII [IMPLEMENTATION / System Test]

{-----------------------||----------------------------}

Phase VIII [OPERATION AND MAINTENANCE / Re Justification]

Here, a system flows through eight different sequential phases, and each phase is segmented
into two divisions: the first division covers the task to be carried out in that phase, and second
part is the justification or confirmation procedure on that specific work. Within this model, the
terms confirmation and justification have specific meanings:

Justification means validation or inspecting whether the result is fit for the operational mission,
that is, checking whether the correct product is being build or not. Is the product correct? 

Confirmation means verification or inspecting the link between a result and the specification
for the result. In other words, a check that the result is being constructed in the correct
manner. Is the system structure correct?

The process of building the systems product flows phase to phase with very little interaction in-
between two stages, apart from transfer of outputs and inputs between them. The phase
progression sequences enforce discipline as every phase has a specific start and end spot, and
progress can be categorically acknowledged.

Within more modern system design projects, the water model is in use to mean any
chronological representation that is divided into successive phases and which pursue the
common structure of the original model. Here, the naming of the phases is not vital, and
suitable names can be used for the particular project being undertaken.

The waterfall model retains that system and should move to the next phase only when it's
previous phase is completed and perfected. Thus in the waterfall model each phase in a system
development life cycle is seen as part of an irreversible succession of events. One phase cannot
commence until the previous step has ended. Once a step has been started, there is no reverse
back to a prior step.

For instance, "detail design" cannot start until "outline design" has been finished, and program
"coding" cannot begin until "detail design" has been completed.

Phases of development in the waterfall model are thus discrete, and there is no leaping back
and forth or overlap between different phases.

Appreciations and Criticism of the waterfall model: 

Appreciations:

The waterfall model provides a clear and easy to follow sequence of activities; it is simple and
can be understood without many complications. Furthermore, particular issues on quality
management are addressed through the Justification and Confirmation section that is being
followed in each phase of the model, and in addition to this, this model will facilitate project
management and control by the need to complete each stage before moving to the succeeding
phase.

Criticism: 

The waterfall model lacks prescribed technique of implementing management control over a
project; planning, controlling, and risk management are not enveloped within the model itself.
Moreover, forecasting the estimated time and cost are complicated for each stage. The life
cycle can take long as the original requirements may no longer be valid, with little possibility for
prototyping.
The waterfall model of system development works best when any reworking of products is kept
to a minimum and the products remain unchanged. It still remains useful for steady and non-
volatile types of projects, and if properly implemented, generates significant cost and
timesaving. If the system is likely to go through significant changes and if the system
requirements are unpredictable then different approaches are recommended, one such
alternate approach is popularly know as the spiral model.
Spiral Model - A New Approach Towards Software Development
  

n last article we discussed about "Waterfall Model", which is one of the oldest and most simple
model designed and followed during software development process. But "Waterfall Model" has
its own disadvantages such as there is no fair division of phases in the life cycle, not all the
errors/problems related to a phase are resolved during the same phase, instead all those
problems related to one phase are carried out in the next phase and are needed to be resolved
in the next phase, this takes much of time of the next phase to solve them. The risk factor is the
most important part, which affects the success rate of the software developed by following
"The Waterfall Model".
 In order to overcome the cons of "The Waterfall Model", it was necessary to develop a new
Software Development Model, which could help in ensuring the success of software project.
One such model was developed which incorporated the common methodologies followed in
"The Waterfall Model", but it also eliminated almost every possible/known risk factors from it.
This model is referred as "The Spiral Model" or "Boehm’s Model".

There are four phases in the "Spiral Model" which are: Planning, Evaluation, Risk Analysis and
Engineering. These four phases are iteratively followed one after other in order to eliminate all
the problems, which were faced in "The Waterfall Model". Iterating the phases helps in
understating the problems associated with a phase and dealing with those problems when the
same phase is repeated next time, planning and developing strategies to be followed while
iterating through the phases. The phases in "Spiral Model" are:

Plan: In this phase, the objectives, alternatives and constraints of the project are determined
and are documented. The objectives and other specifications are fixed in order to decide which
strategies/approaches to follow during the project life cycle.

Risk Analysis: This phase is the most important part of "Spiral Model". In this phase all possible
(and available) alternatives, which can help in developing a cost effective project are analyzed
and strategies are decided to use them. This phase has been added specially in order to identify
and resolve all the possible risks in the project development. If risks indicate any kind of
uncertainty in requirements, prototyping may be used to proceed with the available data and
find out possible solution in order to deal with the potential changes in the requirements.

Engineering: In this phase, the actual development of the project is carried out. The output of
this phase is passed through all the phases iteratively in order to obtain improvements in the
same.
Customer Evaluation: In this phase, developed product is passed on to the customer in order to
receive customer’s comments and suggestions which can help in identifying and resolving
potential problems/errors in the software developed. This phase is very much similar to
TESTING phase.

The process progresses in spiral sense to indicate iterative path followed, progressively more
complete software is built as we go on iterating through all four phases. The first iteration in
this model is considered to be most important, as in the first iteration almost all possible risk
factors, constraints, requirements are identified and in the next iterations all known strategies
are used to bring up a complete software system. The radical dimensions indicate evolution of
the product towards a complete system.

However, as every system has its own pros and cons, "The Spiral Model" does have its pros and
cons too. As this model is developed to overcome the disadvantages of the "Waterfall Model",
to follow "Spiral Model", highly skilled people in the area of planning, risk analysis and
mitigation, development, customer relation etc. are required. This along with the fact that the
process needs to be iterated more than once demands more time and is somehow expensive
task.

The Spiral Model: IT Project Management Solutions

  

The Spiral Model is the neo approach in IT project system development and was originally
devised by Barry W. Boehm through his article published in 1985 "A Spiral Model of Software
Development and Enhancement".

This model of development unites the features of the prototyping model with an iterative
approach of system development; combining elements of design and prototyping-in-stages.
This model is an effort to combine the advantages of top-down and bottom-up concepts highly
preferential for large, exclusive, volatile, and complex projects.

The term "spiral" is used to describe the process that is followed in this model, as the
development of the system takes place, the mechanisms go back several times over to earlier
sequences, over and over again, circulating like a spiral. 
The spiral model represents the evolutionary approach of IT project system development and
carries the same activities over a number of cycles in order to elucidate system requirements
and its solutions.

Similar to the waterfall model, the spiral model has sequential cycles/stages, with each stage
having to be completed before moving on to next.

The prime difference between the waterfall model and the spiral model is that the project
system development cycle moves towards eventual completion in both the models but in the
spiral model the cycles go back several times over to earlier stages in a repetitive sequence. 

Progress Cycles, IT Project Management Solutions 

The progress cycle of this model is divided into four quadrants, and each quadrant with a
different purpose; 

Determining Objectives (I)------------Evaluating Alternatives (II)

************************************************************* 

Planning Next Phase (III)------------Planning Next Phase (IV) 

First Quadrant: the top left quadrant determines and identifies the project objectives,
alternatives, and constrains of the project. Similar to the system conception stage in the
Waterfall Model, here objectives are determined with identifying possible obstacles and
weighting alternative approaches.

Second Quadrant: the top right quadrant determines the different alternatives of the project
risk analysis, and evaluates their task with each alternative eventually resolving them. Probable
alternatives are inspected and associated risks are recognized. Resolutions of the project risks
are evaluated, and prototyping is used wherever necessary.

Third Quadrant: the bottom right quadrant develops the system and this quadrant corresponds
to the waterfall model with detailed requirements determined for the project.

Fourth Quadrant: the bottom left quadrant plans the next phase development process,
providing opportunity to analyze the results and feedback.

In each phase, it begins with a system design and terminates with the client reviewing the
progress through prototyping.

The major advantage of the spiral model over the waterfall model is the advance approach on
setting project objectives, project risk management and project planning into the overall
development cycle. Additionally, another significant advantage is, the user can be given some
of the functionality before the entire system is completed.

The spiral model addresses complexity of predetermined system performance by providing an

iterative approach to system development, repeating the same activities in order to clarify the
problem and provide an accurate classification of the requirement within the bounds of
multiple constraints.

Software Testing Methodologies

There are different types of software testing methodologies in the field of software testing and
quality assurance. In the following article, we will have a look at various software testing
techniques and methodologies that are in practice today.
Software testing is an integral part of the software development life cycle (SDLC). Effectively
and efficiently testing a piece of code is equally important, if not more, than writing it. So what
is software testing? Well, for those of you who are new to software testing and quality
assurance, here's the answer to this question.

Software testing is nothing but subjecting a piece of code to both, controlled as well as
uncontrolled operating conditions, in an attempt to observe the output and examine whether it
is in accordance with certain pre-specified conditions. Different sets of test cases and testing
strategies are prepared, all of which aim at achieving one common goal - removing all the bugs
and errors from the code and making the software error-free and capable enough of providing
accurate and optimum outputs. There are different types of software testing techniques and
methodologies. A software testing methodology is different from a software testing technique.
We will have a look at a few software testing methodologies in the later part of this article.

Software Testing Methods

There are different types of testing methods or techniques as part of the software testing
process. I have enlisted a few of them below.

 White box testing

 Black box testing
 Gray box testing
 Unit testing
 Integration testing
 Regression testing
 Usability testing
 Performance testing
 Scalability testing
 Software stress testing
  Recovery testing
 Security testing
 Conformance testing
 Smoke testing
 Compatibility testing
 System testing
 Alpha testing
 Beta testing

The above software testing methods can be implemented in two ways - manually or by
automation. Manual software testing is done by human software testers who manually i.e.
physically check, test and report errors or bugs in the product or piece of code. In case of
automated software testing, the same process is performed by a computer by means of an
automated testing software such as WinRunner, LoadRunner, Test Director, etc.

Software Testing Methodologies

These are some commonly used software testing methodologies:

 Waterfall model
 V model
 Spiral model
 RUP
 Agile model
 RAD

Let us have a look at each one of these methodologies one by one.

Waterfall Model
The waterfall model adopts a 'top down' approach regardless of whether it is being used
for software development or testing. The basic steps involved in this software testing
methodology are:

1. Requirement analysis
2. Test case design
3. Test case implementation
4. Testing, debugging and validating the code or product
5. Deployment and maintenance

In this methodology, you move on to the next step only after you have completed the present
step. There is no scope for jumping backward or forward or performing two steps
simultaneously. Also, this model follows a non-iterative approach. The main benefit of this
methodology is its simplistic, systematic and orthodox approach. However, it has many
shortcomings since bugs and errors in the code are not discovered until and unless the testing
stage is reached. This can often lead to wastage of time, money and valuable resources.

V Model
The V model gets its name from the fact that the graphical representation of the different test
process activities involved in this methodology resembles the letter 'V'. The basic steps involved
in this methodology are more or less the same as those in the waterfall model. However, this
model follows both a 'top-down' as well as a 'bottom-up' approach (you can visualize them
forming the letter 'V'). The benefit of this methodology is that in this case, both the
development and testing activities go hand-in-hand. For example, as the development team
goes about its requirement analysis activities, the testing team simultaneously begins with
its acceptance testing activities. By following this approach, time delays are minimized and
optimum utilization of resources is assured.

Spiral Model
As the name implies, the spiral model follows an approach in which there are a number of
cycles (or spirals) of all the sequential steps of the waterfall model. Once the initial cycle is
completed, a thorough analysis and review of the achieved product or output is performed. If it
is not as per the specified requirements or expected standards, a second cycle follows, and so
on. This methodology follows an iterative approach and is generally suited for very large
projects having complex and constantly changing requirements.

Rational Unified Process (RUP)

The RUP methodology is also similar to the spiral model in the sense that the entire testing
procedure is broken up into multiple cycles or processes. Each cycle consists of four phases
namely; inception, elaboration, construction and transition. At the end of each cycle, the
product or the output is reviewed and a further cycle (made up of the same four phases)
follows if necessary. Today, you will find certain organizations and companies adopting a
slightly modified version of the RUP, which goes by the name of Enterprise Unified Process
(EUP).

Agile Model
This methodology follows neither a purely sequential approach nor does it follow a purely
iterative approach. It is a selective mix of both of these approaches in addition to quite a few
new developmental methods. Fast and incremental development is one of the key principles of
this methodology. The focus is on obtaining quick, practical and visible outputs and results,
rather than merely following theoretical processes. Continuous customer interaction and
participation is an integral part of the entire development process.

Rapid Application Development (RAD)

The name says it all. In this case, the methodology adopts a rapid development approach by
using the principle of component-based construction. After understanding the various
requirements, a rapid prototype is prepared and is then compared with the expected set of
output conditions and standards. Necessary changes and modifications are made after joint
discussions with the customer or the development team (in the context of software testing).
Though this approach does have its share of advantages, it can be unsuitable if the project is
large, complex and happens to be of an extremely dynamic nature, wherein the requirements
are constantly changing. Here are some more advantages of rapid application development.

This was a short overview of some commonly used software testing methodologies. With the
applications of information technology growing with every passing day, the importance of
proper software testing has grown multifold.

Software Testing - White Box Testing Strategy

An introduction to White Box Testing Strategy and various types of testing that comes under
white box testing strategy.

What is a White Box Testing Strategy?

White box testing strategy deals with the internal logic and structure of the code. White box
testing is also called as glass, structural, open box or clear box testing. The tests written based
on the white box testing strategy incorporate coverage of the code written, branches, paths,
statements and internal logic of the code etc.

In order to implement white box testing, the tester has to deal with the code and hence is
needed to possess knowledge of coding and logic i.e. internal working of the code. White box
test also needs the tester to look into the code and find out which unit/statement/chunk of the
code is malfunctioning.

Advantages of White box testing are:

i) As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out
which type of input/data can help in testing the application effectively. 
ii) The other advantage of white box testing is that it helps in optimizing the code
iii) It helps in removing the extra lines of code, which can bring in hidden defects.

Disadvantages of white box testing are:

i) As knowledge of code and internal structure is a prerequisite, a skilled tester is needed to
carry out this type of testing, which increases the cost.
ii) And it is nearly impossible to look into every bit of code to find out hidden errors, which may
create problems, resulting in failure of the application.

Types of testing under White/Glass Box Testing Strategy:

Unit Testing:
The developer carries out unit testing in order to check if the particular module or unit of code
is working fine. The Unit Testing comes at the very basic level as it is carried out as and when
the unit of the code is developed or a particular functionality is built.

Static and dynamic Analysis:

Static analysis involves going through the code in order to find out any possible defect in the
code. Dynamic analysis involves executing the code and analyzing the output.

Statement Coverage:
In this type of testing the code is executed in such a manner that every statement of the
application is executed at least once. It helps in assuring that all the statements execute
without any side effect.

Branch Coverage:
No software application can be written in a continuous mode of coding, at some point we need
to branch out the code in order to perform a particular functionality. Branch coverage testing
helps in validating of all the branches in the code and making sure that no branching leads to
abnormal behavior of the application.

Security Testing:
Security Testing is carried out in order to find out how well the system can protect itself from
unauthorized access, hacking – cracking, any code damage etc. which deals with the code of
application. This type of testing needs sophisticated testing techniques.

Mutation Testing:
A kind of testing in which, the application is tested for the code that was modified after fixing a
particular bug/defect. It also helps in finding out which code and which strategy of coding can
help in developing the functionality effectively.

Besides all the testing types given above, there are some more types which fall under both
Black box and White box testing strategies such as: Functional testing (which deals with the
code in order to check its functional performance), Incremental integration testing (which deals
with the testing of newly added code in the application), Performance and Load testing (which
helps in finding out how the particular code manages resources and give performance etc.) etc.

What is a Black Box Testing Strategy?

Black Box Testing is not a type of testing; it instead is a testing strategy, which does not need
any knowledge of internal design or code etc. As the name "black box" suggests, no knowledge
of internal logic or code structure is required. The types of testing under this strategy are totally
based/focused on the testing for requirements and functionality of the work product/software
application. Black box testing is sometimes also called as "Opaque Testing",
"Functional/Behavioral Testing" and "Closed Box Testing".

The base of the Black box testing strategy lies in the selection of appropriate data as per
functionality and testing it against the functional specifications in order to check for normal and
abnormal behavior of the system. Now a days, it is becoming common to route the Testing
work to a third party as the developer of the system knows too much of the internal logic and
coding of the system, which makes it unfit to test the application by the developer.

In order to implement Black Box Testing Strategy, the tester is needed to be thorough with the
requirement specifications of the system and as a user, should know, how the system should
behave in response to the particular action.

Various testing types that fall under the Black Box Testing strategy are: functional testing, stress
testing, recovery testing, volume testing, User Acceptance Testing (also known as UAT), system
testing, Sanity or Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc
testing, alpha testing, beta testing etc.

These testing types are again divided in two groups: a) Testing in which user plays a role of
tester and b) User is not required.

Testing method where user is not required:

Functional Testing:
In this type of testing, the software is tested for the functional requirements. The tests are
written in order to check if the application behaves as expected.

Stress Testing:
The application is tested against heavy load such as complex numerical values, large number of
inputs, large number of queries etc. which checks for the stress/load the applications can
withstand.

Load Testing:
The application is tested against heavy loads or inputs such as testing of web sites in order to
find out at what point the web-site/application fails or at what point its performance degrades.

Ad-hoc Testing:
This type of testing is done without any formal Test Plan or Test Case creation. Ad-hoc testing
helps in deciding the scope and duration of the various other testing and it also helps testers in
learning the application prior starting with any other testing.

Exploratory Testing:
This testing is similar to the ad-hoc testing and is done in order to learn/explore the application.

Usability Testing:
This testing is also called as ‘Testing for User-Friendliness’. This testing is done if User Interface
of the application stands an important consideration and needs to be specific for the specific
type of user.

Smoke Testing:
This type of testing is also called sanity testing and is done in order to check if the application is
ready for further major testing and is working properly without failing up to least expected
level.

Recovery Testing:
Recovery testing is basically done in order to check how fast and better the application can
recover against any type of crash or hardware failure etc. Type or extent of recovery is specified
in the requirement specifications.

Volume Testing:
Volume testing is done against the efficiency of the application. Huge amount of data is
processed through the application (which is being tested) in order to check the extreme
limitations of the system.

Testing where user plays a role/user is required:

User Acceptance Testing:

In this type of testing, the software is handed over to the user in order to find out if the
software meets the user expectations and works as it is expected to.

Alpha Testing:
In this type of testing, the users are invited at the development center where they use the
application and the developers note every particular input or action carried out by the user. Any
type of abnormal behavior of the system is noted and rectified by the developers.

Beta Testing:
In this type of testing, the software is distributed as a beta version to the users and users test
the application at their sites. As the users explore the software, in case if any exception/defect
occurs that is reported to the developers.

software Testing - An Introduction To Usability Testing

Success of any newly designed and developed software strongly and mainly depends on what
extent the software meets the requirements stated by user and how the intended/end user
finds the software to operate?

Usability Testing:
As the term suggest, usability means how better something can be used over the purpose it has
been created for. Usability testing means a way to measure how people (intended/end user)
find it (easy, moderate or hard) to interact with and use the system keeping its purpose in
mind. It is a standard statement that "Usability testing measures the usability of the system".

Why Do We Need Usability Testing?

Usability testing is carried out in order to find out if there is any change needs to be carried out
in the developed system (may it be design or any specific procedural or programmatic change)
in order to make it more and more user friendly so that the intended/end user who is
ultimately going to buy and use it receives the system which he can understand and use it with
utmost ease.
Any changes suggested by the tester at the time of usability testing, are the most crucial points
that can change the stand of the system in intended/end user’s view. Developer/designer of
the system need to incorporate the feedbacks (here feedback can be a very simple change in
look and feel or any complex change in the logic and functionality of the system) of usability
testing into the design and developed code of the system (the word system may be a single
object or an entire package consisting more than one objects) in order to make system more
and more presentable to the intended/end user.

Developer often try to make the system as good looking as possible and also tries to fit the
required functionality, in this endeavor he may have forgotten some error prone conditions
which are uncovered only when the end user is using the system in real time.
Usability testing helps developer in studying the practical situations where the system will be
used in real time. Developer also gets to know the areas that are error prone and the area of
improvement.

In simple words, usability testing is an in-house dummy-release of the system before the actual
release to the end users, where developer can find and fix all possible loop holes.

How Usability Test Is Carried Out?

Usability test, as mentioned above is an in-house dummy release before the actual release of
the system to the intended/end user. Hence, a setup is required in which developer and testers
try to replicate situations as realistic as possible to project the real time usage of the system.
The testers try to use the system in exactly the same manner that any end user can/will do.
Please note that, in this type of testing also, all the standard instruction of testing are followed
to make it sure that the testing is done in all the directions such as functional testing, system
integration testing, unit testing etc.

The outcome/feedback is noted down based on observations of how the user is using the
system and what are all the possible ways that also may come into picture, and also based on
the behavior of the system and how easy/hard it is for the user to operate/use the system. User
is also asked for his/her feedback based on what he/she thinks should be changed to improve
the user interaction between the system and the end user. 

Usability testing measures various aspects such as:

How much time the tester/user and system took to complete basic flow?
How much time people take to understand the system (per object) and how many mistakes
they make while performing any process/flow of operation? 
How fast the user becomes familiar with the system and how fast he/she can recall the
system’s functions?
And the most important: how people feel when they are using the system?

Over the time period, many people have formulated various measures and models for
performing usability testing. Any of the models can be used to perform the test.

Advantages of Usability Testing

 Usability test can be modified to cover many other types of testing such as functional
testing, system integration testing, unit testing, smoke testing etc. (with keeping the
main objective of usability testing in mind) in order to make it sure that testing is done
in all the possible directions.
 Usability testing can be very economical if planned properly, yet highly effective and
beneficial.
 If proper resources (experienced and creative testers) are used, usability test can help in
fixing all the problems that user may face even before the system is finally released to
the user. This may result in better performance and a standard system.
 Usability testing can help in uncovering potential bugs and potholes in the system which
generally are not visible to developers and even escape the other type of testing.
Usability testing is a very wide area of testing and it needs fairly high level of understanding of
this field along with creative mind. People involved in the usability testing are required to
possess skills like patience, ability to listen to the suggestions, openness to welcome any idea,
and the most important of them all is that they should have good observation skills to spot and
fix the problems on fly.

Software Testing - Stress Testing

Stress testing is a process for establishing limits of adverse environments in which the
system/software/website under test will crash. Know more about stress testing...

Stress testing has different meaning for different industries where it is used. For a financial
industry/sector, stress testing means a process of testing financial instruments to find out their
robustness and level of accuracy they can maintain under extreme conditions such as sudden or
continuous market crash at a certain level, sudden or extreme change in various parameters,
for example interest rates, repo and reverse repo used in the financial sector, sudden rise or
decline in the price of materials that can affect financial projections etc. For the manufacturing
industry, stress testing may include different parameters and operating process for testing of
different systems. For medical industry, stress testing means a process that can help
understand a patient’s condition, etc.

Stress Testing in IT Industry

Stress testing in IT industry (hardware as well as software sectors) means testing of

software/hardware for its effectiveness in giving consistent or satisfactory performance under
extreme and unfavorable conditions such as heavy network traffic, heavy processes load, under
or over clocking of underlying hardware, working under maximum requests for resource
utilization of the peripheral or in the system etc.

In other words, stress testing helps find out the level of robustness and consistent or
satisfactory performance even when the limits for normal operation for the system
(software/hardware) is crossed.

Most important use of stress testing is found in testing of software and hardware that are
supposed to be operating in critical or real time situation. Such as a website will always be
online and the server hosting the website must be able to handle the traffic in all possible ways
(even if the traffic increases manifold), a mission critical software or hardware that works in real
time scenario etc. Stress testing in connection with websites or certain software is considered
to be an effective process of determining the limit, at which the
system/software/hardware/website shows robustness, is always available to perform its task,
effectively manages the load than the normal scenario and even shows effective error
management under extreme conditions.

Need for Stress Testing

Stress testing is considered to be important because of following reasons:

1. Almost 90% of the software/systems are developed with an assumption that they will be
operating under normal scenario. And even if it is considered that the limit of normal
operating conditions will be crossed, it is not considerably as high as it really could be.
2. The cost or effect of a very important (critical) software/system/website failure under
extreme conditions in real time can be huge (or may be catastrophic for the organization
or entity owning the software/system).
3. It is always better to be prepared for extreme conditions rather than letting the
system/software/website crash, when the limit of normal operation is crossed.
4. Testing carried out by the developer of the system/software/website may not be
sufficient to help unveil conditions which will lead to crash of the system/software when
it is actually submitted to the operating environment.
5. It's not always possible to unveil possible problems or bugs in a system/software, unless
it is subjected to such type of testing.
To help overcome problems like denial of service attacks, in case of web servers for a web
site, security breach related problems due tospamming, hacking and viruses etc., problems
arising out of conditions where software/system/website need to handle requests for resource
allocation for requesting processes at the time when all the required resources are already
allocated to some other process that needs some more resources to complete its work (which
is called as deadlock situation), memory leak, race condition etc.

This type of testing is mostly done with the help of various stress testing softwares available in
market. These tools are configured to automate a process of increasing stress (i.e. creation and
increasing degree of adverse environment) on a system/software/website and capturing values
of various parameters that help confirm the robustness, availability and performance of the
system/software/website being tested. Few of the actions involved in stress testing are
bombarding a website with huge number of requests, running of many resource hungry
applications in a computer, making numerous attempts to access ports of a computer in order
to hack it and use it for various purposes such as spamming, spreading virus etc.

Intensity of the adverse conditions is increased slowly while measuring all the parameters till
the point where the system/software/website crashes. The collected data (observation and
parameter values) are used for further improvement of the system/software/website.

Software Testing - Brief Introduction To Security Testing

Security testing is an important process in order to ensure that the systems/applications that
your organization is using meet security policies and are free from any type of loopholes that
can cause your organization a big loss.

Non-Destructive Testing

Full Range of Leading NDT Equipment View Our Catalog Online Today!  www.mac-ndt.com

Security Testing of any developed system (or a system under development) is all about finding
out all the potential loopholes and weaknesses of the system, which might result into loss/theft
of highly sensitive information or destruction of the system by an intruder/outsider. Security
Testing helps in finding out all the possible vulnerabilities of the system and help developers in
fixing those problems. 
Need of Security Testing

 Security test helps in finding out loopholes that can cause loss of important information
and allow any intruder enter into the systems.
 Security Testing helps in improving the current system and also helps in ensuring that
the system will work for longer time (or it will work without hassles for the estimated
time).
 Security Testing doesn’t only include conformance of resistance of the systems your
organization uses, it also ensures that people in your organization understand and obey
security policies. Hence adding up to the organization-wide security.
 If involved right from the first phase of system development life cycle, security testing
can help in eliminating the flaws into design and implementation of the system and in
turn help the organization in blocking the potential security loopholes in the earlier
stage. This is beneficial to the organization almost in all aspects (financially, security and
even efforts point of view).

Who need Security Testing? 

Now a day, almost all organizations across the world are equipped with hundreds of computers
connected to each other through intranets and various types of LANs inside the organization
itself and through Internet with the outer world and are also equipped with data storage &
handling devices. The information that is stored in these storage devices and the applications
that run on the computers are highly important to the organization from the business, security
and survival point of view.

Any organization small or big in size, need to secure the information it possesses and the
applications it uses in order to protect its customer’s information safe and suppress any
possible loss of its business.
Security testing ensures that the systems and applications used by the organizations are secure
and not vulnerable to any type of attack.

What are the different types of Security Testing? 

Following are the main types of security testing:

 Security Auditing: Security Auditing includes direct inspection of the application

developed and Operating Systems & any system on which it is being developed. This
also involves code walk-through.
 Security Scanning: It is all about scanning and verification of the system and
applications. During security scanning, auditors inspect and try to find out the
weaknesses in the OS, applications and network(s).
 Vulnerability Scanning: Vulnerability scanning involves scanning of the application for
all known vulnerabilities. This scanning is generally done through various vulnerability
scanning software.
 Risk Assessment: Risk assessment is a method of analyzing and deciding the risk that
depends upon the type of loss and the possibility/probability of loss occurrence. Risk
assessment is carried out in the form of various interviews, discussions and analysis of
the same. It helps in finding out and preparing possible backup-plan for any type of
potential risk, hence contributing towards the security conformance.
 Posture Assessment & Security Testing: This is a combination of Security Scanning, Risk
Assessment and Ethical Hacking in order to reach a conclusive point and help your
organization know its stand in context with Security.
 Penetration Testing: In this type of testing, a tester tries to forcibly access and enter the
application under test. In the penetration testing, a tester may try to enter into the
application/system with the help of some other application or with the help of
combinations of loopholes that the application has kept open unknowingly. Penetration
test is highly important as it is the most effective way to practically find out potential
loopholes in the application.
  Ethical Hacking: It’s a forced intrusion of an external element into the system &
applications that are under Security Testing. Ethical hacking involves number of
penetration tests over the wide network on the system under test.

(Please Note: The above given list of security types is based on the Open Source Security
Testing Methodology Manual of Pete Herzog and the Institute for Security and Open
Methodologies - ISECOM)

The best way to ensure security is to involve the security related assessments, audits and
various types of testing right from the first phase of system development. The level and form of
processes used in security testing of any system varies depending upon the phase, condition
and type of system under testing.

Software Testing - Compatibility Testing

Compatibility testing is a non-functional software testing that helps evaluate a
system/application's performance in connection with the operating environment. Read on to
know more about compatibility testing.

CEC Performance Test

PV Module Testing Lab Accredited For Design Qualification. Call Now!  www.TuvPtl.com

Compatibility testing is one of the several types of software testing performed on a system that
is built based on certain criteria and which has to perform specific functionality in an already
existing setup/environment. Compatibility of a system/application being developed with, for
example, other systems/applications, OS, Network, decide many things such as use of the
system/application in that environment, demand of the system/application etc. Many a times,
users prefer not to opt for an application/system just because it is not compatible with any
other system/application, network, hardware or OS they are already using. This leads to a
situation where the development efforts taken by developers prove to be in vain.

What is Compatibility Testing

Compatibility testing is a type of testing used to ensure compatibility of the

system/application/website built with various other objects such as other web browsers,
hardware platforms, users (in case if its very specific type of requirement, such as a user who
speaks and can read only a particular language), operating systems etc. This type of testing
helps find out how well a system performs in a particular environment that includes hardware,
network, operating system and other software etc.

Compatibility testing can be automated using automation tools or can be performed manually
and is a part of non-functional software testing.

Developers generally lookout for the evaluation of following elements in a computing

environment (environment in which the newly developed system/application is tested and
which has similar configuration as the actual environment in which the system/application is
supposed to fit and start working).

Hardware: Evaluation of the performance of system/application/website on a certain hardware

platform. For example: If an all-platform compatible game is developed and is being tested for
hardware compatibility, the developer may choose to test it for various combinations of
chipsets (such as Intel, Macintosh GForce), motherboards etc.

Browser: Evaluation of the performance of system/website/application on a certain type of

browser. For example: A website is tested for compatibility with browsers like Internet Explorer,
Firefox etc. (usually browser compatibility testing is also looked at as a user experience testing,
as it is related to user’s experience of the application/website, while using it on different
browsers).

Network: Evaluation of the performance of system/application/website on network with

varying parameters such as bandwidth, variance in capacity and operating speed of underlying
hardware etc., which is set up to replicate the actual operating environment.

Peripherals: Evaluation of the performance of system/application in connection with various

systems/peripheral devices connected directly or via network. For example: printers, fax
machines, telephone lines etc.

Compatibility between versions: Evaluation of the performance of system/application in

connection with its own predecessor/successor versions (backward and forward compatibility).
For example: Windows 98 was developed with backward compatibility for Windows 95 etc.

Softwares: Evaluation of the performance of system/application in connection with other

softwares. For example: Software compatibility with operating tools for network, web servers,
messaging tools etc.

Operating System: Evaluation of the performance of system/application in connection with the

underlying operating system on which it will be used.

Databases: Many applications/systems operate on databases. Database compatibility testing is

used to evaluate an application/system’s performance in connection to the database it will
interact with.

How helpful is it?

Compatibility testing can help developers understand the criteria that their system/application
needs to attain and fulfill, in order to get accepted by intended users who are already using
some OS, network, software and hardware etc. It also helps the users to find out which system
will better fit in the existing setup they are using. 

The most important use of the compatibility testing is as already mentioned above: to ensure
its performance in a computing environment in which it is supposed to operate. This helps in
figuring out necessary changes/modifications/additions required to make the
system/application compatible with the computing environment.

1. What is testing?

Software Testing can be defined as: Testing is an activity that helps in finding out
bugs/defects/errors in a software system under development, in order to provide a bug free
and reliable system/solution to the customer.

In other words, you can consider an example as: suppose you are a good cook and are
expecting some guests at dinner. You start making dinner; you make few very very very
delicious dishes (off-course, those which you already know how to make). And finally, when you
are about to finish making the dishes, you ask someone (or you yourself) to check if everything
is fine and there is no extra salt/chili/anything, which if is not in balance, can ruin your evening
(This is what called 'TESTING').

This procedure you follow in order to make it sure that you do not serve your guests something
that is not tasty! Otherwise your collar will go down and you will regret over your failure!

2. Why we go for testing?

Well, while making food, its ok to have something extra, people might understand and eat the
things you made and may well appreciate your work. But this isn't the case with Software
Project Development. If you fail to deliver a reliable, good and problem free software solution,
you fail in your project and probably you may loose your client. This can get even worse!

So in order to make it sure, that you provide your client a proper software solution, you go for
TESTING. You check out if there is any problem, any error in the system, which can make
software unusable by the client. You make software testers test the system and help in finding
out the bugs in the system to fix them on time. You find out the problems and fix them and
again try to find out all the potential problems.

3. Why there is need of testing?

OR

Why there is a need of 'independent/separate testing'?

This is a right question because, prior to the concept of TESTING software as a ‘Testing Project’,
the testing process existed, but the developer(s) did that at the time of development.

But you must know the fact that, if you make something, you hardly feel that there can be
something wrong with what you have developed. It's a common trait of human nature, we feel
that there is no problem in our designed system as we have developed it and it is perfectly
functional and fully working. So the hidden bugs or errors or problems of the system remain
hidden and they raise their head when the system goes into production.

On the other hand, its a fact that, when one person starts checking something which is made by
some other person, there are 99% chances that checker/observer will find some problem with
the system (even if the problem is with some spelling that by mistake has been written in wrong
way.). Really weird, isn't it? But that’s a truth!
Even though its wrong in terms of human behavior, this thing has been used for the benefit of
software projects (or you may say, any type of project). When you develop something, you give
it to get checked (TEST) and to find out any problem, which never aroused while development
of the system. Because, after all, if you could minimize the problems with the system you
developed, it’s beneficial for yourself. Your client will be happy if your system works without
any problem and will generate more revenues for you.

BINGO, it's really great, isn't it? That's why we need testing!

4. What is the role of "a tester"?

A tester is a person who tries to find out all possible errors/bugs in the system with the help of
various inputs to it. A tester plays an important part in finding out the problems with system
and helps in improving its quality.

If you could find all the bugs and fix them all, your system becomes more and more reliable.

A tester has to understand the limits, which can make the system break and work abruptly. The
more number of VALID BUGS tester finds out, the better tester he/she is!

What is Rational Unified Process (RUP)

Rational Unified Process (RUP) is a comprehensive software engineering process. It features a
disciplined approach towards industry-tested practices for designing softwares and systems
within a development organization. Continue reading, if you want to know what is rational
unified process (RUP)?

Test Strategy & Process

Learn Tacticle & Strategic Approach Regardless of Methodology @ STP2010  www.stpcon.com

The concept of Rational Unified Process (RUP) came from the Rational Software Corporation, a
division of IBM (International Business Machines Corporation). It keeps a check on
effective project management and high-quality production of software. The basic methodology
followed in RUP is based on a comprehensive web-enabled program development and object-
oriented approach.The 'Rational Unified Process' adopts the 'Unified Modeling Language' and
provides the best practiced guidelines, templates and illustrations of all aspects for program
development. Here is a simple breakdown of all the aspects related to this concept, so as to
give you a brief understanding as to what is rational unified process (RUP)?

There are primarily four phases or stages of development that is concluded with a release in
RUP. Here is a quick review of all the four stages or cycles.

Inception Phase
In the inception phase, the goal is to develop the parent idea into a product vision by defining
its scope and the business case. The business case includes business context, factors influencing
success, risk assessment and financial forecast. This is to get an understanding of the business
drivers and to justify the launch of the project. This phase is to identify the work flows required
by the project. 

Elaboration Phase
Here the architectural foundation, project plan and high-risk factors of the project are
determined, after analyzing the problem domain. For establishing these objectives, an in-and-
out knowledge of the system is a must. In other words, the performance requirements, scope
and functionality of the system, influence the deciding factor in the architectural concept of the
project. Architectural and planning decisions are governed by the most critical use-cases. So, a
perfect understanding of the use-cases and an articulated vision is what this phase of
elaboration looks forward to achieve. This is an important phase. Since, after this phase the
project is carried on to a level where any changes might cause disastrous outcome for the
entire operation.

Construction Phase
As the name suggests, the phase involves construction of the software system or project. Here,
development of the remaining components and application features is performed. Thereafter,
they are integrated into the product which is moved from an architectural baseline to a
completed system. In short, the source code and the application design is created for the
software for its transition to the user community. The construction phase is the first external
release of the software, wherein, adequate quality with optimization of resources is achieved
rapidly. 

Transition Phase
Transition phase marks the transition of the project from development to production. This
stage is to ensure that the user requirements have been satisfied and met by the product. The
initiative is done by testing the product before its release as a beta version. This beta version is
enhanced by bug fixing, site preparation, manual completion, defect identification and
improving performance and usability. Other objectives are also taken up. They include

 Training users and maintainers for successful operation of the system

 Purchasing hardware
 Converting data from old to new systems
 Arranging for activities for successful launch of the product
 Holding sessions of learning lessons for improving future process and tool environment.

Rational Unified Process mentions six best practices, which have to be kept in mind when
designing any software. These practices help prevent flaws in the project development and
create more scope for efficient productivity. These six practices are as follows.

1. An iterative (executing the same set of instructions a given number of times or until a

specified result is obtained) approach towards thesoftware development.

 2. Managing user requirements.
3. Use and test individual components before being integrated into a larger system.

Use 'Unified Modeling Language' tool to get a visual model of the components, users
and their interaction relating to the project.Constant testing of the software quality is
considered one of the best practices in any software development.

4. For a successful iterative development, monitoring, tracking and controlling changes

made to a system is essential for a team to work together as a single unit.

The concept of rational unified process has endless explanation and description. Each and every
important and essential considerations in a software development has been defined to its root.
RUP results in a reduced IT costs, improved IT business, higher quality, higher service level and
sharper adaptability, and most importantly, higher ROI (return on investments), and many
other benefits. The above is just a theoretical brief explanation to the question as to what is
RUP? However, a clearer and elaborated idea can be achieved once the process is put into
practical use.
how to Prototype an Idea or Invention
Expert guide to prototyping a new idea or invention, including advice on patenting and
designing a new idea.

Each idea is different and the best approach to prototyping depends on the specifics of the
idea. However there are some basic principles that can help. The first question to ask is: "What
is the prototype for?" 

Presentation to interested parties

When presenting your idea to an investor or company representative it might not actually be
necessary to have a prototype. It is often possible to convey the idea or invention to an
interested party using a graphic presentation. The idea should be designed, ideally using
computer aided design, and then images of the product laid out on presentation boards. It is
probably best to get a professional product designer to complete the design work and show
how the product looks and what it does. Try to find a design company that specializes in
product design for inventors. One UK based company is Innovate Design.

If funds are tight it is better to spend the money on a professional presentation rather than a
prototype. The presentation will be more cost effective than the prototype and will be quicker
to produce. The work done during the design stage can help reduce the cost of the prototyping
stage if it becomes necessary at a later date. 

When a prototype is necessary

Concept prototypes are sometimes necessary to either prove that an idea works or instantly
convey an idea that is hard to describe on paper. If people need to interact with the idea to be
persuaded of its benefits then a prototype can make all the difference. 

Often people are more prepared to back an idea if they can see that a lot of the development
work has already been done and a prototype demonstrates this. An inventor could typically
expect to charge more for an idea if it has been prototyped so it is worth considering if the
funds are available.

How much will a prototype cost?

Prototypes costs vary hugely depending on the size and complexity of the idea. Typically for a
small hand held product with a unique shape it could be in the region of two to three thousand
pounds.

Why are prototypes so expensive?

Often the idea has to be designed first to establish the layout of internal components and the
shape of the casing among other considerations. Then a virtual model has to be built using
computer aided design and then finally a prototype can be built using rapid prototyping. All of
this takes time and therefore it is expensive.

What is rapid prototyping?

Rapid prototyping is a technology that takes a 3D computer model and builds a 3D plastic part.
There are three basic techniques for rapid prototyping: Stereolithography, Selective Laser
Sintering and Fusion Deposition Modelling. For all these processes the model needs to be
professionally designed using computer aided design.

Are there cheaper ways of building a prototype?

Some ideas can be prototyped simply from existing products or by using ordinary materials and
these will be cheaper than prototypes that are built using rapid prototyping. Another cheaper
way is to build a prototype that proves the principle of the idea without necessarily looking like
the final product. This is called a ‘proof of principle’ prototype. Alternatively an aesthetic model
could be built that shows what the product will look like but does not prove whether it will
work.

What are the different types of prototype?

There are three main categories of prototype:

1. Proof of principle: A prototype that simply proves that a particularly new system or
mechanism works. Often it is just part of the overall idea and it does not need to look like the
final product.
Software Verification & Validation Model - An Introduction

 
A perfect software product is built when every step is taken with full consideration that ‘A right
product is developed in a right manner’. ‘Software Verification & Validation’ is one such model,
which helps the system designers and test engineers to confirm that a right product is build
right way throughout the development process and improve the quality of the software
product.

‘Verification & Validation Model’ makes it sure that, certain rules are followed at the time of
development of a software product and also makes it sure that the product that is developed
fulfills the required specifications. This reduces the risk associated with any software project up
to certain level by helping in detection and correction of errors and mistakes, which are
unknowingly done during the development process.

What is Verification?
The standard definition of Verification goes like this: "Are we building the product RIGHT?" i.e.
Verification is a process that makes it sure that the software product is developed the right
way. The software should confirm to its predefined specifications, as the product development
goes through different stages, an analysis is done to ensure that all required specifications are
met.

Methods and techniques used in the Verification and Validation shall be designed carefully, the
planning of which starts right from the beginning of the development process. The Verification
part of ‘Verification and Validation Model’ comes before Validation, which incorporates
Software inspections, reviews, audits, walkthroughs, buddy checks etc. in each phase of
verification (every phase of Verification is a phase of the Testing Life Cycle)

During the Verification, the work product (the ready part of the Software being developed and
various documentations) is reviewed/examined personally by one ore more persons in order to
find and point out the defects in it. This process helps in prevention of potential bugs, which
may cause in failure of the project.
Few terms involved in Verification:
Inspection:
Inspection involves a team of about 3-6 people, led by a leader, which formally reviews the
documents and work product during various phases of the product development life cycle. The
work product and related documents are presented in front of the inspection team, the
member of which carry different interpretations of the presentation. The bugs that are
detected during the inspection are communicated to the next level in order to take care of
them.

Walkthroughs:
Walkthrough can be considered same as inspection without formal preparation (of any
presentation or documentations). During the walkthrough meeting, the presenter/author
introduces the material to all the participants in order to make them familiar with it. Even when
the walkthroughs can help in finding potential bugs, they are used for knowledge sharing or
communication purpose.

Buddy Checks:
This is the simplest type of review activity used to find out bugs in a work product during the
verification. In buddy check, one person goes through the documents prepared by another
person in order to find out if that person has made mistake(s) i.e. to find out bugs which the
author couldn’t find previously.

The activities involved in Verification process are: Requirement Specification verification,

Functional design verification, internal/system design verification and code verification (these
phases can also subdivided further). Each activity makes it sure that the product is developed
right way and every requirement, every specification, design code etc. is verified!

What is Validation?
Validation is a process of finding out if the product being built is right?
i.e. whatever the software product is being developed, it should do what the user expects it to
do. The software product should functionally do what it is supposed to, it should satisfy all the
functional requirements set by the user. Validation is done during or at the end of the
development process in order to determine whether the product satisfies specified
requirements.

Validation and Verification processes go hand in hand, but visibly Validation process starts after
Verification process ends (after coding of the product ends). Each Verification activity (such as
Requirement Specification Verification, Functional design Verification etc.) has its
corresponding Validation activity (such as Functional Validation/Testing, Code
Validation/Testing, System/Integration Validation etc.).

All types of testing methods are basically carried out during the Validation process. Test plan,
test suits and test cases are developed, which are used during the various phases of Validation
process. The phases involved in Validation process are: Code Validation/Testing, Integration
Validation/Integration Testing, Functional Validation/Functional Testing, and System/User
Acceptance Testing/Validation.

Terms used in Validation process:

Code Validation/Testing:
Developers as well as testers do the code validation. Unit Code Validation or Unit Testing is a
type of testing, which the developers conduct in order to find out any bug in the code
unit/module developed by them. Code testing other than Unit Testing can be done by testers or
developers.

Integration Validation/Testing:
Integration testing is carried out in order to find out if different (two or more) units/modules
co-ordinate properly. This test helps in finding out if there is any defect in the interface
between different modules.

Functional Validation/Testing:
This type of testing is carried out in order to find if the system meets the functional
requirements. In this type of testing, the system is validated for its functional behavior.
Functional testing does not deal with internal coding of the project, in stead, it checks if the
system behaves as per the expectations.

User Acceptance Testing or System Validation:

In this type of testing, the developed product is handed over to the user/paid testers in order to
test it in real time scenario. The product is validated to find out if it works according to the
system specifications and satisfies all the user requirements. As the user/paid testers use the
software, it may happen that bugs that are yet undiscovered, come up, which are
communicated to the developers to be fixed. This helps in improvement of the final product.

Software Testing - Acceptance Testing

Acceptance testing is associated not only with software field but also to any other field (such as
manufacturing, engineering, even non-technical) that involves a customer and a system
developed for the customer and developers of the system.

Acceptance testing (also known as user acceptance testing) is a type of testing carried out in
order to verify if the product is developed as per the standards and specified criteria and meets
all the requirements specified by customer. This type of testing is generally carried out by a
user/customer where the product is developed externally by another party.

Acceptance testing falls under black box testing methodology where the user is not very much
interested in internal working/coding of the system, but evaluates the overall functioning of the
system and compares it with the requirements specified by them. User acceptance testing is
considered to be one of the most important testing by user before the system is finally
delivered or handed over to the end user.

Acceptance testing is also known as validation testing, final testing, QA testing, factory
acceptance testing and application testing etc. And in software engineering, acceptance testing
may be carried out at two different levels; one at the system provider level and another at the
end user level (hence called user acceptance testing, field acceptance testing or end-user
testing).

Acceptance testing in software engineering generally involves execution of number test cases

which constitute to a particular functionality based on the requirements specified by the user.
During acceptance testing, the system has to pass through or operate in a computing
environment that imitates the actual operating environment existing with user. The user may
choose to perform the testing in an iterative manner or in the form of a set of varying
parameters (for example: missile guidance software can be tested under varying payload,
different weather conditions etc.).

The outcome of the acceptance testing can be termed as success or failure based on the critical
operating conditions the system passes through successfully/unsuccessfully and the user’s final
evaluation of the system.

The test cases and test criterion in acceptance testing are generally created by end user and
cannot be achieved without business scenario criteria input by user. This type of testing and
test case creation involves most experienced people from both sides (developers and users) like
business analysts, specialized testers, developers, end users etc.

Process involved in Acceptance Testing

1. Test cases are created with the help of business analysts, business customers (end
users), developers, test specialists etc.
 2. Test cases suites are run against the input data provided by the user and for the number
of iterations that the customer sets as base/minimum required test runs.
3. The outputs of the test cases run are evaluated against the criterion/requirements
specified by user.
4. Depending upon the outcome if it is as desired by the user or consistent over the
number of test suites run or non conclusive, user may call it successful/unsuccessful or
suggest some more test case runs.
5. Based on the outcome of the test runs, the system may get rejected or accepted by the
user with or without any specific condition.

Acceptance testing is done in order to demonstrate the ability of system/product to perform as

per the expectations of the user and induce confidence in the newly developed
system/product. A sign-off on contract stating the system as satisfactory is possible only after
successful acceptance testing.

Types of Acceptance Testing

User Acceptance Testing: User acceptance testing in software engineering is considered to be

an essential step before the system is finally accepted by the end user. In general terms, user
acceptance testing is a process of testing the system before it is finally accepted by user.

Alpha Testing & Beta Testing: Alpha testing is a type of acceptance testing carried out at
developer’s site by users (internal staff). In this type of testing, the user goes on testing the
system and the outcome is noted and observed by the developer simultaneously. 

Beta testing is a type of testing done at user’s site. The users provide their feedback to the
developer for the outcome of testing. This type of testing is also known as field testing.
Feedback from users is used to improve the system/product before it is released to other
users/customers.
Operational Acceptance Testing: This type of testing is also known as operational
readiness/preparedness testing. It is a process of ensuring all the required components
(processes and procedures) of the system are in place in order to allow user/tester to use it.

Contact and Regulation Acceptance Testing: In contract and regulation acceptance testing, the
system is tested against the specified criteria as mentioned in the contract document and also
tested to check if it meets/obeys all the government and local authority regulations and laws
and also all the basic standards.
Software Testing - Brief Introduction To Exploratory Testing
Exploratory Software Testing, even though disliked by many, has found its place in the Software
Testing world. Exploratory testing is the only type of testing that can help in uncovering bugs
that stand more chance of being ignored by other testing strategies...

What is an Exploratory Testing?

Bach’s Definition: ‘Any testing to the extent that the tester actively controls the design of the
tests as those tests are performed and uses information gained while testing to design new and
better tests.’ 

Which simply can be put as: A type of testing where we explore software, write and execute the
test scripts simultaneously.

Exploratory testing is a type of testing where tester does not have specifically planned test
cases, but he/she does the testing more with a point-of-view to explore the software features
and tries to break it in order to find out unknown bugs.

A tester who does exploratory testing, does it only with an idea to more and more understand
the software and appreciate its features. During this process, he/she also tries to think of all
possible scenarios where the software may fail and a bug can be revealed. 

Why do we need exploratory testing?

  At times, exploratory testing helps in revealing many unknown and un-detected bugs,
which is very hard to find out through normal testing.
 As exploratory testing covers almost all the normal type of testing, it helps in improving
our productivity in terms of covering the scenarios in scripted testing and those which
are not scripted as well.
 Exploratory Testing is a learn and work type of testing activity where a tester can at least
learn more and understand the software if at all he/she was not able to reveal any
potential bug.
 Exploratory testing, even though disliked by many, helps testers in learning new
methods, test strategies, and also think out of the box and attain more and more
creativity.

Who Does Exploratory Testing? 

Any software tester knowingly or unknowingly does it!

While testing, if a tester comes across a bug, as a general practice, tester registers that bug with
the programmer. Along with registering the bug, tester also tries to make it sure that he/she
has understood the scenario and functionality properly and can reproduce the bug condition.
Once programmer fixes the bug, tester runs a test case with the same scenario replication in
which the bug had occurred previously. If tester finds that the bug is fixed, he/she again tries to
find out if the fix can handle any such same type of scenario with different inputs.

For an example, lets consider that a tester finds a bug related to an input text field on a form,
where the field is supposed to accept any digit other than the digits from 1 to 100, which it fails
to and accepts the number 100. Tester logs this bug to the programmer and now is waiting for
the fix. Once programmer fixes the bug, it sends it across to the tester so as to get it tested.
Tester now will try to test the bug with same input value (100: as he/she had found that this
condition causes application to fail) in the field. If application rejects the number (100) entered
by the tester, he/she can safely close the defect.
Now, along with the above given test input value, which had revealed the bug, tester tries to
check if there is any other value from this set (0 to 100), which can cause the application to fail.
He/she may try to enter values from 0 to 100, or may be some characters or a combination of
character and numbers in any order. All these test cases are thought by the tester as a variation
of the type of value he/she had entered previously and represent only one test scenario. This
testing is called exploratory testing, as the tester tried to explore and find out the possibility of
revealing a bug by using any possible way.

What qualities I need to posses to be able to perform an Exploratory Testing?

As I mentioned above, any software tester can perform exploratory testing.
The only limit to the extent to which you can perform exploratory testing is your imagination
and creativity, more you can think of ways to explore, understand the software, more test cases
you will be able write and execute simultaneously.

Advantages of Exploratory Testing

 Exploratory testing can uncover bugs, which are normally ignored (or hard to find) by
other testing strategies.
 It helps testers in learning new strategies, expand the horizon of their imagination that
helps them in understanding & executing more and more test cases and finally improve
their productivity.
 Exploratory testing helps tester in confirming that he/she understands the application
and its functionality properly and has no confusion about the working of even a smallest
part of it, hence covering the most important part of requirement understanding.
 As in case of exploratory testing, we write and execute the test cases simultaneously. It
helps in collecting result oriented test scripts and shading of load of unnecessary test
cases which do not yield and result.
 Exploratory testing covers almost all type of testing, hence tester can be sure of
covering various scenarios once exploratory testing is performed at the highest level (i.e.
 if the exploratory testing performed can ensure that all the possible scenarios and test
cases are covered).

Custom Software Development

Custom software development is very known term to those companies who wants a software
solution which suits to their requirements. It is not always necessary that ready made software
satisfy the functional requirement of any organization. For such cases Custom software
development is required.

As the name suggest, custom software development, also called custom software engineering,
is one that is tailor made to the special requirements of the customer. Obviously customer
software development would rise above the pre-developed, template or boxed solutions. It
would be unique in conception, design and development achieved on one time basis.

Custom software is, therefore, developed for specific functions and is quite different from the
existing or the off-the-shelf software. It is not addressed to mass market.

Examples of custom software development include accounting software, customized software

for budget or project managing, software for commercial products such as e-commerce
websites, business data bases, software for special needs of the companies, business entities,
organizations, smaller companies, charities and individuals, industries and government. 

It is quite evident from the above explanation that custom software can be developed only on a
small scale. Custom software development is a complex process and is usually founded on pre-
built building blocks which are rearranged, re-organized or re-engineered to suit the individual
needs of the clients. 

If you wish to have software built to your individual needs, you will have to first explain your
needs, the viability and affordability of the software. This would entail formation of a detailed
proposal for the development of the design of the software and building a system for its
operation. 

You will need to draw a contract with the custom software development company about the
time frame of delivery, cost and functionality. It is important that the product is delivered
functionally complete and ready for testing and deployment by the end user.

According to Blueberry Consultants, there are certain other important questions that need to
be addressed before signing the contract and some of them are:

 Who will own the copyright of the product - the producer or its owner or the payer?
 How will the system be built? Would it be built on the top of any other platform or
system?
 Will the system use or depend upon the third party systems or libraries. And will it entail
copyright violations?
 Who will control the source code?
 Who will collect the requirements from the customer?
 Will the system provide for firewall configuration?
 What is the expertise and experience of the software developing company?
 What is the strength of their expert staff?
 What programming languages will be used?
 Will they incorporate any logging system in the software to report and prevent bugs?

Interview Questions for Software Testing

Software Testing Interview Questions on Product Testing

 What will be the test cases for product testing? Give an example of test plan template.
 What are the advantages of working as a tester for a product based company as
opposed to a service based company?
  Do you know how a product based testing differs from a project based testing? Can you
give a suitable example?
 Do you know what is exactly meant by Test Plan? Name its contents? Can you give a
sample Test Plan for a Login Screen?
 How do you differentiate between testing a product and testing any web-based
application?
 What is the difference between Web based testing and Client server testing?
 How to perform SOAP Testing manually?
 Explain the significance of Waterfall model in developing a product.

Software Testing Interview Questions on Quality Assurance

 How do you ensure the quality of the product?

 What do you do when there isn't enough time for thorough testing?
 What are the normal practices of the QA specialists with perspective of a software?
 Can you tell the difference between high level design and low level design?
 Can you tell us how Quality Assurance differs from Quality Control?
 You must have heard the term Risk. Can you explain the term in a few words? What are
the major components of the risk?
 When do you say your project testing is completed? Name the factors.
 What do you mean by a walk through and inspection?
 What is the procedure for testing search buttons of a web application both manually
and using Qtp8.2?
 Explain Release Acceptance Testing. Explain Forced Error Testing. Explain Data Integrity
Testing. Explain System Integration Testing.
 How does compatibility testing differ while testing in Internet explorer and testing in
Firefox?

Software Testing Interview Questions on Testing Scenarios

  How do you know that all the scenarios for testing are covered?
 Can you explain the Testing Scenario? Also explain scenario based testing? Give an
example to support your answer.
 Consider a yahoo application. What are the test cases you can write?
 Differentiate between test scenario and test case?
 Is it necessary to create new Software requirement document, test planning report, if it
is a 'Migrating Project'?
 Explain the difference between smoke testing and sanity testing?
 What are all the scenarios to be considered while preparing test reports?
 What is an 'end to end' scenario?
 Other than requirement traceability matrix, what are the other factors that we need to
check in order to exit a testing process ?
 What is the procedure for finding out the length of the edit box through WinRunner?

Software Testing Interview Questions on Automated Testing

 What automated testing tools are you familiar with?

 Describe some problems that you encountered while working with an automated
testing tool.
 What is the procedure for planning test automation?
 What is your opinion on the question that can a test automation improve test
effectiveness?
 Can you explain data driven automation?
 Name the main attributes of test automation?
 Do you think automation can replace manual testing?
 How is a tool for test automation chosen?
 How do you evaluate the tool for test automation?
 What are the main benefits of test automation according to you?
 Where can test automation go wrong?
 Can you describe testing activities?
  What testing activities you need to automate?
 Describe common issues of test automation.
 What types of scripting techniques for test automation are you aware of?
 Name the principles of good testing scripts for automation?
 What tools can you use for support of testing during the software development life
cycle?
 Can you tell us it the activities of a test case design be automated?
 What are the drawbacks of automated software testing?
 What skills are needed to be a good software test automator?

Software Testing Interview Questions on Bug Tracking

 Can you have a defect with high severity and low priority and vice-versa i.e high priority
and low severity? Justify your answer.
 Can you explain the difference between a Bug and a Defect? Explain the phases of bug
life cycle
 What are the different types of Bugs we normally see in any of the projects? Also
include their severity.
 What is the difference between Bug Resolution Meeting and Bug Review Committee?
Who all participate in Bug Resolution Meeting and Bug Review Committee?
 Can you name some recent major computer system failures caused by software bugs?

What do you mean by 'Reproducing a bug'? What do you do, if the bug was not
reproducible?

 How can you tell if a bug is reproducible or not?

 On what basis do we give priority and severity for a bug. Provide an example for high
priority and low severity and high severity and low priority?
 Explain Defect Life Cycle in Manual Testing?
 How do you give a BUG Title & BUG Description for ODD Division?
  Have you ever heard of a build interval period?

Software testing is a vast field and there is really no dearth of software testing interview
questions. You can explore the Internet for more software testing interview questions and of
course, the solutions. Hope this article helps you to get the job of your dreams. Good Luck!
Software Testing - Test Cases
What are test cases in software testing, how they are designed and why they are so important
to the entire testing scenario, read through to know more..

What is a Test Case?

A test case is a set of conditions or variables and inputs that are developed for a particular goal
or objective to be achieved on a certain application to judge its capabilities or features.
It might take more than one test case to determine the true functionality of the application
being tested. Every requirement or objective to be achieved needs at least one test case. Some
software development methodologies like Rational Unified Process (RUP) recommend creating
at least two test cases for each requirement or objective; one for performing testing through
positive perspective and the other through negative perspective.

Test Case Structure

A formal written test case comprises of three parts -

1. Information
Information consists of general information about the test case. Information
incorporates Identifier, test case creator, test case version, name of the test case,
purpose or brief description and test case dependencies.
2. Activity
Activity consists of the actual test case activities. Activity contains information about the
test case environment, activities to be done at test case initialization, activities to be
 done after test case is performed, step by step actions to be done while testing and the
input data that is to be supplied for testing.
3. Results
Results are outcomes of a performed test case. Results data consist of information
about expected results and the actual results.

Designing Test Cases

Test cases should be designed and written by someone who understands the function or
technology being tested. A test case should include the following information -

 Purpose of the test

 Software requirements and Hardware requirements (if any)
 Specific setup or configuration requirements
 Description on how to perform the test(s)
 Expected results or success criteria for the test

Designing test cases can be time consuming in a testing schedule, but they are worth giving
time because they can really avoid unnecessary retesting or debugging or at least lower it.
Organizations can take the test cases approach in their own context and according to their own
perspectives. Some follow a general step way approach while others may opt for a more
detailed and complex approach. It is very important for you to decide between the two
extremes and judge on what would work the best for you. Designing proper test cases is very
vital for your software testing plans as a lot of bugs, ambiguities, inconsistencies and slip ups
can be recovered in time as also it helps in saving your time on continuous debugging and re-
testing test cases.

The main purpose behind any Software Development process is to provide the client (Final/End
User of the software product) with a complete solution (software product), which will help him
in managing his business/work in cost effective and efficient way. A software product
developed is considered successful if it satisfies all the requirements stated by the end user.

Any software development process is incomplete if the most important phase of Testing of the
developed product is excluded. Software testing is a process carried out in order to find out and
fix previously undetected bugs/errors in the software product. It helps in improving the quality
of the software product and make it secure for client to use.

What is a bug/error?
A bug or error in software product is any exception that can hinder the functionality of either
the whole software or part of it.

How do I find out a BUG/ERROR?

Basically, test cases/scripts are run in order to find out any unexpected behavior of the
software product under test. If any such unexpected behavior or exception occurs, it is called as
a bug.

What is a Test Case?

A test case is a noted/documented set of steps/activities that are carried out or executed on
the software in order to confirm its functionality/behavior to certain set of inputs.

What do I do if I find a bug/error?

In normal terms, if a bug or error is detected in a system, it needs to be communicated to the
developer in order to get it fixed.

Right from the first time any bug is detected till the point when the bug is fixed and closed, it is
assigned various statuses which are New, Open, Postpone, Pending Retest, Retest, Pending
Reject, Reject, Deferred, and Closed.
(Please note that there are various ways to communicate the bug to the developer and track
the bug status)

Statuses associated with a bug:

New:
When a bug is found/revealed for the first time, the software tester communicates it to his/her
team leader (Test Leader) in order to confirm if that is a valid bug. After getting confirmation
from the Test Lead, the software tester logs the bug and the status of ‘New’ is assigned to the
bug.

Assigned:
After the bug is reported as ‘New’, it comes to the Development Team. The development team
verifies if the bug is valid. If the bug is valid, development leader assigns it to a developer to fix
it and a status of ‘Assigned’ is assigned to it.

Open:
Once the developer starts working on the bug, he/she changes the status of the bug to ‘Open’
to indicate that he/she is working on it to find a solution.

Fixed:
Once the developer makes necessary changes in the code and verifies the code, he/she marks
the bug as ‘Fixed’ and passes it over to the Development Lead in order to pass it to the Testing
team.

Pending Retest:
After the bug is fixed, it is passed back to the testing team to get retested and the status of
‘Pending Retest’ is assigned to it.

Retest:
The testing team leader changes the status of the bug, which is previously marked with
‘Pending Retest’ to ‘Retest’ and assigns it to a tester for retesting.

Closed:
After the bug is assigned a status of ‘Retest’, it is again tested. If the problem is solved, the
tester closes it and marks it with ‘Closed’ status.

Reopen:
If after retesting the software for the bug opened, if the system behaves in the same way or
same bug arises once again, then the tester reopens the bug and again sends it back to the
developer marking its status as ‘Reopen’.

Pending Reject:
If the developers think that a particular behavior of the system, which the tester reports as a
bug has to be same and the bug is invalid, in that case, the bug is rejected and marked as
‘Pending Reject’.

Rejected:
If the Testing Leader finds that the system is working according to the specifications or the bug
is invalid as per the explanation from the development, he/she rejects the bug and marks its
status as ‘Rejected’.

Postponed:
Sometimes, testing of a particular bug has to be postponed for an indefinite period. This
situation may occur because of many reasons, such as unavailability of Test data, unavailability
of particular functionality etc. That time, the bug is marked with ‘Postponed’ status.

Deferred:
In some cases a particular bug stands no importance and is needed to be/can be avoided, that
time it is marked with ‘Deferred’ status.

Software Testing Life Cycle

The software testing life cycle identifies various testing activities and also explains which testing
activity needs to be carried out when. Different phases of the life cycle of software testing have
been explained in this article. So, read on.

Introduction to Software Testing Life Cycle

Every organization has to undertakes testing of each of its products. However, the way it is
conducted differs from one organization to another. This refers to the life cycle of the testing
process. It is advisable to carry out the testing process from the initial phases, with regard to
theSoftware Development Life Cycle or SDLC to avoid any complications.

Software Testing Life Cycle Phases

Software testing has its own life cycle that meets every stage of the SDLC. The software testing
life cycle diagram can help one visualize the various software testing life cycle phases. They are

1. Requirement Stage

2. Test Planning
3. Test Analysis

4. Test Design
5. Test Verification and Construction

6. Test Execution
7. Result Analysis

8. Bug Tracking
9. Reporting and Rework
10. Final Testing and Implementation
11. Post Implementation
Requirement Stage
This is the initial stage of the life cycle process in which the developers take part in analyzing
the requirements for designing a product. Testers can also involve themselves as they can think
from the users' point of view which the developers may not. Thus a panel of developers, testers
and users can be formed. Formal meetings of the panel can be held in order to document the
requirements discussed which can be further used as software requirements specifications or
SRS.
Test Planning
Test planning is predetermining a plan well in advance to reduce further risks. Without a good
plan, no work can lead to success be it software-related or routine work. A test plan document
plays an important role in achieving a process-oriented approach. Once the requirements of the
project are confirmed, a test plan is documented. The test plan structure is as follows:

1. Introduction: This describes the objective of the test plan.

2. Test Items The items that are referred to prepare this document will be listed here such
as SRS, project plan.
3. Features to be tested: This describes the coverage area of the test plan, ie. the list of
features that are to be tested that are based on the implicit and explicit requirements
from the customer.
4. Features not to be tested: The incorporated or comprised features that can be skipped
from the testing phase are listed here. Features that are out of scope of testing, like
incomplete modules or those on low severity eg. GUI features that don't hamper the
further process can be included in the list.
5. Approach: This is the test strategy that should be appropriate to the level of the plan. It
should be in acceptance with the higher and lower levels of the plan.
6. Item pass/fail criteria: Related to the show stopper issue. The criterion which is used has
to explain which test item has passed or failed.
7. Suspension criteria and resumption requirements: The suspension criterion specifies the
criterion that is to be used to suspend all or a portion of the testing activities, whereas
resumption criterion specifies when testing can resume with the suspended portion.
8. Test deliverable: This includes a list of documents, reports, charts that are required to be
presented to the stakeholders on a regular basis during testing and when testing is
completed.
9. Testing tasks: This stage is needed to avoid confusion whether the defects should be
reported for future function. This also helps users and testers to avoid incomplete
functions and prevent waste of resources.
 10. Environmental needs: The special requirements of that test plan depending on the
environment in which that application has to be designed are listed here.
11. Responsibilities: This phase assigns responsibilities to the person who can be held
responsible in case of a risk.
12. Staffing and training needs: Training on the application/system and training on the
testing tools to be used needs to be given to the staff members who are responsible for
the application.
13. Risks and contingencies:This emphasizes on the probable risks and various events that
can occur and what can be done in such situation.
14. Approval: This decides who can approve the process as complete and allow the project
to proceed to the next level that depends on the level of the plan.

Test Analysis
Once the test plan documentation is done, the next stage is to analyze what types of software
testing should be carried out at the various stages of SDLC. 

Test Design
Test design is done based on the requirements of the project documented in the SRS. This
phase decides whether manual or automated testing is to be done. In automation testing,
different paths for testing are to be identified first and writing of scripts has to be done if
required. There originates a need for an end to end checklist that covers all the features of the
project.

Test Verification and Construction

In this phase test plans, the test design and automated script tests are completed. Stress and
performance testing plans are also completed at this stage. When the development team is
done with a unit of code, the testing team is required to help them in testing that unit and
reporting of the bug if found. Integration testing and bug reporting is done in this phase of the
software testing life cycle.
Test Execution
Planning and execution of various test cases is done in this phase. Once the unit testing is
completed, the functionality of the tests is done in this phase. At first, top level testing is done
to find out top level failures and bugs are reported immediately to the development team to
get the required workaround. Test reports have to be documented properly and the bugs have
to be reported to the development team.

Result Analysis
Once the bug is fixed by the development team, i.e after the successful execution of the test
case, the testing team has to retest it to compare the expected values with the actual values,
and declare the result as pass/fail.

Bug Tracking
This is one of the important stages as the Defect Profile Document (DPD) has to be updated for
letting the developers know about the defect. Defect Profile Document contains the following

1. Defect Id: Unique identification of the Defect.

2. Test Case Id: Test case identification for that defect.
3. Description: Detailed description of the bug.
4. Summary: This field contains some keyword information about the bug, which can help
in minimizing the number of records to be searched.
5. Defect Submitted By: Name of the tester who detected/reported the bug.
6. Date of Submission: Date at which the bug was detected and reported.
7. Build No.: Number of test runs required.
8. Version No.: The version information of the software application in which the bug was
detected and fixed.
9. Assigned To: Name of the developer who is supposed to fix the bug.
10. Severity: Degree of severity of the defect.
11. Priority: Priority of fixing the bug.
 12. Status: This field displays current status of the bug.

The contents of a bug well explain all the above mentioned things.

Reporting and Rework

Testing is an iterative process. The bug once reported and as the development team fixes the
bug, it has to undergo the testing process again to assure that the bug found is resolved.
Regression testing has to be done. Once the Quality Analyst assures that the product is ready,
the software is released for production. Before release, the software has to undergo one more
round of top level testing. Thus testing is an ongoing process.

Final Testing and Implementation

This phase focuses on the remaining levels of testing, such as acceptance, load, stress,
performance and recovery testing. The application needs to be verified under specified
conditions with respect to the SRS. Various documents are updated and different matrices for
testing are completed at this stage of the software testing life cycle.

Post Implementation
Once the tests are evaluated, the recording of errors that occurred during various levels of the
software testing life cycle, is done. Creating plans for improvement and enhancement is an
ongoing process. This helps to prevent similar problems from occuring in the future projects. In
short, planning for improvement of the testing process for future applications is done in this
phase.