Software Testing

Module-3

13/07/2025 1
 Software Testing
 Computer programs are designed and developed by human beings
and hence are prone to errors.
 If unchecked, they can lead to a lot of problems, including social
implications.
 Testing the software becomes an essential part of the software
development lifecycle.
 Carrying out the testing activities for projects has to be practiced
with proper planning and must be implemented correctly.
 Software testing is a critical element of software quality assurance
and represents the ultimate review of specification, design, and
code generation

13/07/2025 2
Software Testing
• Because of human error, There will be a software bug or
fault in the code and if that executed it becomes failure.

13/07/2025 3
What is Software Testing

 Software testing is a process of executing a program with the intention of

finding or identifying bugs or faults in the code.

Definitions of Testing:
Test is a formal activity. It involves a strategy and a systematic approach.
The different stages of tests supplement each other. Tests are always
specified and recorded.

Test is a planned activity. The workflow and the expected results are
specified. Therefore the duration of the activities can be estimated.

The point in time where tests are executed is defined

The test is the formal proof of software quality.

13/07/2025 4
How to test a program

• Testing a program involves executing

the program with a set of test inputs
and observing if the program behaves
as expected.
• If the program fails to behave as
expected, then the input data and
the conditions under which it fails are
noted for later debugging and error
correction.

13/07/2025 5
Objectives of testing
 Testing is a process of executing a program with the intent of
finding an error.
 A good test case is one that has a high probability of finding an
as-yet- undiscovered error.
 A successful test is one that uncovers an as-yet-undiscovered
error.

13/07/2025 6
Principles of Testing
1.Testing shows the presence of defects
• Software testing talks about the presence of defects and doesn’t talk about the absence of defects.
• Testing can reduce the number of defects but not remove all defects.

2.Exhaustive testing is not possible

• Exhaustive testing is impossible means the software can never test at every test case.
• It can test only some test cases and assume that the software is correct and it will produce the correct
output in every test case.

3.Early testing
• The defect detected in the early phases of SDLC will be very less expensive.

4.Defect clustering
• In a project, a small number of modules can contain most of the defects.

5.Pesticide paradox
• Repeating the same test cases, again and again, will not find new bugs.

6.Testing is context-dependent
• Different types of software need to perform different types of testing.

7.Absence of errors fallacy

• If a built software is 99% bug-free but it does not follow the user requirement then it is unusable.
13/07/2025 7
Testing fundamentals
1. Errors, Faults and Failure
1. Error is the discrepancy between actual outcome and desire outcome.
2. Fault is also called bug, cause of error is a fault. Fault is an accidental condition that causes
a functional unit to fail its task.
3. Failure happens when a faulty code gets executed.
An error is caused by a fault and may propagate to become failure.
2. The cost of defects

13/07/2025 8
Testing fundamentals (cont’d)

3. Testing process 4. Role of Software tester

The role of tester is to confirm that the

software works properly by finding defects as
early as possible and ensuring that these are
fixed.

Activities of tester:
 Prepare test plan and test data
 Design test cases and test scripts
 Perform testing
 Track defects in the defect management
system
 Participate in the test review meeting
 Prepare test report
 Follows software standards.

13/07/2025 9
Software Test Activities
• Testing is a long activity in which several test cases are executed.
• Testing is carry out by different teams in different environments and machines.
• So, testing phase contains different activities:

 Create test plan

1. It is a formal document including following attributes:
1. Test plan ID
2. Purpose
3. Test items
4. References
5. Features to be tested
6. Schedule
7. Responsibilities
8. Test environment
9. Test case libraries and standards
10. Test strategy
11. Test deliverables
12. Release criteria
13. Expected risk

13/07/2025 10
Test activities(cont’d) Test case to issue a book to the student member from
library
Test plan ID TP-001
 Design test cases
 A test case is a set of Test case ID TC-001
input and expected Features to be tested Issuance of book to member
output under which a
Preconditions 1. Library membership is mandatory
program unit is 2. Book quota limit should be <5
exercised with the
Test script 1. Verify membership
purpose of causing 2. Check book availability
failure and detecting 3. Check number of book to be issued
faults. 4. Issue book
5. Add issued book details into member’s account.
6. Update library catalog
Test Data 1. Valid membership ID
2. 2. Invalid membership ID
3. Valid book limit: 1,4
4. Invalid book limit: 5, 6, 9
Expected results 1. Book should be issued if the member has valid membership card.
2. Display “renew membership” if membership expired.
3. Book limit should be within 5
Test status Pass

13/07/2025 11
 Design test stubs and test drivers

 Test case execution

• After designing test cases, its time to execute the test cases in the test item (code).
• Test environment is set up.
• Tester run the procedure several times with different test cases ad observe the result.
• After executing the text case, the result and observation is recorded in a test summary report.

 Preparation of test summary report

 Test summary report is prepared after completion of test program.
 Report is directed to stakeholders for further processing and discussion.
 It includes number of test cases and their corresponding results.

 Defect tracking and statistics

 Various defects have been tracked for further processing or observation.
 A record of ignored defects, unsolved defects (due to resource constraints) have been listed and managed again.
13/07/2025 12
Why design test cases?

Would it not be sufficient to test a software using a large number of random

input values? Why design test cases?
Answer: this would be very costly and at the same time very ineffective way of testing
due to the following reasons:
Consider the below code:
if (x>y):
max = x;
else:
max = x;
here, several test cases wont find the bug until and unless we choose appropriate test
case for that problem.

13/07/2025 13
Approaches of test case design
• Black-box approach
• White-box (or glass-box) approach

Black-box approach
 Black box testing is performed on the basis of software functions or features.
 Only input values are considered for the design of test cases.
 Output values that the software provides for test cases are observed.
 Internal processing of software is not considered.
 Different methods:
 Equivalence class partitioning
 Boundary value analysis
 Cause-effect graphing

13/07/2025 14
Equivalence class partitioning

 In the equivalence class partitioning approach, the domain of input values to the program under
test is partitioned into a set of equivalence classes.

 The partitioning is done such that for every input data belonging to the same equivalence class,
the program behaves similarly.

5% (discount) 10% 15% 20%

100-1000/- 1001-5000/- 5001-10000/- 10001-50,000/-
(purchase amount)

Example: For a software that computes the square root of an input integer that can assume values
in the range of 0 and 5000. Determine the equivalence classes and the black box test suite.
Answer:
1. Three equivalence classes—set of negative integers, set of integers in the range of 0 and 5000,
and set of integers larger than 5000.
2. Therefore, the test cases must include representatives for each of
3. the three equivalence classes.
4. A possible test suite can be: {–5,500,6000}
13/07/2025 15
Example: Design equivalence class partitioning test suite for a
function that reads a character string of size less than five
characters and displays whether it is a palindrome?
Hints:
 Identify the valid and invalid equivalence classes.
 Take one representative of each equivalence class and design the
test suite.

13/07/2025 16
• Identifying Equivalence Classes
1.Valid Inputs
1. Palindromes of length 1-4
1. (Single character: "a")
2. (Two characters: "aa")
3. (Three characters: "aba")
4. (Four characters: "abba")
2. Non-palindromes of length 2-4
1. ("ab", "abc", "abcd")
2.Invalid Inputs
1. Empty String ("") – Edge case
2. Strings with 5 or more characters – Should be rejected
1. ("abcde", "abcdef")
3. Non-alphabetic characters
1. Numeric: "123", "121"
2. Special Characters: "@@", "a@a", "!@!"
13/07/2025 17
Test Case ID Input Expected Output Equivalence Class

TC1 "a" Palindrome Valid (Palindrome, length 1)

TC2 "aa" Palindrome Valid (Palindrome, length 2)

TC3 "aba" Palindrome Valid (Palindrome, length 3)

TC4 "abba" Palindrome Valid (Palindrome, length 4)

TC5 "ab" Not a Palindrome Valid (Non-palindrome, length 2)

TC6 "abc" Not a Palindrome Valid (Non-palindrome, length 3)

TC7 "abcd" Not a Palindrome Valid (Non-palindrome, length 4)

TC8 "" Error: Empty String Invalid (Empty String)

TC9 "abcde" Error: String too long Invalid (Length >= 5)
TC10 "abcdef" Error: String too long Invalid (Length >= 5)

13/07/2025 18
• Scenario: Testing the input field for "Age" in a registration form, where
the valid age range is 18 to 60.
• Step 1: Identify Input Conditions
• The system only accepts ages between 18 and 60 (inclusive). Any input
outside this range should be rejected.

Step 2: Define Equivalence Class Test Data Examples Expected Result

Equivalence Valid Input (18–60) 18, 25, 40, 60 Accepted

Classes Below Lower Bound
0, 10, 17 Rejected
(<18)
We divide input Above Upper Bound
61, 70, 100 Rejected
values into valid (>60)
and invalid Non-numeric Input "abc", "#$", "twenty" Rejected
partitions: Empty Input (blank field) Rejected

13/07/2025 19
• Step 3: Select Test Cases
• From each equivalence class, we pick at least one test case:
Test Case ID Input Age Expected Output

TC001 18 Accepted

TC002 35 Accepted

TC003 60 Accepted

TC004 17 Rejected

TC005 61 Rejected

TC006 "abc" Rejected

TC007 "" (empty) Rejected

13/07/2025 20
Boundary value analysis
 Boundary value analysis-based test suite design involves designing test cases
using the values at the boundaries of different equivalence classes.
 Programmers often fail to properly address 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 <, etc.
 Refined version of equivalence class partitioning .

Example: For a function that computes the square root of the integer values in
the range of 0 and 5000, determine the boundary value test suite.
Answer: There are three equivalence classes—
 The set of negative integers,
 set of integers in the range of 0 and 5000,
 set of integers larger than 5000.
 The boundary value-based test suite is: {0,-1,5000,5001}
13/07/2025 21
Example:
Let us assume there is a test case that takes the car speed from 40 km/hr- 80 km/hr,
and if the speed is lower than 40 and higher than 80, then our software should send
the notification. To test our software’s working, we will pick boundary values like
40,41,79,80. We will check our software performance on these boundary values. If
the values are entered below 40 and above 80 then it will be considered invalid case.
If the value entered is between 40-80 then it will be a valid case.
Answer:
Boundary Value Test Case
Invalid Test Case Valid Test Case Invalid Test Case
(Min Value-1) (Min,+Min,Max,-Max) (Max Value+1)
39 40,41,79,80 81

13/07/2025 22
 Cause-effect Graphing
• The main drawback of equivalence class partitioning and boundary value analysis is consideration of only
one input domain.
• But such methods may fail when module takes input from various input conditions. Cause-effect method
is suitable for such situation.
Cause-effect graphing Technique:
• It is a graphical representation of a relationship between cause (input) and effect (outcome).
Example:
“Cash withdrawal” from ATM.
Solutions:
1. First identify potential causes and effects of the problem.
2. Draw the graph representing the relationship between causes and effects.
Causes:
C1: Enter valid amount
C2: Enter valid PIN
C3: Amount availability in ATM
Effect:
E1: Cash withdrawal.
13/07/2025 23
• E1 will be successful if C1, C2 and C3 is true.

C1

C2
∧ E1

C3

• Other cases may be possible also like invalid amount, invalid PIN, non availability of
cash in ATM. Such condition may also be represented in graph.
• Other notation of cause-effect graph: C1
C1
E1
Identity NOT E1 ∧
C1 E1 C1 E1 ∨
C2
C2

13/07/2025 24
Example: Perform the cause-effect graph to issue a book to the student of the
library and design the test cases.
1. Identify causes and effects. 2. Draw cause-effect graph
Causes:
C1: Library membership card C1
valid E1
C2: Expired membership card
C3: Verify book limit C2 ∧ E2
C4: availability of books in library
Effects: ∼
C3
E1: Renewal of membership card. ∧ E3
E2: Exceed book issue limit
E3: issue book
C4

13/07/2025 25
3. Design Decision table for test cases of each effects.
Causes Test 1 Test 2 Test 3
C1 X 1 1
C2 1 X X
C3 X 0 1
C4 X X 1
Effect
E1 1
E2 1
E3 1

13/07/2025 26
 Error guessing
Error guessing" is a technique where testers leverage their experience
and intuition to predict potential areas where errors might occur in a
system.
Example scenarios for error guessing:
• Entering invalid data types into a field (e.g., letters in a number field)
• Testing with extremely large or small values to check boundary
conditions
• Simulating user errors like accidentally deleting important data
• Checking for system behavior when unexpected inputs are provided

13/07/2025 27
White box testing
In white box testing each testing strategy essentially designs test
cases based on analysis of some aspect of source code and is
based on some heuristic.
Types:
 Coverage-based
 Statement coverage,
 Branch coverage,
 Multiple condition coverage,
 Path coverage-based testing
 Fault-based
 Mutation testing.

13/07/2025 28
Coverage-based Testing
A coverage-based testing strategy attempts to execute (or cover) certain elements of a program.

Statement coverage-based testing:

 The statement coverage strategy aims to design test cases so as to execute every statement in
a program at least once.
 The principal idea governing the statement coverage strategy is that unless a statement is
executed, there is no way to determine whether an error exists in that statement.
Example: Design statement coverage-based test suite for the following Euclid’s GCD computation program:
int computeGCD(x, y)
int x, y;
{
while (x != y){
if (x>y) then
x=x-y;
else y=y-x;
}
return x;
}
Hints: design different test cases in such a way that every statement executes at least once.
All test cases are {(x = 3, y = 3), (x = 4, y = 3), (x = 3, y =4)}
13/07/2025 29
• STATEMENT COVERAGE for the function
printSum(int a, int b) {
int result = a + b; // Statement 2
if (result > 0) { // Statement 3
printcol("red", result); // Statement 4
}
else if (result < 0) { // Statement 5
printcol("blue", result); // Statement 6
}
}

13/07/2025 30
Branch coverage based testing

13/07/2025 31
13/07/2025 32
13/07/2025 33
Example: Design branch coverage-based test suite for the following Euclid’s
GCD computation program:
int computeGCD(x, y)
int x, y;
{
while (x != y){
if (x>y) then
x=x-y;
else y=y-x;
}
return x;
}
Answer: The test suite {(x = 3, y = 3), (x = 3, y = 2), (x = 4, y = 3), (x = 3, y =
4)} achieves branch coverage

13/07/2025 34
Example: Find the test suite suing branch coverage technique for the following
problem.

int a;
if(a<0)
{
a = a+5;
}
printf(“a =%d”, a);

Answer:
if we take a = -2, it will executes all statements at least once. So it is
statement coverage test case.
But, a = -2 will not evaluate the if statement for false condition. Hence. It is
not branch coverage test case.
Therefore, (a=-2), (a=4), both are branch coverage test case.

13/07/2025 35
Multiple condition coverage testing
• It is used to cover all the conditions.
• Condition coverage is also known as predictive
coverage in which each one of the Boolean
expression have been evaluated to both true and
false condition.

Design the test cases that covers all the

expression within each conditions.

13/07/2025 36
Path coverage based testing
• The basis path method enables the test-case designer to derive a logical
complexity measure of a procedural design and use this measure as a guide
for defining a basis set of execution paths.
• Test cases derived to exercise the basis set are guaranteed to execute every
statement in the program at least one time during testing.

Basic path testing steps:

1. Construct the Control Flow Graph
2. Compute the Cyclomatic Complexity of the Graph
3. Identify the Independent Paths
4. Design Test cases from Independent Paths

13/07/2025 37
Control flow graph (CFG)
• It describes the flow of control within the
program.
• It is a finite set of nodes and edges. The
nodes represents the executable statements
and edges represents the flow of controls.

13/07/2025 38
McCabe’s Cyclomatic Complexity Metric
• McCabe’s cyclomatic complexity defines an upper bound on the
number of independent paths in a program.
• The number of independent paths helps to design different test
cases for the program.
Three ways to obtain cyclometric complexity:
C(C) = E-N+2 (E= edges, N= nodes)

C(C) = P+1 (where P = predicates , means number of selection

or iteration statements)

C(C)= Total number of non-overlapping closed areas + 1

13/07/2025 39
 public static void main(String[] args) {
Scanner scanner = new Scanner(System.in);
System.out.print("Enter a number: ");
int num = scanner.nextInt();
if (num % 2 == 0) {
System.out.println(num + " is even.");
else {
System.out.println(num + " is odd.");
}
scanner.close();
}
13/07/2025 40
 Number of predicates (decision)
= 1.
Hence, C(C) = P+1 = 1+1 = 2

Closed region = 1, C(C) = 1+1 =

2

13/07/2025 41
Identifying the independent paths
• From the previous cyclometric complexity i.e., 2 number of independent path = 2.
• Hence, prepare any random test cases for all independent paths.
1
Example:
1. Greatest of numbers 2
2. Input (A)
3
3. Input (B)
4. If(A>B)
4
5. Then print (A)
6. Elseif(B>A)
5 6
7. Then print (B)
7 8
8. Else
Print(both are equal)
10 9
9. End if
10. End if 11
11. Exit
13/07/2025 42
Mutation Testing – Software
Testing
• Mutation Testing is a type of Software Testing that is performed to
design new software tests and also evaluate the quality of already
existing software tests. Mutation testing is related to modification a
program in small ways. It focuses to help the tester develop effective
tests or locate weaknesses in the test data used for the program.

13/07/2025 Dr. Tauseef Khan, SCOPE, VIT-AP 43

• Objective of Mutation Testing:
The objective of mutation testing is:
• To identify pieces of code that are not tested properly.
• To identify hidden defects that can’t be detected using other testing
methods.
• To discover new kinds of errors or bugs.
• To calculate the mutation score.
• To study error propagation and state infection in the program.
• To assess the quality of the test cases.
13/07/2025 Dr. Tauseef Khan, SCOPE, VIT-AP 44
Level of Testing

Software testing is an activity performed to identify errors so that errors can be

removed to obtain a product with greater quality.
To assure and maintain the quality of software and to represents the ultimate
review of specification, design, and coding, software testing is required.
There are different levels of testing:
 Unit testing
 Integration testing
 System testing
 Acceptance testing

13/07/2025 45
Unit testing
 Here, individual units of software i.e. group of computer program modules, usage
procedures, and operating procedures are tested to determine whether they are suitable
for use or not.
 An individual component may be either an individual function or a procedure.
 Unit Testing is typically performed by the developer. In SDLC or V Model, Unit testing is
the first level of testing done before integration testing.
 Unit testing is such a type of testing technique that is usually performed by developers.

Objectives:
 To isolate a section of code.
 To verify the correctness of the code.
 To test every function and procedure.
 To fix bugs early in the development cycle and to save costs.
 To help the developers to understand the code base and enable them to make changes
quickly.
 To help with code reuse.
13/07/2025 46
 Unit testing with the help of driver and
A complete environment is needed to provide all
stub modules
relevant code that is necessary for execution of the
module.

 The procedures belonging to other modules that

the module under test calls.

 Non-local data structures that the module

accesses.

 A procedure to call the functions of the module

under test with appropriate parameters.

Modules required to provide the necessary

environment (which either call (test drivers) or are
called (test stubs) by the module under test) are
usually not available until they too have been unit
tested.
13/07/2025 47
Integration Testing
Integration testing is carried out after all (or at least some of ) the modules have
been unit tested.
Successful completion of unit testing, to a large extent, ensures that the unit (or
module) as a whole works satisfactorily.
The objective of integration testing is to detect the errors at the module
interfaces (call parameters).
The objective of integration testing is to check whether the different modules of
a program interface with each other properly.

Example:
it is checked that no parameter mismatch occurs when one module invokes the
functionality of another module. It ensure that there are no errors in parameter
passing, when one module invokes the functionality of another module.

13/07/2025 48
Types of Integration testing
• Big-bang approach
• Incremental approach
Top-down approach
Bottom up approach
Mixed/sandwich approach

13/07/2025 49
Big-bang approach:

• It is a simple approach, where all separately tested modules are integrated

first and then tested as a single module.
Advantage:
• Suitable for small project where no. of modules are less.
• No additional cost for writing test drivers and stubs.
Disadvantage:
 May miss important data flow between modules.
 Difficult to find the root cause of any detected error/bugs.
 Generally not useful for large project.
 High risk critical modules are not tested isolated and on priority (high priority
functional requirements)

13/07/2025 50
Incremental testing approach
Testing is done by integrating two or more
modules that are logically related and then
tested for proper functioning.

Top-down approach:
This approach begins with the main module and
moves downwards integrating and testing its lower-
level modules.
Advantage:
 Major control and decisions are considered early
before testing the lower level modules.
Disadvantage:
 Testing may be delayed for a module if lower-level
modules are not available.

Bottom-up approach:
Reverse process of top-down approach.
Lower-level modules are integrated function-wise to
form a subsystem and sub-system are integrated to
form main module.

13/07/2025 51
Sandwich approach: TOP DOWN APPROACH BOTTOM UP APPROACH
Bottom Up Integration testing is one of
 Combination of both top-down and Top Down Integration testing is one of the
the approach of Integration testing in
approach of Integration testing in which
bottom-up approach. which integration testing takes place
01. integration testing takes place from top to
from bottom to top means system
bottom means system integration begins
 Top-down approach forces the with top level modules.
integration begins with lowest level
modules.
lower-level modules to be available
In this testing the higher level modules In this testing the lower level modules
and bottom-up approach requires are tested first then the lower level are tested first then the higher level
upper-level modules. 02.
modules are tested and then the modules modules are tested and then the
are integrated accordingly. modules are integrated accordingly.
 Most preferred approach as In this testing stubs are used for simulate In this testing drivers are used for
modules are tested as and when the submodule if the invoked submodule simulate the main module if the main
03.
they are available. is not developed means Stub works as a module is not developed means Driver
momentary replacement. works as a momentary replacement.
Bottom Up Integration testing
Top Down Integration testing approach is
approach is beneficial if the crucial
04. beneficial if the significant defect occurs
flaws encounters towards the bottom
toward the top of the program.
of the program.
In Top Down Integration testing approach In Bottom Up Integration testing
the main module is designed at first then approach different modules are
05.
the submodules/subroutines are called created first then these modules are
from it. integrated with the main function.
It is implemented on Structure/procedure- It is implemented on Object-oriented
06.
oriented programming languages. programming languages.
The complexity of this testing is
07. The complexity of this testing is simple.
complex and highly data intensive.
08. It works on big to small components. It works on small to big components.
In this approach Stub modules must be In this approach, Driver modules must
09.
produced. be produced.
13/07/2025 52
System testing
 System Testing is a type of software testing that is performed on a complete integrated
system to evaluate the compliance of the system with the corresponding requirements.
 In system testing, integration testing passed components are taken as input. The goal
of integration testing is to detect any irregularity between the units that are integrated
together.
 System testing detects defects within both the integrated units and the whole system.
 System testing test the system for functional requirements

Types :
 Performance testing: Test the speed, scalability, stability and reliability of the software product
 Volume testing: test amount of data the system can processed..
 Stress testing: test system under stress situation.
 Security testing: check security of system.
 Recovery testing: test to recover any lost data.
 Compatibility testing: new system (files) is compatible with older one.
 Configuration testing: system can run on different h/w and s/w.
 Installation testing: system is correctly installed or not.
 Documentation testing: in operational stage, if any error come, manual is needed to overcome this
situation.
13/07/2025 53
Acceptance testing
 This testing is performed before the system is released in the market.
 It is performed with the customer to ensure that the system is acceptable for
delivery or not.
 System is tested in customer point of view.

Types:
 User testing: test the functionalities that frequently used by users.
 Regulation testing: test the system based on certain regulation of the area
where the system to be deployed.
 Alpha testing: Pilot testing (testing performed in a development
environment)
 Beta testing: performed by limited and friendly customer.

13/07/2025 54