UNIT-4

SOFTWARE
TESTING
 What is Testing?

• Although software testing is itself an expensive

activity, yet launching of software without testing
may lead to cost potentially much higher than that of
testing, specially in system where human safety is
involved.
• A more appropriate definition is-
“ Testing is the process of executing a program with
the intent of finding errors “.
• In the software life cycle, the earlier the errors are
discovered and removed, the lower is the cost of
their removal.
 Who should do the testing?
• The testing requires the developers to find
errors from their software.
• It is very difficult for software developer to
point out errors from own creations.
• Many organizations have made a distinction
between development and testing phase by
making different people responsible for each
phase.
 Testing Objectives
• Software Testing has different objectives. The
major objectives of Software testing are as
follows:
1. Finding defects which may get created by the
programmer while developing the software.
2. To make sure that the end result meets the user
requirements.
3. To ensure that it satisfies the SRS that is System
Requirement Specifications.
4. To gain the confidence of the customers by
 Principles of Software Testing
1. Testing shows presence of defects.
2. Exhaustive testing is impossible
3. Early testing
4. Defect clustering
5. The Pesticide Paradox
6. Testing is context dependent
7. Absence of errors fallacy.
 Other principles are-
• Testing must be done by an independent
party.
• Assign best personnel to the task.
• Test for invalid and unexpected input
conditions as well as valid conditions.
• Keep software static during test.
• Provide expected test results if possible.
1. TESTING SHOWS THE PRESENCE OF BUGS
Testing an application can only reveal that one or more defects exist in the application,
however, testing alone cannot prove that the application is error free. Therefore, it is
important to design test cases which find as many defects as possible.

2. EXHAUSTIVE TESTING IS IMPOSSIBLE

Unless the application under test has a very simple logical structure and limited input, it is
not possible to test all possible combinations of data and scenarios. For this reason, risk
and priorities are used to concentrate on the most important aspects to test.

3. EARLY TESTING
The sooner we start the testing activities the better we can utilize the available time. As
soon as the initial products, such the requirement or design documents are available, we
can start testing. It is common for the testing phase to get squeezed at the end of the
development lifecycle, i.e. when development has finished, so by starting testing early, we
can prepare testing for each level of the development lifecycle.
Another important point about early testing is that when defects are found earlier in the
lifecycle, they are much easier and cheaper to fix. It is much cheaper to change an
incorrect requirement than having to change a functionality in a large system that is not
working as requested or as designed!
4. DEFECT CLUSTERING
During testing, it can be observed that most of the reported defects are related to small number of modules
within a system. i.e. small number of modules contain most of the defects in the system. This is the
application of the Pareto Principle to software testing: approximately 80% of the problems are found in 20%
of the modules.

5. THE PESTICIDE PARADOX

If you keep running the same set of tests over and over again, chances are no more new defects will be
discovered by those test cases. Because as the system evolves, many of the previously reported defects will
have been fixed and the old test cases do not apply anymore. Anytime a fault is fixed or a new functionality
added, we need to do regression testing to make sure the new changed software has not broken any other
part of the software. However, those regression test cases also need to change to reflect the changes made
in the software to be applicable and hopefully fine new defects.

6. TESTING IS CONTEXT DEPENDENT

Different methodologies, techniques and types of testing is related to the type and nature of the
application. For example, a software application in a medical device needs more testing than a games
software. More importantly a medical device software requires risk based testing, be compliant with
medical industry regulators and possibly specific test design techniques. By the same token, a very popular
website, needs to go through rigorous performance testing as well as functionality testing to make sure the
performance is not affected by the load on the servers.

7. ABSENCE OF ERRORS FALLACY

Just because testing didn’t find any defects in the software, it doesn’t mean that the software is ready to be
shipped. Were the executed tests really designed to catch the most defects? or where they designed to see
if the software matched the user’s requirements? There are many other factors to be considered before
making a decision to ship the software.

If the system built is unusable and does not fulfil the user’s needs and expectations then finding and fixing
defects does not help.
• Other principles to note are:

– Testing must be done by an independent party.

Testing should not be performed by the person or team that developed
the software since they tend to defend the correctness of the program.
– Assign best personnel to the task.
Because testing requires high creativity and responsibility only the best
personnel must be assigned to design, implement, and analyze test
cases, test data and test results.
– Test for invalid and unexpected input conditions as well as valid conditions.
The program should generate correct messages when an invalid test is
encountered and should generate correct results when the test is valid.
– Keep software static during test.
The program must not be modified during the implementation of the
set of designed test cases.
– Provide expected test results if possible.
A necessary part of test documentation is the specification of expected
results, even if providing such results is impractical
 Some Terminologies
Error: It is the human action that produces the
incorrect result that produces a fault.

Bug: The presence of error at the time of

execution of software.

Fault: State of software caused by an error.

Failure: Deviation of the software from its

expected result. It is a failure.
 Software Testing Process
The most widely used testing process(levels)
consists of three stages that are as follows:

1. Unit Testing
2. Integration Testing
3. System Testing
 Unit Testing
• Unit testing is a method by which individual units of source
code are tested to determine if they are fit for use.
• A unit is the smallest testable part of an application like
functions, classes, procedures, interfaces.
• Unit tests are basically written and executed by software
developers to make sure that code meets its design and
requirements and behaves as expected.
• The goal of unit testing is to segregate each part of the program
and test that the individual parts are working correctly.
• This means that for any function or procedure when a set of
inputs are given then it should return the proper values. It
should handle the failures gracefully during the course of
execution when any invalid input is given.
 Advantages of Unit Testing
1. Issues are found at early stage. Since unit testing are carried out by
developers where they test their individual code before the integration.
Hence the issues can be found very early and can be resolved then and
there without impacting the other piece of codes.

2. Unit testing helps in maintaining and changing the code. This is possible by
making the codes less interdependent so that unit testing can be executed.
Hence chances of impact of changes to any other code gets reduced.

3. Since the bugs are found early in unit testing hence it also helps in
reducing the cost of bug fixes. Just imagine the cost of bug found during
the later stages of development like during system testing or during
acceptance testing.

4. Unit testing helps in simplifying the debugging process. If suppose a test

fails then only latest changes made in code needs to be debugged.
 Component Testing
• It is also called as module testing.
• The basic difference between the unit testing and
component testing is in unit testing the developers
test their piece of code but in component testing the
whole component is tested.
• There are problems associated with testing a module
in isolation.
• How do we run a module without anything to call it,
to be called by it or, possibly, to output intermediate
values obtained during execution?
• Component testing may be done in isolation from rest of the system depending
on the development life cycle model chosen for that particular application.

• In such case the missing software is replaced by Stubs and Drivers and simulate
the interface between the software components in a simple manner.

• Let’s take an example to understand it in a better way. Suppose there is an

application consisting of three modules say, module A, module B and module C.
The developer has developed the module B and now wanted to test it. But in
order to test the module B completely few of it’s functionalities are dependent
on module A and few on module C. But the module A and module C has not
been developed yet. In that case to test the module B completely we can replace
the module A and module C by stub and drivers as required.
 What Is Integration Testing?

Integration testing ("I&T") is the phase in software

testing in which individual software modules are
combined and tested as a group.
It occurs after unit testing and before system testing.
Integration testing takes as its input modules that
have been unit tested, groups them in larger
aggregates, applies tests defined in an integration test
plan to those aggregates, and delivers as its output
the integrated system ready for system testing.
 Integration Testing Strategy
• The entire system is viewed as a collection of
subsystems.
• The Integration testing strategy determines the
order in which the subsystems are selected for
testing and integration-
– Big bang integration (Non incremental)
– Incremental integration
– Top down integration
– Bottom up integration
– Sandwich testing
 Big Bang Integration
• All the components of the system are
integrated & tested as a single unit.
• Instead of integrating component by
component and testing, this approach waits
till all components arrive and one round of
integration testing is done.
• It reduces testing effort, and removes
duplication in testing.
 A
Big-Bang Approach
B C D
Test A

Test B
E F G
Test C
Test
Test D A, B, C, D,
E, F, G
Test E

Test F

Test G
 System Testing
• System testing is most often the final test to
verify that the system to be delivered meets
the specification and its purpose.
• It tests both functional & non-functional
aspects of the product.
• It is started once unit testing , component
testing & integration testing are completed.
• System testing is carried out by specialists
testers or independent testers
 System Testing
• It is performed on the basis of written test
cases according to information collected from
SRS & detailed design documents.
• It ensures that the product is ready for moving
to the user acceptance test level.
• This the last chance for the test team to find
any remaining product defects before the
product is handed over to the customer.
 WHY System Testing?

• Bring in customer perspective

• Build confidence in the product
• Analyze & reduce risk of releasing the product
• Ensure product is ready for acceptance testing
 Types of System Testing
There are essentially three main kinds of
system testing –

1. Alpha Testing
2. Beta Testing
3. Acceptance Testing
 Alpha Testing
• This test takes place at the developer’s site.
• Alpha testing is testing of an application when development is
about to complete. Minor design changes can still be made as a
result of alpha testing.
• Alpha testing is typically performed by a group that is
independent of the design team, but still within the company,
e.g. in-house software test engineers, or software QA engineers.
• Alpha testing is final testing before the software is released to
the general public. It has two phases:
– In the first phase of alpha testing, the software is tested by in-house
developers. They use either debugger software, or hardware-assisted
debuggers. The goal is to catch bugs quickly.
– In the second phase of alpha testing, the software is handed over to
the software QA staff, for additional testing in an environment that is
similar to the intended use.
 Beta Testing
• It takes place at customer’s site. It is the system testing
performed by a selected group of friendly customers. It sends
the system to users who install it and use the software in testing
mode., that is not live usage.
• A beta test is the second phase of software testing in which a
sampling of the intended audience tries the product out. (Beta is
the second letter of the Greek alphabet.) Originally, the
term alpha test meant the first phase of testing in a software
development process. The first phase includes unit testing,
component testing, and system testing. Beta testing can be
considered “pre-release” testing.
• The goal of beta testing is to place your application in the hands
of real users outside of your own engineering team to discover
any flaws or issues from the user’s perspective that you would not
want to have in your final, released version of the application.
Differences between Alpha and Beta Testing

Alpha Testing Beta Testing

It is done at developer’s site. It is done at one or more customer’s site.
It is conducted in a controlled It is conducted in an environment that
environment with developer. cannot be controlled by the developer.

During alpha testing, developers records During beta testing, customer records all
errors and usage problems. problems and submits report to the
developer for modifications at regular
intervals.
 Acceptance Testing
• It is a type of testing carried out in order to verify if the
product is developed as per the standards and specifies
criteria and meets all the requirements specified by
customer.
• Thus, acceptance testing is the system testing to
determine whether to accept or reject the delivery of the
system.
• The goal of acceptance testing is to establish confidence
in the system.
• Acceptance testing is most often focused on a validation
type testing.
 Regression Testing
• It is a type of testing carried out to ensure that
changes made in the fixes are not impacting
the previously working functionality.
• The main aim of regression testing is to make
sure that changed component is not impacting
the unchanged part of the component.
• It means re-testing an application after its
code has been modified to verify that it still
functions correctly.
 Software Testing Strategies
• It provides a road map for the software developers,
quality assurance organizations and the customer.
• Common characteristics of software testing
strategies include the following:
– Testing begins at the module level and works outward
toward the integration of the entire system.
– Different testing techniques are appropriate at different
times.
– Testing is conducted by developers and for large
projects, by an independent test group.
 Types of Testing Strategy
1. Top down Strategy
It is an approach where modules are developed
and tested starting at the top level of the
programming hierarchy and continuing with the
lower levels.
2. Bottom up Strategy
It is opposite of top down method. This process
starts with building and testing the low level
modules first, working its way up the hierarchy.
 White Box testing
• White Box testing is based on the inner
workings of an application and revolves around
internal testing. The term "whitebox" was used
because of the see-through box concept. The
clear box or whitebox name symbolizes the
ability to see through the software's outer shell
(or "box") into its inner workings.
• One of the basic goal of white box testing is to
verify a working flow for an application.
 White Box Testing
• White-box testing is also called as:
-Structural testing
-Code Based Testing
-Clear testing
-Open testing
- Glass box testing
 How do you perform White Box Testing?

• Testers divided it into two basic steps:

STEP 1) UNDERSTAND THE SOURCE CODE

Step 2) CREATE TEST CASES AND EXECUTE
 STEP 1) UNDERSTAND THE SOURCE CODE

• The tester must be very knowledgeable in the

programming languages used in the
applications they are testing. Also, the testing
person must be highly aware of secure coding
practices.
 Step 2) CREATE TEST CASES AND EXECUTE

• Writing more code to test the application's

source code. The tester will develop little tests
for each process or series of processes in the
application.
What do you verify in White Box Testing ?

• Basically verify the security holes in the code.

• Verify the broken or incomplete paths in the code.
• Verify the flow of structure mention in the
specification document
• Verify the Expected outputs
• Verify the all conditional loops in the code to check
the complete functionality of the application.
• Verify the line by line or Section by Section in the
code.
 White-box Testing Techniques
• It examines source code and analyze what is present
in the code.
• Structural testing doesn’t expose errors of code
omission but can estimate the test suite adequacy in
terms of code coverage i.e execution of components
by the test suite or its fault-finding ability.
• The following are some important techniques of
white-box testing:
A. Basis Path Testing
B. Structural Testing
C. Logic Based Testing
 A. Basis Path Testing
• It allows the design and definition of a basis
set of execution paths. The test cases created
from the basis path allow the program to be
executed in such a way as to examine each
possible path through the program by
executing each statement at least once.
• The following steps can be applied to derive the
basis set:
1. Using the design or code as a foundation, draw a
corresponding flow graph.
2. Determine the cyclomatic complexity of the
resultant flow graph.
3. Determine the basis set of linearly independent
paths.
4. Prepare test cases that will force execution of each
path in the basis set.
 B. Structural Testing
• It is a broaden testing coverage and improve
quality of white-box testing.
• The following are some important types of
structural testing:
1. Statement coverage testing
2. Branch coverage testing
3. Condition coverage testing
4. Path coverage testing
5. Data flow based testing
 C. Logic Based Testing
• It is used when the input domain and resulting
processing are amenable to a decision table
representation.
• The following steps are applied:
– List all actions that can be associated with a specific
algorithm.
– List all conditions
– Associate specific conditions with specific actions
eliminating impossible combination of conditions.
– Define rules by indicating what action occurs for a set of
conditions.
 WHITE BOX TESTING ADVANTAGES

• Testing can be commenced at an earlier stage.

One need not wait for the GUI to be available.
• Testing is more thorough, with the possibility of
covering most paths.
• As the tester has knowledge of the source
code, it becomes very easy to find out which
type of data can help in testing the application
effectively.
• It is easy to automate.
 WHITE BOX TESTING DISADVANTAGES

• Due to the fact that skilled tester is needed to

perform white box testing, the costs are
increased.
• The tests focus on the software as it exists, and
missing functionality may not be discovered.
• Test script maintenance can be a burden if the
implementation changes too frequently.
• It is suitable for small projects.
 Black Box Testing

This method is named so because the software

program, in the eyes of the tester, is like a black
box; inside which one cannot see.
A black-box test takes into account only the input and output of the
s/w without regard to the internal code of the program .
 BLACK BOX TESTING
• Also called functional testing and behavioral
testing.
• It focuses on determining whether or not a
program does what it is supposed to do based on
its functional requirements.
• It attempts to find errors in the external behavior
of the code in the following categories :
(1) incorrect or missing functionality;
(2) Interface errors;
(3) Errors in data structures used by interfaces;
(4) Behavior or performance errors;
 Why Black Box Testing?
• It helps in identifying any incomplete &
inconsistent requirement.
• It addresses the stated req. as well as implied
req.
• It encompasses the end user perspective.
• It handles valid & invalid inputs.
• Can be started early in the cycle as soon as the
specifications are ready.
 BLACK BOX TESTING ADVANTAGES

• Tester requires no knowledge of

implementation and programming language
used.
• Reveals any ambiguities and inconsistencies in
the functional specifications.
• Efficient when used on large systems.
• Tests are done from user’s point of view.
• Test cases can be designed as soon as the
specifications are complete.
 BLACK BOX TESTING DISADVANTAGES

• Only a small number of possible inputs can be

tested and many program paths will be left
untested.
• Without clear specifications, which is the
situation in many projects, test cases will be
difficult to design.
• Tests can be redundant if the software
designer/ developer has already run a test
case.
 Comparison Between Black-box and White-box
Testing
Criteria Black Box Testing White Box Testing

White Box Testing is a software

Black Box Testing is a software
testing method in which the
testing method in which the
internal structure/ design/
Definition internal structure/ design/
implementation of the item
implementation of the item being
being tested is known to the
tested is NOT known to the tester
tester.
Mainly applicable to higher levels of Mainly applicable to lower levels
Levels Applicable To testing: Acceptance Testing of testing: Unit Testing
System Testing Integration Testing

Scope It is suitable for large projects It is suitable for small projects.

Programming Knowledge Not Required Required

Implementation
Not Required Required
Knowledge
Basis for Test Cases Requirement Specifications Detail Design

This is the least time consuming The most exhaustive and time
Time
and exhaustive consuming testing.