SOFTWARE TESTING

UNIT- 1 [PRINCIPLES OF TESTING]

SOFTWARE TESTING:
 The process of evaluating and verifying that a software product or application
does what it is supposed to do is called software testing.

 Benefits of testing:
 prevent bugs
 reduce development costs
 improving performance.
A TEST IN TIME!
 Defects in a product can come from any phase of software development

[requirements, design, development etc.]

 There could have been errors while gathering initial requirements.

 If a wrong or incomplete requirement forms the basis for design and

development of the product, then the functionality can never be realized

correctly in the eventual product.
 Similarly, when a product design which forms the basis of product

development (coding) is faulty, then the code that realizes the faulty design will
also not meet the requirements.
 Thus, it is essential to catch and correct defects in all phases.

COST IMPLICATIONS:
 If during requirements capture, some requirements are erroneously captured

and the error is not detected until the product is delivered to the customer, the
organisation incurs the expenses for:
 Performing a wrong design based on wrong requirement.

 Transforming the wrong design into wrong code during the coding phase

 Testing to make sure the product compiles with the (wrong) requirement.

 Releasing the product with wrong functionality.

[How defects from early phases added to the cost]

When an erroneous product reaches the customer after the testing phase, the
customer may incur a potential downtime that result in the loss of productivity
or business.
This in turn would reflect as a loss of goodwill to the software product
organisation.
On top of this loss, an organisation would redo all steps in software
development in order to rectify the problem.
The cost of defect is compounded depending on the delay in detecting the
defect.
Hence, smaller the lag time between defect injection and defect detection,
lesser are unnecessary costs. Thus, it becomes essential to capture the defects
as soon as possible.
 [Compounding effect of defects on software costs]

THE CAT AND THE SAINT

[Understanding why testing is needed?]
 “Why one tests” is as important as “what to test” and “how to test”

 Testing requires analysing and understanding what you are trying to test,
knowing what the correct outcome is, and why you are performing any test.

 If tests carried out without understanding why the test is done, this will end up
in running inappropriate tests that do not address what the product should do.
 It may even turn out that the product is modified to make sure the tests are
running successfully, even if the product does not meet customer requirements.

 Understanding the rationale of why certain functionalities are tested leads to

different types of tests like White Box testing, Black Box testing etc.

 White Box Testing – To check the various paths in the code and make sure
they are exercised correctly.
 Black Box Testing - Knowing the external functionality of what the product
should do.

 Integration Testing – Used to make sure that the different components fit
together.
 Internationalization Testing – to ensure that the product works with multiple
languages found in different parts of the world.
 Regression Testing – to ensure that the changes work as designed and do not
have any unintended side effects.

TEST THE TESTS FIRST!

 “A defective test is more dangerous than a defective product”.
 Tests are also artifacts produced by human beings, much as programs and
documents are.
 It can not be assumed that the tests will be perfect.

 It is important to make sure that the tests themselves are not faulty before
getting started to use.
 One way of making sure that the tests are tested is to document the inputs and
expected outputs for a given test and validate this description by an expert or
counter-checking this by some means outside the test themselves.

 By comparing this “known correct results” with result produced by the

product, the confidence level of the test and the product can be increased.

THE POLICEMEN ON THE BRIDGE:

 “Prevention is better than cure – the horizon may be extended much

farther”
 Testers are probably best equipped to know the problems that the customer

may encounter.
 It may not be possible for the testers themselves to carry out preventive action.

 Testers would have to work with development engineers to make sure that the

root cause of the defects are addressed.

  The testers should not feel that by eliminating the problems totally their jobs

are at stake.
 Their careers can be enriching and beneficial to the organisation if they harness

their defect detection experience and transform some of it to defect prevention

initiatives.
 Defect prevention is a part of a tester’s job.

 A career of a tester can be enriching and rewarding, if defect prevention and

defect detection activities are balanced.

PHASES OF SOFTWARE PROJECT

A software project is made up of series of phases. Broadly, most of the
software projects comprise of the following phases:
Requirements gathering and analysis
Planning
Design
Development or coding
Testing
Deployment and maintenance

REQUIREMENTS GATHERING AND ANALYSIS:

 During requirements gathering, the specific requirements of the software to be
built are gathered and documented.
 If the software is bespoke software, then there is a single customer who can
give all these requirements.

 If the software is a general-purpose software, then a product marketing team

within the software product organisation specifies the requirements by
aggregating the requirements of multiple potential customers.
 It is important to ensure that the right requirements are captured at every stage.
  The requirements gets documented in the form of a System Requirements
Specification (SRS) document.
 This document acts as a bridge between the customer and the designers
chartered to build the product.
PLANNING:
 The purpose of planning phase comes with a schedule, the scope, and resource

requirements for a release.

 A plan explains how the requirements will be met and by which time.

 It needs to take into account the requirements- what will be met and what will

not be me.
 The planning phase is applicable for both development and testing activities.

 At the end of this phase, both project plan and test plan documents are

delivered.

DESIGN:
 The purpose of design phase is to figure out how to satisfy the requirement
enumerated in the System Requirements Specification [SRS] document.
 It produces the representation that will be used by development phase.
 This representation should serve two purposes.

 First, from this representation, it should be possible to verify all the

requirements are satisfied.
 Second, this representation should give sufficient information for the
development phase to proceed with coding and implementation of the system.
 Design is usually split into two levels:
1. High-level design

2. Low-level design (or) detailed design

  The design step produces the System Design Description (SDD) document
that will be used by development teams to produce the programs that realize
the design.

DEVELOPMENT OR CODING:
 Design acts as a blueprint for the actual coding to proceed.

 This development or coding phase comprises coding the programs in chosen

programming language.
 It produces the software that meets the requirements the design was meant to

satisfy.
 This phase also involves the creation of product documentation.

TESTING:
 As the program are coded, they are also tested.

 In addition, after coding is complete, the product is subjected to testing.

 Testing is the process of exercising the software product in pre-defined ways to

check if the behaviour is same as the expected behaviour.

 By testing the software, an organisation identifies and removes as many defects

as possible before shipping it out.

DEPLOYMENT AND MAINTENANCE:
Once the product is tested, it is given to the customers who deploy it their
environments.

As the users start using the product in their environments, they may observe
discrepancies between the actual behaviour of the product and what they were
given to expect.

Such discrepancies could end up as product defects, which need to be

corrected.
 The product now enters into maintenance phase, wherein the product is
maintained or changed to satisfy the changes that arise from customer
expectations, environmental changes etc.

Maintenance is made up of:

corrective maintenance – fixing customer-reported problem
adaptive maintenance – making the software run in new version of
operating system or database
preventive maintenance – changing the application code to avoid
potential security hole in an operating system code.

QUALITY, QUALITY ASSURANCE AND QUALITY CONTROL

 A software product is designed to satisfy certain requirements of a given
customer(or a set of customers).

 Requirements get translated into software features, each feature being designed
to meet one or more of the requirements.
 For each such feature, the expected behaviour is characterized by a set of test
cases. Each test case is further characterized by:
 The environment under which the test case is to be executed.
 Inputs that should be provided for that test case.
 How these inputs get processed.
 What changes should be produced in the internal state or environment.
 What outputs should be produced.

 The actual behaviour of a given software for a given test case, under given set
of inputs, in a given environment, and in internal state is characterized by:
 How these inputs actually get processed.
  What changes are actually produced in the internal state or environment
 what outputs are actually produced.

 If the actual behaviour and the expected behaviour are identical in all their
characteristics, then the test case is said to passed.
 If not, the given software is said to have defect on that test case.

 There are two ways to increase the chances of product meeting the
requirements expected of it. They are:
1. Quality Control

2. Quality Assurance

QUALITY:
Quality is meeting the requirements expected of the software, consistently and
predictably.
QUALITY CONTROL:
It attempts to build a product, test it for expected behaviour after it is built, and
if the expected behaviour is not the same as actual behaviour of the product,
fixes the product as is necessary and rebuilds the product.
This iteration is repeated till the expected behaviour of the product matches
with actual behaviour for the scenarios tested.
Thus, Quality Control is Defect- detection and defect- correction oriented,
and works on product rather than process.

The responsibilities of quality control is usually localized to quality control

team.

QUALITY ASSURANCE:
 It attempts defect prevention by concentrating on the process of producing the
product rather than working on defect- detection/correction after the product is
built.
The approach of quality assurance is reviewing the design before the product is
built and correct the design errors in the first place.
To ensure the production of a better code, a quality assurance process may
mandate coding standards to be followed by all programmers.
Quality Assurance normally tends to apply to all products that use process.
Since, it continues throughout the life of product, it is everybody’s
responsibility. Hence, it is a staff function.

Quality Assurance Quality Control

Concentrates on process of producing the Concentrates on specific products.

products.
Defect – prevention oriented Defect-detection and defect – correction
oriented
Usually done through out the life cycle Usually done after the product is built

This is usually a staff function This is usually a line function

Examples: reviews and audits Examples: software testing at various

levels

TESTING, VERIFICATION AND VALIDATION

TESTING:
 "Testing" is the phase that follows coding and precedes deployment.

 Testing is traditionally used to mean testing of the program code.

 However, coding is a downstream activity, as against requirements and design

that occur much earlier in a project life cycle.
  Given that the objective of a software project is to minimize and prevent

defects, testing of program code alone is not sufficient.

 Testing increases the chances of a product or service meeting the customer's

requirements.
 While testing does not guarantee zero defects, effective testing certainly

increases the chances of customer acceptance of the software.

 The purpose of testing is to uncover defects in the system (and to have

someone fix the defects).

 Testing is done by a set of people within a software product (or service)

organization whose goal and charter is to uncover the defects in the product
before it reaches the customer.
VERIFICATION:
 The process of evaluating a system or component to determine whether the
products of a given phase satisfy the conditions imposed at the start of that
phase is called verification.

 It is a process of checking documents, design, code, and program in order to

check if the software has been built according to the requirements or not.
 The main goal of verification process is to ensure quality of software
application, design, architecture etc.
 The verification process involves activities like reviews, walk-throughs and
inspection.

 Verification takes care of activities to focus on the question "Are we building

the product right?"
 To build the product right, certain activities/conditions/procedures are imposed
at the beginning of the life cycle. These activities are considered "proactive"
as their purpose is to prevent the defects before they take shape.
VALIDATION:
 The process of evaluating a system or component during or at the end of
development process to determine whether it satisfies specified requirements.

 It is a dynamic mechanism of testing and validating if the software product

actually meets the exact needs of the customer or not.

 The process helps to ensure that the software fulfils the desired use in an
appropriate environment.
 The validation process involves activities like unit testing, integration testing,
system testing and user acceptance testing.

 Validation takes care of a set of activities to address the question "Are we

building the right product?"
 To build the right product, certain activities are carried out during various
phases to validate whether the product is built as per specifications. These
activities are considered "reactive" as their purpose is to find defects that
affect the product and fix them as soon as they are introduced.

Quality Assurance = Verification

Quality Control = Validation, testing

PROCESS MODEL TO REPRESENT DIFFERENT PHASES

 A process model is a way to represent any given phase of software
development that effectively builds in the concepts of validation and
verification to prevent and minimize the delay between defect injection and
defect detection (and eventual correction).

 In this model, each phase of a software project is characterized by the

following.
 Entry criteria: specifies when that phase can be started. Also included are
the inputs for the phase.
 Tasks, or steps that need to be carried out in that phase, along with
measurements that characterize the tasks.
 Verification: specifies methods of checking that the tasks have been carried
out correctly.
 Exit criteria: stipulates the conditions under which one can consider the
phase as done. Also included are the outputs for only the phase.
 This model is known as the Entry Task Verification eXit or ETVX model
 It offers several advantages for effective verification and validation. They are:
1. Clear entry criteria make sure that a given phase does not start

prematurely.
2. The verification for each phase (or each activity in each phase) helps

prevent defects, or at least, minimizes the time delay between defect

injection and defect detection.
3. Documentation of the detailed tasks that comprise each phase reduces

the ambiguity in interpretation of the instructions and thus minimizes

the variations that can come from repeated executions of these tasks by
different individuals.
4. Clear exit criteria provide a means of validation of the phase.
 SOFTWARE DEVELOPMENT LIFE CYCLE [SDLC] MODELS

A software life cycle model is a descriptive representation of the software

development cycle.
SDLC models might have a different approach but the basic phases and activity
remain the same for all the models.
A Life Cycle model describes how the phases combine together to form a
complete project or life cycle.

WATERFALL MODEL:
Waterfall model is the very first model that is used in SDLC. It is also known
as the linear sequential model.
 In this model, the outcome of one phase is the input for the next phase.
Development of the next phase starts only when the previous phase is
complete.

First, Requirement gathering and analysis is done. Once the requirement is

freeze then only the System Design can start. Herein, the SRS document
created is the output for the Requirement phase and it acts as an input for
the System Design.
In System Design Software architecture and Design, documents which act
as an input for the next phase are created i.e. Implementation and coding.

In the Implementation phase, coding is done and the software developed is

the input for the next phase i.e. testing.
In the testing phase, the developed code is tested thoroughly to detect the
defects in the software. Defects are logged into the defect tracking tool and
are retested once fixed. Bug logging, Retest, Regression testing goes on
until the time the software is in go-live state.

In the Deployment phase, the developed code is moved into production

after the sign off is given by the customer

Any issues in the production environment are resolved by the developers

which come under maintenance.

Advantages of the Waterfall Model:

Waterfall model is the simple model which can be easily understood and is the
one in which all the phases are done step by step.
Deliverables of each phase are well defined, and this leads to no complexity
and makes the project easily manageable.
Disadvantages of Waterfall model:
Waterfall model is time-consuming & cannot be used in the short duration
projects as in this model a new phase cannot be started until the ongoing phase is
completed.
Waterfall model cannot be used for the projects which have uncertain
requirement or wherein the requirement keeps on changing. Because this model
expects the requirement to be clear in the requirement gathering and analysis phase
itself and any change in the later stages would lead to cost higher as the changes
would be required in all the phases.

V-SHAPED MODEL:
 V- Model is also known as
Verification and Validation Model.
 In this model Verification & Validation goes hand in hand i.e. development and

testing goes parallel.

 V model and waterfall model are the same except that the test planning and

testing start at an early stage in V-Model.

a) Verification Phase:
(i) Requirement Analysis:
In this phase, all the required information is gathered & analysed. Verification
activities include reviewing the requirements.
(ii) System Design:
Once the requirement is clear, a system is designed i.e. architecture,
components of the product are created and documented in a design document.
(iii) High-Level Design:
High-level design defines the architecture/design of modules. It defines the
functionality between the two modules.

(iv) Low-Level Design:

Low-level Design defines the architecture/design of individual components.
(v) Coding:
Code development is done in this phase.
b) Validation Phase:
(i) Unit Testing:
 Unit testing is performed using the unit test cases that are designed and is done

in the Low-level design phase.

 Unit testing is performed by the developer itself.

 It is performed on individual components which lead to early defect detection.

(ii) Integration Testing:

Integration testing is performed using integration test cases in High-level
Design phase.
Integration testing is the testing that is done on integrated modules.
It is performed by testers.

(iii) System Testing:

 System testing is performed in the System Design phase.
  In this phase, the complete system is tested i.e. the entire system functionality

is tested.
(iv) Acceptance Testing:
Acceptance testing is associated with the Requirement Analysis phase and is
done in the customer’s environment.

Advantages of V – Model:
 It is a simple and easily understandable model.
 V –model approach is good for smaller projects wherein the requirement is
defined and it freezes in the early stage.
 It is a systematic and disciplined model which results in a high-quality product.
Disadvantages of V-Model:
V-shaped model is not good for ongoing projects.
Requirement change at the later stage would cost too high.

[V-model]