Testing

UNIT-4
 Testing

• Software testing is the process of testing the software

product.
• Testing strategy provides a framework or set of activities
which are essential for the success of the project. they
may include planning, designing of test cases, execution
of program with test cases, interpretation of the outcome
and finally collection and management of data.
• Testing is the process of executing a program with the
intent of finding errors.
• Effective software testing will contribute to the delivery of
high quality software product, more satisfied users, lower
maintenance cost, more accurate and reliable result.
• Hence software testing is necessary and important
activity of software development process.
 Why should We Test ?
• 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 systems where human
safety is involved.
• 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
• Testing requires the developers to find
errors from their software.
• It is 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.
 What should We Test ?
• We should test the program’s responses to every
possible input. It means, we should test for all
valid and invalid inputs.
• Execute all the possible paths of the program. a
program path can be traced through the code
from the start of the program to program
termination two paths differ if the program
execute different statement in each ,or execute
the same statement but in differ order.
 Error, Mistake, Bug, Fault and
Failure
• People make errors. A good synonym is mistake. This
may be a syntax error or misunderstanding of
specifications. Sometimes, there are logical errors.
• When developers make mistakes while coding, we call
these mistakes “bugs”.
• A fault is the representation of an error, where
representation is the mode of expression, such as
narrative text, data flow diagrams, ER diagrams, source
code etc. Defect is a good synonym for fault.
• A failure occurs when a fault executes. A particular fault
may cause different failures, depending on how it has
been exercised.
• Test case: This is the triplet [I,S,O], where I is the data
input to the system, S is the state of the system at which
the data is input, and O is the expected output of the
system.
• Test suite: This is the set of all test cases with which a
given software product is to be tested.
• The set of test cases is called a test suite. Hence any
combination of test cases may generate a test suite.

Test case template

 Test data and test cases
• Test data Inputs which have been
devised to test the system
• Test cases Inputs to test the system and
the predicted outputs from these inputs if
the system operates according to its
specification
 Verification and Validation

• Verification is the process of evaluating a

system or component to determine whether the
products of a given development phase satisfy
the conditions imposed at the start of that phase.
• Validation is the process of evaluating a system
or component during or at the end of
development process to determine whether it
satisfies the specified requirements .
Testing= Verification + Validation
 Levels of Testing
There are 4 levels of testing:

• Unit testing
• Integration testing
• System testing
• Regression testing
 Unit Testing

• Unit testing is the process of testing the smallest part of

a software (like a module or class ) to ensure it works
correctly.
• There are number of reasons in support of unit testing
than testing the entire product.
1. The size of a single module is small enough that we can
locate an error fairly easily.
2. The module is small enough that we can attempt to test it
in some demonstrably exhaustive fashion.
3. Confusing interactions of multiple errors in widely
different parts of the software are eliminated.
• 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?
• In unit testing, sometimes a module depends on other
modules that are not yet developed.
To test properly, we use Stub and Driver.
• A stub is a dummy module that simulates the behavior
of a lower-level module (called function). It is used when:
The called module is not developed yet
• A driver is a dummy program that calls the function to
be tested. It is Used when:The main program is not
developed yet
• A driver module contain the nonlocal data
structures accessed by the module under test,
and would also have the code to call the different
functions of the module with appropriate
parameter values.
• This overhead code, called scaffolding
represents effort that is import to testing, but
does not appear in the delivered product as
shown in Fig.
Scaffolding required testing a
program unit (module)
 Live Project: Online Shopping System

• Imagine you are developing an online

shopping application with these
modules:
• Order Module (places order)
• Payment Module (handles payment)
• Delivery Module (ships product)
 1. Stub (Simple Concept)
Situation:
•You want to test the Order Module, but the Payment Module is
not ready yet
•What you do:
•You create a fake(called) Payment Module that gives a fixed
response
•Example:
•Order Module asks → “Payment successful?”
•Stub (fake module) replies → “Yes, successful”
Meaning:
•You are not testing real payment
•You are just pretending payment works
•This fake(called) module is called a Stub
 2. Driver (Simple Concept)
•Situation:
•You want to test the Payment Module, but the Order Module (main
system) is not ready
•What you do:
•You create a dummy program (calling module)that calls the Payment
Module
Example:
•Driver acts like a customer
•It sends request → “Process payment of ₹1000”
•Payment module gives result → “Success”
•Meaning:
•You are testing Payment Module directly
•Driver acts like a temporary main program
 Integration Testing
• The purpose of unit testing is to determine that
each independent module is correctly
implemented. This gives little chance to
determine that the interface between modules is
also correct, and for this reason integration
testing must be performed.
• Focuses on interaction of modules in a
subsystem
• Unit tested modules combined to form
subsystems
• Test cases to “exercise” the interaction of
modules in different ways
 Approaches to integration testing
• Top-down testing
– starts with the main routine and one or two subordinate
routines in the system.
– After the top-level ‘skeleton’ has been tested, the immediately
subroutines of the ‘skeleton’ are combined with it and tested.
– Top-down integration testing approach requires the use of
program stubs to simulate the effect of lower-level routines
that are called by the routines under test
• Bottom-up testing
– each subsystem is tested separately and then the full
system is tested
– Primary purpose of testing each subsystem is to test the
interfaces among various modules making up the
subsystem. Both control and data interfaces are tested
– Integrate individual components in levels until the complete
system is created

• In practice, most integration involves a combination of these strategies

 System Testing

• System tests are designed to validate a fully developed

system to assure that it meets its requirements. There
are essentially three main kinds of system testing:
Alpha Testing. Alpha testing refers to the system testing
carried out by the test team within the developing
organization.
Beta testing. Beta testing is the system testing
performed by a select group of friendly customers.
Acceptance Testing. Acceptance testing is the system
testing performed by the customer to determine whether
he should accept the delivery of the system.
Attributes of software to be tested during
system testing
 Approaches of Testing
• Black Box Testing
• White Box Testing
 Functional Testing or black-box testing or
behavioural testing

• In the black-box testing approach, test cases are

designed using only the functional specification of the
software, i.e. without any knowledge of the internal
structure of the software.
• In black-box testing, the tester only knows the inputs that
can be given to the system and what output the system
should give.
• It Involves only observation of the output for certain input
values, there is no attempt to analyze the code which
produce the output.
• An approach to testing where the program is considered
as a ‘black-box' because internal structure of the code is
to be ignored
• In the black-box testing, test cases are designed from an
examination of the input/output values only and no knowledge
of design, or code is required.
 Black-box testing
The following are the main approaches to designing black box test
cases.
1. Boundary value analysis
2. Equivalence class portioning
3. Cause Effect graphing
 Boundary value analysis
• Test cases that are close to boundary value condition
have a higher chance of detecting an error.
• Boundary condition means , an input value may be on
the boundary, just below the boundary (upper side) or
just above the boundary (lower side)
• Programmers often fail to see the special processing
required by the input values that lie at the boundary of
the different equivalence classes.
• For example, programmers may improperly use <
instead of <=, or conversely <= for <. Boundary value
analysis leads to selection of test cases at the
boundaries of the different equivalence classes.
• Suppose we have an input variable x with a range from
1-100 the boundary values are 1,2,99 and 100.
 Boundary value analysis
• Programmers may mistakenly use < instead of <=
• Select test cases at the boundaries of different equivalence
classes.
• If an input condition specifies a range, bounded by values a
and b:
• Test cases should be designed with value a and b, and just
above a just below b.
Example: Integer D with input range [-3, 10],
test values: -3, 10, 9, -2, 0
If an input condition specifies a number values:
• Test cases should exercise minimum and maximum numbers.
• Values just above minimum and below maximum are also to
be tested.
 • Consider a program with two input variables x and y.
These input variables have specified boundaries as:

Hence both the input x and y are bounded by two interval [a,b] and [c,d] respectively. for
input x, we may design test cases with value a and b, just above a and also just below b,
for input y, we may have values c and d ,design just above c and just below d. These
test cases will have more chance to detect an error
• The basic idea of boundary value analysis
is to use input values at their minimum,
just minimum, a nominal value, just below
their their maximum and at their maximum
• Thus for a program of n variable ,boundary
value analysis yields 4n+1 test cases.
 Example
• Consider a program for the determination of the
nature of roots of a quadratic equation. Its input
is a triple of positive integers (say a,b,c) and
values may be from interval [0,100]. The
program output may have one of the following
words.
[Not a quadratic equation; Real roots; Imaginary
roots; Equal roots] Design the boundary value
test cases.
 Equivalence Class Partitioning

• Equivalence Class Partitioning (ECP) is a black-box

testing technique used in software testing to reduce the
number of test cases while still maintaining good coverage.
• In this approach, the domain of input values to a program is
partitioned into a finite number of equivalence classes, so
that if the program works correctly for a value then it will work
correctly for all the other values in that class.
• This partitioning is done such that the behavior of the program
is similar for every input data belonging to the same
equivalence class.
• The main idea behind defining the equivalence classes is that
testing the code with any one value belonging to an
equivalence class is as good as testing the software with any
other value belonging to that equivalence class.
• Equivalence classes for a software can be designed by
examining the input data and output data.
 Equivalence Class Testing
Two steps are required to implementing this method:
1. The equivalence classes are identified by taking each
input condition and partitioning it into valid and invalid
classes. For example, if an input condition specifies a
range of values from 1 to 999, we identify one valid
equivalence class [1<item<999]; and two invalid
equivalence classes [item<1] and [item>999].
2. Generate the test cases using the equivalence classes
identified in the previous step. This is performed by
writing test cases covering all the valid equivalence
classes. Then a test case is written for each invalid
equivalence class so that no test contains more than one
invalid class.
Types of Equivalence Classes
• Valid Equivalence Class → Inputs that
should be accepted
• Invalid Equivalence Class → Inputs that
should be rejected
• E.g. range 0< value<Max specified
– one range is the valid class
– input < 0 is an invalid class
– input > max is an invalid class
 Example
• Consider the program for the determination of
nature of roots of a quadratic equation as
explained in example. Identify the equivalence
class test cases for output and input domains.
Example
 Example
• A system accepts marks between 0 to 100
Step 1: Identify Equivalence Classes

Class Type Input Range Description

Valid Class 0 – 100 Acceptable marks
Invalid Class 1 Less than 0 Negative marks
Invalid Class 2 Greater than 100 Marks above limit
Step 2: Select Test Cases
Instead of testing all values:

Test Case Input Expected Output

TC1 50 Valid
TC2 -5 Invalid
TC3 120 Invalid
Only 3 test cases cover all scenarios instead of testing 0,1,2,...100
 Cause effect graphing
• Cause effect graphing is a set of test case
design technique that provide a concise
representation of logical condition and
corresponding actions
• Cause Effect Graphing Technique
• Consider single input conditions
• do not explore combinations of input
circumstances
Steps
1. Causes & effects in the specifications are identified.
– A cause is a distinct input condition or an equivalence class
of input conditions.
– An effect is an output condition or a system transformation.
2. The semantic content of the specification is analyzed
and transformed into a Boolean graph linking the causes
& effects.
3. The graph is converted in to decision
4. The columns in the decision table are converted into test
cases.
Basic cause effect graph symbols
 Example
“The characters in column 1 must be an A or B. The
character in column 2 must be a digit. In this situation,
the file update is made. If the character in column 1 is
incorrect, message x is issued. If the character in column
2 is not a digit, message y is issued”.
The causes are
• c1: character in column 1 is A
• c2: character in column 1 is B
• c3: character in column 2 is a digit
and the effects are
• e1: update made
• e2: message x is issued
• e3: message y is issued
Cause effect graph
 Example
• If depositing less than Rs. 1 Lakh, rate of
interest:
6% for deposit upto 1 year
7% for deposit over 1 year but less than 3 yrs
8% for deposit 3 years and above
•If depositing more than Rs. 1 Lakh, rate of
interest:
7% for deposit upto 1 year
8% for deposit over 1 year but less than 3 yrs
9% for deposit 3 years and above
Cause-Effect Graph Example
Causes Effects
C1: Deposit<1yr e1: Rate 6%
C2: 1yr<Deposit<3yrs e2: Rate 7%
C3: Deposit>3yrs e3: Rate 8%
C4:Deposit <1 Lakh e4: Rate 9%
C5: Deposit >=1Lakh
Cause-Effect Graph Example
Develop a Decision Table
 CE graphing: Example
• A bank database which allows two commands
– Credit acc# amt
– Debit acc# amt
• Requirements
– If credit and acc# valid, then credit
– If debit and acc# valid and amt less than balance,
then debit
– Invalid command - message
 Example…
• Causes
– C1: command is credit
– C2: command is debit
– C3: acc# is valid
– C4: amt is valid
• Effects
– E1: Print “Invalid command”
– E2: Print “Invalid acct#”
– E3: Print “Debit amt not valid”
– E4: Debit account
– E5: Credit account
• The requirements are that if the command is
credit and the acct_number is valid, then the
account is credited.
• If the command is debit, the [Link] is valid,
and the transaction_amount is valid (less than
the balance), then the account is debited.
• If the command is not valid, the account number
is not valid, or the debit amount is not valid, a
suitable message is generated.
• We can identify the following causes and effects
from these requirements:
Example…
 Decision Table
# 1 2 3 4 5

C1 0 1 x x x
C2 0 x 1 1 x
C3 x 0 1 1 1
C4 x x 0 1 1
E1 1
E2 1
E3 1
E4 1
E5 1
 Example
• Consider the triangle problem specified in the example . Draw the Cause effect graph
and identify the test cases.
• Solution
• The causes are:-
• c1: side x is less than sum of sides y and z
• c2: side y is less than sum of sides x and y
• c3: side z is less than sum of sides x and y
• c4: side x is equal to side y
• c5: side x is equal to side z
• c6: side y is equal to side z
• effects are
• e1: Not a triangle
• e2: Scalene triangle
• e3: Isosceles triangle
• e4: Equilateral triangle
• e5: Impossible stage