In God we trust and others we test

UNIT 4 SOFTWARE TESTING

UNIT IV TESTING AND MAINTENANCE 9
Testing – Unit testing – Black box testing– White box testing – Integration and
System testing– Regression testing – Debugging - Program analysis – Symbolic
execution – Model Checking- Case Study
.

CCS356 V.S 1
CCS356 V.S 2
 What is Software Testing ?
• Testing is the process of executing a program
with the intent of finding faults.”

• Testing is the process of demonstrating that

errors are not present.
• The purpose of testing is to show that a program
performs its intended functions correctly.
• Testing is the process of establishing confidence
that a program does what it is supposed to do.

CCS356 V.S 3
 Terms ( similar but means different)
• bugs are faults in system or application which impact on software
functionality and performance.
• When we make an error during coding, we call this a ‘bug’. Hence, error /
mistake / defect in coding is called a bug.
• There are different types of bugs, some of them are given below.
– Functional Errors
– Compilation Errors
– Missing commands
– Run time Errors
– Logical errors
– Inappropriate error handling

• The bugs introduced by programmer inside the code is called as Defect.

• When a defect reaches the end customer, it is called as Failure.

CCS356 V.S 4
Software Testing Taxonomy

Alpha
TestingConducted at the developer’s
siteDone by internal users or testers

Beta Testing
Conducted at the customer’s environme
Done by real users

Testing Technique
├── Static Testing
└── Dynamic Testing
CCS356 V.S 5
Internal and External Views of Testing
• Any engineered product (and most other things) can be tested
in one of two ways:
• (BLACK-BOX testing) Testing the
functionalities of the software product
without knowing inner implementation
details
• (WHITE-BOX testing) Knowing the internal
workings of a product, tests can be conducted
on the internal operations are performed
according to specifications and all internal
components have been adequately exercised
CCS356 V.S 6
CCS356 V.S 7
CCS356 V.S 8
 Test Case
Test Case ID Test Scenario Preconditions Test Steps Test Data Expected Result
Course registered
1. Login 2. Go to Course
Register for an Student logged in; Course ID: successfully and
CRS_TC_01 Registration 3. Select
available course seats available CS301 confirmation message
course 4. Click Register
displayed
System displays message:
Register for a course Student logged in; 1. Login 2. Select full Course ID:
CRS_TC_02 “Course is full. Registration
that is full course capacity full course 3. Click Register CS302
failed.”
Student already 1. Login 2. Select same System displays message:
Duplicate course Course ID:
CRS_TC_03 registered for the course again 3. Click “You are already registered
registration CS301
course Register for this course.”
Student has not 1. Login 2. Select System displays message:
Register without Course ID:
CRS_TC_04 completed prerequisite advanced course 3. Click “Prerequisite course not
prerequisite CS401
course Register completed.”
1. Login 2. Go to Course removed from
Drop a registered Student already Registered Courses 3. Course ID: schedule and message
CRS_TC_05
course registered for course Select course 4. Click CS301 “Course dropped
Drop successfully.”
View registered 1. Login 2. Navigate to System displays list of
CRS_TC_06 Student logged in Student ID
courses Registered Courses page registered courses
System displays error
Register with invalid 1. Login 2. Enter invalid Course ID:
CRS_TC_07 Student logged in message “Invalid course
course ID course ID 3. Click Register XYZ999
ID.”
User is logged out and
CRS_TC_08 Logout from system Student logged in 1. Click Logout button —
redirected to login page

CCS356 V.S 9
CCS356 V.S 10
 white box testing
• which also known as glass box testing, structural
testing, clear box testing, open box testing and
transparent box testing
• It is based on inner workings of an application
• revolves around internal structure testing.
• programming skills are required to design test cases.
• The primary goal is to focus on the flow of inputs
and outputs through the software and strengthening
the security of the software.

CCS356 V.S 11
 Generic steps of white box testing
1. Design all test scenarios, test cases and prioritize them
according to high priority number.
2. the study of code at runtime to examine the resource
utilization, not accessed areas of the code, time taken by
various methods and operations and so on.
3. testing of internal subroutines takes place. Internal
subroutines such as nonpublic methods, interfaces are able
to handle all types of data appropriately or not.
4. focuses on testing of control statements like loops and
conditional statements to check the efficiency and accuracy
for different data inputs.
5. white box testing includes security testing to check all
possible security loopholes by looking at how the code
handles security
CCS356 V.S 12
 Advantages of White box testing
✓White box testing optimizes code so hidden
errors can be identified.
✓Test cases of white box testing can be easily
automated.
✓This testing is more thorough than other
testing approaches as it covers all code paths.
✓It can be started in the SDLC phase even
without GUI.

CCS356 V.S 13
 Disadvantages of White box testing
❖White box testing is too much time consuming when it
comes to large-scale programming applications.
❖White box testing is much expensive and complex.
❖It can lead to production error because it is not detailed
by the developers.
❖White box testing needs professional programmers who
have a detailed knowledge and understanding of
programming language and implementation.

CCS356 V.S 14
 Techniques Used in White Box Testing
Data Flow Data flow testing is a group of testing strategies that examines the
Testing control flow of programs in order to explore the sequence of
variables according to the sequence of events.
Control Flow Control flow testing determines the execution order of statements or
Testing instructions of the program through a control structure. The control
structure of a program is used to develop a test case for the program.
In this technique, a particular part of a large program is selected by
the tester to set the testing path. Test cases represented by the
control graph of the program.
Branch Testing Branch coverage technique is used to cover all branches of the
control flow graph. It covers all the possible outcomes (true and
false) of each condition of decision point at least once.
Statement Statement coverage technique is used to design white box test cases.
Testing This technique involves execution of all statements of the source
code at least once. It is used to calculate the total number of
executed statements in the source code, out of total statements
present in the source code.
Decision This technique reports true and false outcomes of Boolean
Testing expressions. Whenever there is a possibility of two or more
outcomes from the statements like do while statement, if statement
and case statement (Control flow statements), it is considered as
decision point because there are two outcomes either true or false.

CCS356 V.S 15
 Statement Coverage Testing
• This technique involves execution of all statements of the source code at least
once.
• It is used to calculate the total number of executed statements in the source
code out of total statements present in the source code.

display (int a, int b){ Scenario 1: If a = 5, b = 4 display (int a, int b) {

sum = a+b sum = a+b
If (sum>0) { If (sum>0) {
Print (This is positive result) Print (This is positive result)
} }
else { else {
Print (This is negative result) Print (This is negative result)
} }
} }

CCS356 V.S 16
Statement coverage = 5/7*100 =71%
 Statement Coverage Testing
Scenario 2: If A = -2, B = -7

display (int a, int b){ Statement coverage = 6/7*100=85%

sum = a+b
If (sum>0) {
Print (This is positive result)
}
else {
Print (This is negative result)
}
}

CCS356 V.S 17
 Branch coverage technique
• used to cover all branches of the control flow
graph.
• It covers all the possible outcomes (true and
false) of each condition of decision point at
least once.

CCS356 V.S 18
Read X
Read Y
IF X+Y > 100 THEN
Print "Large"
ENDIF
If X + Y<100 THEN
Print "Small"
ENDIF

Case Covered Branches Path Branch coverage

Yes 1, 2, 4, 5, 6, 8 A1-B2-C4-D6-E8 2

No 3,7 A1-B3-5-D7

CCS356 V.S 19
 Decision Coverage Testing
• This technique reports true and false outcomes of Boolean expressions.
• Whenever there is a possibility of two or more outcomes from the
statements like do while statement, if statement and case
statement (Control flow statements),

(a=7)

Test (int a)
{
If(a>4)
a=a*3
Print (a)
}
CCS356 V.S 20
 Decision Coverage Testing

Test Case Value of A Output Decision Coverage

1 3 3 50%

2 7 21 50%

CCS356 V.S 21
 Path coverage testing ( basis path )

• Construction of graph with nodes and edges

from code.
• Identification of independent paths.
• Cyclomatic Complexity Calculation
• Design of Test Cases

CCS356 V.S 22
 Path coverage testing ( basis path )

• cyclomatic complexity M would be defined as,

• M = E – N + 2P
• where,
E = the number of edges in the control flow graph
N = the number of nodes in the control flow graph
P = the number of connected components

CCS356 V.S 23
 cyclomatic complexity
• Cyclomatic Complexity = Total number of
closed regions in the control flow graph + 1
• Cyclomatic Complexity = P + 1
– Here, P = Total number of predicate nodes
contained in the control flow graph

CCS356 V.S 24
A = 10
IF B > C THEN
A=B
ELSE
A=C
ENDIF
Print A
Print B
Print C

CCS356 V.S 25
IF A = 354
THEN IF B > C
THEN A = B
ELSE A = C
END IF
END IF
PRINT A
Total number of closed regions in the control flow graph + 1

=2+1=3
Cyclomatic Complexity

=E–N+2 =8–7+2 =3
Cyclomatic Complexity
=P+1 =2+1 =3

CCS356 V.S 26
Cyclomatic Complexity Meaning
•Structured and Well Written Code
1 – 10 •High Testability
•Less Cost and Effort
•Complex Code
10 – 20 •Medium Testability
•Medium Cost and Effort
•Very Complex Code
20 – 40 •Low Testability
•High Cost and Effort
•Highly Complex Code
> 40 •Not at all Testable
•Very High Cost and Effort

CCS356 V.S 27
Cyclomatic Complexity = E – N + 2
= 16 – 14 + 2 = 4

CCS356 V.S 28
V(G) = e – n + 2P = 16 – 15 + 2 = 3
V(G) = no. of regions = 3

CCS356 V.S 29
CCS356 V.S 30
 Mutation Testing
• Mutation Testing is a type of software testing in which certain
statements of the source code are changed/mutated to check
if the test cases are able to find errors in source code.
• changed version of the program is known as a mutant of the
original program

CCS356 V.S 31
 Mutation Testing….
Original Program Mutant Program
If (x>y)
If(x<y)
Print "Hello"
Print "Hello"
Else
Else
Print "Hi" Print "Hi"

Mutation Score = (Killed Mutants / Total number of Mutants) * 100

Types of Mutation Testing

Statement Mutation - developer cut and pastes a part of a code of which the outcome
may be a removal of some lines
Value Mutation- values of primary parameters are modified
Decision Mutation- control statements are to be changed

CCS356 V.S 32
 Steps in mutation testing
• Step 1: Faults are introduced into the source code of the program
by creating many versions called mutants. Each mutant should
contain a single fault, and the goal is to cause the mutant version to
fail which demonstrates the effectiveness of the test cases.
• Step 2: Test cases are applied to the original program and also to
the mutant program. A Test Case should be adequate, and it is
tweaked to detect faults in a program.
• Step 3: Compare the results of an original and mutant program.
• Step 4: If the original program and mutant programs generate the
different output, then that the mutant is killed by the test case.
Hence the test case is good enough to detect the change between
the original and the mutant program.
• Step 5: If the original program and mutant program generate the
same output, Mutant is kept alive. In such cases, more effective test
cases need to be created that kill all mutants.

CCS356 V.S 33
UNIT testing

CCS356 V.S 34
 Introduction
► A module encapsulates code and data to implement a
particular functionality.

MODULE FUNCTIONALITY

CCS356 V.S 35
Module example
MATH COUNTER

MATH_Addition(int a,
int b) COUNTER_START()

MATH_Subtraction(int a,
int b)
COUNTER_STOP()
MATH_Multiplication(int a,
int b)

MATH_Division(int a, COUNTER_RESET()
int b)

CCS356 V.S 36
 Software systemexample

ERP
Mobile
app
system
M1 M2 M3
M M
1 2
M1. M2. M3.
M1. M1. M1. M2.
1 2 3 1 1 1 1
M1.
M - Module 2
CCS356 V.S 37
Whatis unit
testing?
• lowest level of testing
• tested in isolation
• most through look at detail
• tests are written and run
by software developers

CCS356 V.S 38
 Whatis unitSoftware development
testing? process V-Model

When is unit
testing
performed?

CCS356 V.S 39
 Whatis unit testing?
When is unit testing performed?

CCS356 V.S 40
Whatis unit testing?

CCS356 V.S 41
 Benefits
• Unit testing allows the programmer to
refactor code at a later date, and make
sure the module still works correctly.

• By testing the parts of a software

application first and then testing the
sum of its parts, integration testing
becomes much easier.

• Unit testing provides a sort of living

documentation of the system.

CCS356 V.S 42
 Data flow Testing
Control Flow Testing
Branch Coverage Testing
Statement Coverage
Testing
Decision Coverage Testing

Stub Driver
Stub is considered as subprogram. It is a simple main program.

Stub does not accept test case data. Driver accepts test case data.

It replaces the modules of the Pass the data to the tested

program into subprograms. These components and print the returned
modules are tested by the next result.
driver.

CCS356 V.S 43
 Testing Case Design Strategies
▪ Software testing is the process to uncover errors in requirement, design and coding.
▪ It is used to identify the correctness, completeness, security and quality of software
products against a specification.
▪ Two basic approaches of software testing are:
1. Black Box Testing
1. Equivalence Partitioning
2. Boundary Value analysis
3. Cause effect graphing
4. Error guessing
2. White Box Testing
1. Statement Coverage
2. Branch Coverage
3. Conditional Coverage
4. Path Testing

CCS356 V.S 44
Software Testing Taxonomy

Alpha
• Testing Conducted at the developer’s site
• Done by internal users or testers

Beta Testing
• Conducted at the customer’s environme
• Done by real users

Testing Technique
├── Static Testing
└── Dynamic Testing
CCS356 V.S 45
 Testing Case Design Strategies
 Black Box Testing
◼ Method that examines the functionality of an application, without
looking at its structure.
◼ The tester does not ever examine the programming code and does
not need any further knowledge of the program other than
requirement specifications (SRS).
◼ You can begin planning for black box testing soon after the
requirements and the functional specifications are available.

CCS356 V.S 46
 Black Box Testing

 Advantages
◼ The designer and the tester are independent of each other.
◼ The testing is done from the point of view of the user.
◼ Test cases can be designed when requirements are clear.

CCS356 V.S 47
 Black Box Testing

 Disadvantages
◼ Test cases are difficult to design.
◼ Testing every output against every input will take a long time and
many program structures can go unchecked.
◼ Inefficient testing because tester only has limited knowledge about
an application.

CCS356 V.S 48
 Equivalence Class Partitioning
• Equivalent Class Partitioning is a black box technique (code is not visible to
tester)
• can be applied to all levels of testing like unit, integration, system, etc.
• In this technique, you divide the set of test condition into a partition that
can be considered the same.
• It divides the input data of software into different equivalence data
classes.

You can apply this technique, where there is a range in the input field.

CCS356 V.S 49
CCS356 V.S 50
Consider a program for the determination of the largest
amongst three numbers.
Its input is a triple of positive integers (say x,y and z) and
values are from interval [1, 300].

CCS356 V.S 51
Output domain equivalence classes are:
O1= {<x, y, z > : Largest amongst three numbers x, y, z }
O2= {<x, y, z > : Input values(s) is /are out of range with sides x, y, z }

CCS356 V.S 52
 Boundary Value Analysis

 Boundaries mark the point or zone of

transition from one equivalence class to
another.
 The program is more likely to fail at a
boundary, so these are the best members of
(simple, numeric) equivalence classes to use.
 If software can operate on the edge of its
capabilities, it will almost certainly operate well
under normal conditions.

CCS356 V.S 53
boundary value testing is to select input variable values at their

• Minimum
• Just above the minimum
• A nominal value
• Just below the maximum
• Maximum

CCS356 V.S 54
 Boundary Value Analysis

 E.C.P. and B.A. can be used together.

 Input: range of valid values
◼ Test Cases (valid) for the ends of the range
◼ Test Cases (invalid) for conditions just beyond the
ends
 Input (real number- Range): 0.0 - 90.0
◼ Test Cases
 0.0, 90.0, -.0.001, 90.001

The number of inputs

selected by this technique is 4n + 1 where ‘n’ is the number of inputs.

CCS356 V.S 55
 Boundary Value Analysis
 Input: number of valid values
◼ Test Cases (maximum and minimum number of values)
◼ One beneath and beyond these values
 Input (file can contain 1-255 records)
◼ Test Cases
◼ 0, 1, 255, and 256 records.
 Types of Boundary conditions
◼ numeric character position quantity speed location size
 Also, extremes
◼ first/last min/max start/finish over/under empty/full
Shortest/longest slowest/fastest largest/smallest …

CCS356 V.S 56
 Boundary Value Analysis
 Use these guidelines for each output condition
 Output: Monthly Deduction
◼ Minimum = 0.0, Maximum = 3500.50
 Test Cases to cause
◼ 0.0 deduction and 3500.50 deduction
 If possible to design test cases to have negative
deduction and deduction larger than 3500.50.
 If input or output of a program is an ordered set
(a sequential file, linear list, table) focus
attention on the first and last elements of the set.

CCS356 V.S 57
 Example

 Employees of an organization are allowed to get

accommodation expenses while traveling on
official tours.
 The program for validating expenses claims for
accommodation has the following requirements
◼ There is an upper limit of Rs. 3,000 for
accommodation expense claims
◼ Any claim above Rs. 3,000 should be rejected
and cause an error message to be displayed
◼ All expense amounts should be greater than
zero and an error message to be displayed if
this is not the case

CCS356 V.S 58
 Example
 Inputs: Accommodation Expense
 Boundaries of the Input Values
 Better to show Boundaries Graphically
◼ Boundary: 0 < Expense ≤
3,000 0 3,000
 | |
-1|+1 2,900|3,001

CCS356 V.S 59
 Equivalence Class Partitioning

 Employees of an organization are allowed to get

accommodation expenses while traveling on official tours.
The program for validating expenses claims for
accommodation has the following requirements
 There is an upper limit of Rs. 3,000 for accommodation
expense claims
 Any claim above Rs. 3,000 should be rejected and cause an
error message to be displayed
 All expense amount should be greater than zero and an
error message to be displayed if this is not the case

CCS356 V.S 60
 Test Case Generation (Using Black Box) and Test
Data Generation (Equivalence Class Partitioning)

Inputs: Accommodation Expense

Partition the Input Values:

Expense ≤ 0
0 < Expense ≤ 3,000
Expense > 3,000

CCS356 V.S 61
Test Case Generation (Using Black Box) and Test
Data Generation (Equivalence Class Partitioning)

Test Case 1 2 3

Expenses 2000 -10 3500

P. tested 0<E.C<3000 E.C<0 E.C>3000

Exp-output OK error mess error mess

CCS356 V.S 62
 Worst-Case Testing

(i) Minimum value

(ii) Just above minimum value
(iii) Just below maximum value
(iv) Maximum value
(v) Nominal (Average) value

Robust Worst-Case Testing

just below minimum value (minimum value–)

and
just above maximum value (maximum value+).

CCS356 V.S 63
Boundary Analysis

CCS356 V.S 64
CCS356 V.S 65
 Boundary Analysis
 We analyze the range of dates by partitioning
the month field for the date into different sets:
◼ {February}
◼ {April, June, September, November}
◼ {Jan, March, May, July, August, October, December}
 For testing, you want to pick one of each. There
might or might not be a “boundary” on months.
The boundaries on the days, are sometimes 1-28,
sometimes 1-29, etc

CCS356 V.S 66
 Error Guessing

 Just ‘guess’ where the errors are ……

 Intuition and experience of tester
 Ad hoc, not really a technique
 Strategy:
◼ Make a list of possible errors or error-prone situations
(often related to boundary conditions)
◼ Write test cases based on this list

CCS356 V.S 67
Test Case Generation (Using Black Box) and Test
Data Generation (Equivalence Class Partitioning)
❑ Consider a function, Grade(), with the following
specification:
❑ The function is passed an coursework out of 100 out of
which it generates a grade for the course in the range
‘A’ to ‘D’.
❑ The grade is calculated from the overall mark, which is
calculated as the sum of exam and c/w marks, as
follows:
 greater than or equal to 70 ‘A’
 greater than or equal to 50, but less than 70 ‘B’
 greater than or equal to 30, but less than 50 ‘C’
 less than 30 ‘D’
 Where a mark is outside its expected range then a fault
message (‘FM’) is generated.
 All inputs are passed as parameters.

CCS356 V.S 68
Test Case Generation (Using Black Box) and Test
Data Generation (Equivalence Class Partitioning)

 Design Test Cases to exercise Partitions

 A test case comprises the following:
◼ the inputs to the component
◼ The partitions exercised
◼ The expected outcome of the test case
 Two Approaches to Design Test Cases
◼ Separate test cases are generated for each partition
◼ A minimal set of test cases is generated to cover all
partitions

CCS356 V.S 69
Test Case Generation (Using Black Box) and Test
Data Generation (Equivalence Class Partitioning)
 Input :: Course mark
 Equivalence Class Partitions
◼ Valid
 0 ≤ real number ≤ 100
◼ Invalid
 alphabetic
 Coursework < 0
 Coursework > 100

CCS356 V.S 70
Test Case Generation (Using Black Box) and Test
Data Generation (Equivalence Class Partitioning)

Invalid E.C.(s)
Course Mark < 0 ‘FM’
Course Mark > 100 ‘FM’

Valid E.C.(s)
0 ≤ Course Mark < 30 ‘D’
30 ≤ Course Mark < 50 ‘C’
50 ≤ Course Mark < 70 ‘B’
70 ≤ Course Mark ≤ 100 ‘A’

CCS356 V.S 71
Test Case Generation (Using Black Box) and Test
Data Generation (Equivalence Class Partitioning)
Valid Partitions

TEST CASES 1 2 3

Input Course Work 8 -15 47

Partition tested 0<=c<=25 c<0 c>25

Expected output ‘C’ FM FM

CCS356 V.S 72
Test Case Generation (Using Black Box) and Test
Data Generation (Equivalence Class Partitioning)

Invalid Partitions

Test cases 4

Input (course work) ‘A’

Partition tested (of exam mark) real

Expected output FM

CCS356 V.S 73
Test Case Generation (Using Black Box) and Test
Data Generation (Equivalence Class Partitioning)

 Equivalence partitions may also be considered for

invalid outputs.
 Difficult to identify unspecified outputs.
 If test can cause to occur an Invalid output, i.e.
identified a defect in either the component, its
specification, or both.

CCS356 V.S 74
Test Case Generation (Using Black Box) and Test
Data Generation (Equivalence Class Partitioning)
Valid Partitions

Test cases 5 6 7
Course Marks -20 17 45
Partition tested 0<C 0<=C<=30 30<=C<50

Expected output ‘FM’ ‘D’ ‘C’

CCS356 V.S 75
Test Case Generation (Using Black Box) and Test
Data Generation (Equivalence Class Partitioning)

Valid Partitions

Test Case 8 9 10

Input Course Mark 66 80 110

Partition tested 50<C<70 70<C<100 C>100

Expected output B A FM

CCS356 V.S 76
 Minimal Test Cases

 Many of the test cases are similar, but targeting

different E.P.(s)
 it is possible to develop single test cases that
exercise multiple partitions at the same time
 Reduces number of test cases required to cover
all E.P.(s)

CCS356 V.S 77
Test Cases for Multiple E.P.(s)

CCS356 V.S 78
Test Cases for Multiple E.P.(s)

CCS356 V.S 79
CCS356 V.S 80
CCS356 V.S 81
Decision table technique

• appropriate for the functions that have a logical

relationship between two and more than two inputs.
• This technique is related to the correct combination of
inputs and determines the result of various combinations
of input.
• To design the test cases by decision table technique

CCS356 V.S 82
If both email and password are correctly matched, the user will be directed
to the email account's homepage; otherwise, it will come back to the login
page with an error message specified with "Incorrect Email" or "Incorrect
Password."

CCS356 V.S 83
CCS356 V.S 84
CCS356 V.S 85
CCS356 V.S 86
Cause –effect graphic
❖ Cause Effect Graph is a black box
testing technique that graphically
illustrates the relationship between a
given outcome and all the factors that
influence the outcome.

CCS356 87
V.S
 Cause – effect graphic
❖Step 1: Identify the causes and the
effects
❖Step 2: Establish the graph of relations
between causes and effects
❖Step 3: Complete the graph by adding
constraints between causes and
effects
❖Step 4: Convert the graph to a decision
table
❖ Step 5: Generate a test cases

CCS356 88
V.S
CCS356 89
V.S
 Example : The “Print message” is software that reads two characters
and, depending on their values, messages is printed.
• The first character must be an “A” or a “B”.
• The second character must be a digit.
• If the first character is an “A” or “B” and the second character is a digit,
then the file must be updated.
• If the first character is incorrect (not an “A” or “B”), the message X must
be printed.
• If the second character is incorrect (not a digit), the message Y must be
printed

CCS356 90
V.S
The Causes of this situation The Effects (results) for this situation are:
are: E1 – Update the file
C1 – First character is A E2 – Print message “X”
C2 – First character is B E3 – Print message “Y”
C3 – the Second character
is a digit

CCS356 91
V.S
E2 states print message “X”. Message X will be printed when the First character
is neither A nor B.
This means Effect E2 will hold true when either C1 OR C2 is invalid. So the graph
for Effect E2 is shown as (In blue line)

CCS356 92
V.S
For Effect E3.
E3 states print message “Y”. Message Y will be printed when the Second
character is incorrect.
This means Effect E3 will hold true when C3 is invalid. So the graph for Effect
E3 is shown as (In Green line)

CCS356 93
V.S
Writing Decision Table Based On Cause And Effect graph
First, write down the Causes and Effects in a single column shown below
traverse from Effect to Cause
Now for E1 to be “1” (true), we have the below two conditions –
C1 AND C3 will be true
C2 AND C3 will be true

For E2 to be True, either C1 or C2 has to be False shown as

CCS356 94
V.S
adding 0 in the blank column

CCS356 95
V.S
Writing Test Cases From The Decision Table
Below is a sample test case for Test Case 1 (TC1) and Test Case 2 (TC2).

CCS356 96
V.S
 Example

A system of car insurance premiums:

❖Sex is Female and Age is < 65,
Premium is 500$
❖Sex is Male and Age is < 25, Premium
is 3000$
❖Sex is Male and Age is => 25 and
<65, Premium is 1000$
❖ Age is => 65, Premium is 1500$

CCS356 97
V.S
 Step 2

Establish the graph of relations

between
causes and
effects

CCS356 98
V.S
Example – Step 3

Complete the graph by adding

constraints between causes and
effects

CCS356 99
V.S
 Example – Step
3

CCS356 10
V.S 0
 Example – Step
4

CCS356 10
V.S 1
 Example – Step 5

CCS356 10
V.S 2
State transition
testing
State transition technique is a
dynamic testing technique, which is
used when the system is defined in
terms of a finite number of states and
the transitions between the states is
governed by the rules of the system.

CCS356 10
V.S 3
 Shopping
Cart
• Your Shopping Cart is empty -
S1
• Add Item - S2
• Remove Item
• Checkout - S3
• Payment - S4

CCS356 10
V.S 4
 State –Transition
diagram

CCS356 10
V.S 5
 State -Transition
Tables

CCS356 10
V.S 6
 Test
Case

CCS356 10
V.S 7
integration testing
Integrate/combine the unit tested module one by one and test the
behavior as a combined unit.

goal of this testing is to test the interfaces between the units/modules

Types of Integration testing are:.

• Big Bang Approach :
• Incremental Approach:
which is further divided into the following
-Top Down Approach
-Bottom Up Approach
-Sandwich Approach - Combination of Top
Down and Bottom Up

CCS356 10
V.S 8
CCS356 10
V.S 9
Big Bang Approach:

Here all component are integrated together at once and then tested.

Advantages:
• Convenient for small systems.
Disadvantages:
• Fault Localization is difficult.
• Given the sheer number of interfaces that need to be tested in this
approach, some interfaces link to be tested could be missed easily.
• Since the Integration testing can commence only after "all" the modules
are designed, the testing team will have less time for execution in the testing
phase.
• Since all modules are tested at once, high-risk critical modules are not
isolated and tested on priority. Peripheral modules which deal with user interfaces
are also not isolated and tested on priority.

CCS356 11
V.S 0
Top-down Integration:
• In Top to down approach, testing takes place from top
to down following the control flow of the software system.
• Takes help of stubs for testing.

depth-first integration would

integrate all components on a
major control path of the structure.

Breadth-first integration
incorporates all components
directly subordinate at each level,
moving across the structure
horizontally

CCS356 11
V.S 1
 The top-down integration process is performed in a series
of five steps:

1. The main control module is used as a test driver and stubs are
substituted for all components directly subordinate to the main
control module.
2. Depending on the integration approach selected (i.e., depth or
breadth first), subordinate stubs are replaced one at a time with
actual components.
3. Tests are conducted as each component is integrated.
4. On completion of each set of tests, another stub is replaced with
the real component.
5. Regression testing (refer previous section of notes) may be
conducted to ensure that new errors have not been introduced.

CCS356 11
V.S 2
 A bottom-up integration strategy may be implemented
with the following steps:
1. Low-level components are combined into clusters (sometimes called builds)
that perform a specific software subfunction.
2. A driver (a control program for testing) is written to
coordinate test case input and output.
3. The cluster is tested.
4. Drivers are removed and clusters are combined moving
upward in the program structure.

CCS356 11
V.S 3
 Coding Standards and Guidelines

Martin Fowler. Any fool can write code that a computer can
understand. Good programmers write code that humans can
understand.

•A coding standard gives a uniform appearance to the codes

written by different engineers.
•It improves readability, and maintainability of the code and it
reduces complexity also.
•It helps in code reuse and helps to detect error easily.
•It promotes sound programming practices and increases
efficiency of the programmers.

CCS356 11
V.S 4
•Indentation: Proper and consistent indentation is essential in producing easy to read
and maintainable programs.
Indentation should be used to:
Emphasize the body of a control structure such as a loop or a select statement.
Emphasize the body of a conditional statement
Emphasize a new scope block
•Inline comments: Inline comments analyze the functioning of the subroutine, or key
aspects of the algorithm shall be frequently used.
•Rules for limiting the use of global: These rules file what types of data can be declared
global and what cannot.
•Structured Programming: Structured (or Modular) Programming methods shall be used.
"GOTO" statements shall not be used as they lead to code, which is hard to read and
maintain,.
•Naming conventions for global variables, local variables, and constant identifiers: A
possible naming convention can be that global variable names always begin with a capital
letter, local variable names are made of small letters, and constant names are always
capital letters.
•Error return conventions and exception handling system: Different functions in a
program report the way error conditions are handled should be standard within an
organization. For example, different tasks while encountering an error condition should
CCS356 11
either return
V.S a 0 or 1 consistently. 5
 example
int totalMarks; // Good
int tm; // Bad

Follow standard styles:

Variables → camelCase
Classes → PascalCase
Constants → UPPER_CASE

CCS356 11
V.S 6
• Coding Standards for Components: It is recommended to write components name
by its purpose. This approach improves the readability and maintainability of code.
• Coding Standards for Classes: Usually class name should be noun starting with
uppercase letter. If it contains multiple word than every inner word should start
with uppercase.
• Eg: String, StringBuffer, Dog
• Coding Standards for Interface: Usually interface name should be adjective starting
with uppercase letter. If it contains multiple word than every inner word should
start with uppercase.
• Eg: Runnable, Serializable, Comparable
• Coding Standards for Methods: Usually method name should either be verb or
verb noun combination starting with lower letter. If it contains multiple word than
every inner word should start with uppercase.
• Eg: print(), sleep(), setSalary()
• Coding Standards for Variables: Usually variable name should be noun starting with
lowercase letter. If it contains multiple word than every inner word should start
with uppercase.
• Eg: name, age. mobileNumber
• Coding Standards for Constants: Usually constant name should be noun. It should
contain CCS356
only uppercase If it contains multiple word than words are separated
11 with (
V.S 7
_ ) underscore symbol. Usually we declare constants with public static and final
 Code Smells
void processOrder() {
class User {
// validate order
void login() {}
// calculate price
void register() {}
// apply discount
void sendEmail() {}
// save to database
void generateReport() {}
// send email
}
}

CCS356 11
V.S 8
 Code refactoring
• Refactoring is the process of making improvements to a
program to slow down degradation through change.

• It means modifying a program to improve its structure, to

reduce its complexity, or to make it easier to understand.

• Refactoring, carried out during program development, is an

effective way to reduce the long-term maintenance costs of
a program

CCS356 11
V.S 9
CCS356 12
V.S 0
CCS356 12
V.S 1
 Code walkthrough
public class FactorialExample {
public static void main(String[] args) {
int num = 5;
int result = factorial(num);
[Link]("Factorial of " + num + " is: " + result);
}

public static int factorial(int n) {

int fact = 1;
for (int i = 1; i <= n; i++) {
fact = fact * i; }
return fact;
}
} CCS356
V.S
12
2
 walkthrough

A code walkthrough helps:

•Detect logical errors early
•Improve code quality
•Share understanding among team members

CCS356 12
V.S 3
 regression testing
Regression testing is a black box testing techniques.
It is used to authenticate a code change in the software does not
impact the existing functionality of the product..

Test cases are re-executed to check the previous functionality of the

application is working fine, and the new changes have not produced
any bugs.
We can perform regression testing in the following scenario, these are:

1. When new functionality added to the application.

Example:
A website has a login functionality which allows users to log in only with Email. Now providing a
new feature to do login using Facebook.

2. When there is a Change Requirement.

Example:
CCS356
Remember password removed from the login page which is applicable previously. 12
V.S 4
 regression testing …
3. When the defect fixed

Example:
Assume login button is not working in a login page and a tester reports a bug
stating that the login button is broken. Once the bug fixed by developers, tester
tests it to make sure Login Button is working as per the expected result.
Simultaneously, tester tests other functionality which is related to the login
button.
4. When there is a performance issue fix

Example:
Loading of a home page takes 5 seconds, reducing the load time to 2 seconds.

5. When there is an environment change

Example:
When we update the database from MySql to Oracle.
CCS356 12
V.S 5
regression testing can be
performed using …

Re-Test is one of the approaches to do regression testing. In this approach, all the test
case suits should be re-executed.
Regression test Selection: a selected test-case suit will execute rather than an entire
test-case suit. The selected test case suits divided in two cases
Reusable Test cases.
Obsolete Test cases.

Prioritize the test case depending on business impact, critical and frequently
functionality used. Selection of test cases will reduce the regression test suite.

CCS356 12
V.S 6
 Types of regression test

Regression testing = Re-testing old features after changes to

ensure nothing breaks.
CCS356 12
V.S 7
Real-Time Project Scenario: Banking Application
Project
A bank develops an online banking system similar to apps like Google
Pay or PhonePe.
The system already has the following modules:
•User Login
•Balance Checking
•Fund Transfer
•Transaction History

New Change in the System

Developers introduce a new feature:
UPI Quick Transfer Module
This allows users to transfer money instantly using a mobile number
or UPI ID.
CCS356 12
V.S 8
Need for Regression Testing
After adding the new module, testers must ensure that the existing
banking functionalities are not affected.

Regression Testing Activities

Testers re-test previously working modules:
1. Login Module
•User login with valid credentials
•Invalid login attempt
•Password reset functionality
Expected Result: Login system should work as before.

CCS356 12
V.S 9
2. Balance Inquiry
•User checks account balance
•Balance updates after transactions
Expected Result: Correct balance should be displayed.

3. Fund Transfer (Existing Feature)

•Transfer money between accounts
•Validate transaction confirmation
•Verify transaction ID generation
Expected Result: Fund transfer should still function correctly.

4. Transaction History
•View recent transactions
•Check new UPI transfers appear in history
CCS356 13
Expected
V.S Result: All transactions should be recorded correctly.
0
Validation testing

CCS356 13
V.S 1
 Debugging Approaches
Debugging is the process of finding and resolving defects or problems within a computer
program that prevent correct operation of computer software or a system.

Brute Force Method : the program is loaded with print statements to print the
intermediate values

Backtracking: starting from the statement at which an error symptom has been
discovered, the source code is derived backward till the error is
discovered
Cause Elimination Method: In this approach, a listing of causes that may presumably
have contributed to the error symptom is developed and tests are conducted to
eliminate every.

Program Slicing: Slicing or program slicing is a technique used in software testing

which takes a slice or a group of program statements in the
program for testing particular test conditions or cases and that may
affect a value at a particular point of interest
CCS356 13
V.S 2
 Program analysis

• Program analysis is used to study the various

characteristics of the program such as its size,
complexity, adequacy of commenting, adherence
to programming standards and many other
characteristics.
• Program Analysis Tool is an automated tool whose
input is the source code or the executable code of a
program and the output is the observation of
characteristics of the program.

CCS356 V.S 133

The structural properties that are usually
analyzed are:

• Whether the coding standards have been

fulfilled or not.
• Some programming errors such as
uninitialized variables.
• Mismatch between actual and formal
parameters.
• Variables that are declared but never used.

CCS356 V.S 134

 Symbolic execution
• Symbolic Execution of a Program is a program analysis technique
used in software testing and verification where inputs are treated
as symbols (variables) instead of concrete values.
• Instead of running the program with specific inputs, it explores all
possible execution paths using symbolic values.

int foo(int x) { Symbolic Execution:

(start: α)
if (x > 0) •Let input: x = α
/ \
return x + 1; Path 1:
α>0 α≤0
else •Condition: α > 0
/ \
return x - 1; •Output: α + 1
return α+1 return α-1
} •Path condition: α > 0
Path 2:
•Condition: α ≤ 0
•Output: α - 1
•Path condition: α ≤ 0

CCS356 V.S 135

 Symbolic execution

Applications
•Software testing (automatic test generation)
•Program verification
•Security analysis (finding vulnerabilities)
•Debugging

symbolic execution as:"Running a program with all possible inputs at once

using mathematics instead of actual values."

CCS356 V.S 136

V Model

CCS356 13
V.S 7
Need of User Acceptance Testing:

CCS356 13
V.S 8
 Types of Acceptance Testing:
• User Acceptance Testing (UAT) (End-User Testing.)
to determine whether the product is working for the user correctly.
Specific requirements often used by the customers are chosen.
• Business Acceptance Testing (BAT):
- whether the product meets the business goals and purposes or not.
• Contract Acceptance Testing (CAT):
- contract which specifies that once the product goes live, within a predetermined period,
the acceptance test must be performed and it should pass all the acceptance use cases.
Here is a contract termed as Service Level Agreement (SLA),
Regulations Acceptance Testing (RAT):
- is used to determine whether the product violates the rules and regulations
that are defined by the government of the country where it is being released.

Operational Acceptance Testing (OAT):

Test the operational readiness of the product and is a non-functional testing.
It mainly includes testing of recovery, compatibility, maintainability, reliability etc.

CCS356 13
V.S 9
Software Maintenance
• Software Maintenance is the process of modifying a software product
after it has been delivered to the customer.
• The main purpose of software maintenance is to modify and update
software application after delivery to correct faults and to improve
performance

Need for Maintenance –

Software Maintenance must be performed in order to:

• Correct faults.
• Improve the design.
• Implement enhancements.
• Interface with other systems.
• Accommodate programs so that different hardware, software, system features,
and telecommunications facilities can be used.
• Migrate legacy software.
• Retire software.
CCS356 14
V.S 0
Types of Software Maintenance
• Corrective maintenance:
either to rectify some bugs observed while the system is in use, or to enhance the
performance of the system.
• Adaptive maintenance:
This includes modifications and updations when the customers need the product
to run on new platforms, on new operating systems, or when they need the
product to interface with new hardware and software.
• Perfective maintenance:
to support the new features that the users want or to change different types of
functionalities of the system according to the customer demands.
• Preventive maintenance:
modifications and updations to prevent future problems of the software. It goals
to attend problems, which are not significant at this moment but may cause
serious issues in future
CCS356 14
V.S 1
Business process reengineering(BPR)

A business process is “a set of logically related tasks performed to achieve a

defined business outcome”
The business →business systems →business processes→business sub-processes

Business process re-engineering is the radical redesign of business processes to

achieve dramatic improvements in critical aspects like quality, output, cost,
service, and speed.
The BPR model defines six activities:

CCS356 14
V.S 2
The BPR model defines six activities
1. Business definition. Business goals are identified within the context of four key
drivers: cost reduction, time reduction, quality improvement, and
personnel development and empowerment.
2. Process identification. critical Processes are identified -- ranked by importance,
by need for change.
3. Process evaluation. The existing process is thoroughly analyzed and measured.
process tasks are identified; the costs and time consumed by process tasks are
noted; and quality/performance problems are isolated.
4. Process specification and design. use cases are prepared for each process that is
to be redesigned. Within the context of BPR, use cases identify a scenario that
delivers some outcome to a customer
5. Prototyping. A redesigned business process must be prototyped before it is fully
integrated into the business. This activity “tests” the process so that refinements
can be made.
6. Refinement and instantiation. Based on feedback from the prototype, the
business process is refined and then instantiated within a business system.

CCS356 V.S 143

IMPLEMENTING BPR IN ICICI BANK

Company Profile:
➢ ICICI Bank (formerly Industrial Credit and Investment
Corporation of India) is a major banking and financial services
organization in India.
➢ It is the 4th largest bank in India and the largest private sector
bank in India by market capitalization.
➢ The bank also has a network of 1,700+branches and about 4,721
ATMs in India and presence in 19 countries, as well as some 24
million customers.
➢ ICICI Bank is one of the Big Four Banks of India, along with State
Bank of India, Axis Bank and HDFC Bank — its main competitors.

CCS356 V.S 144

CCS356 V.S 145
CCS356 V.S 146
CCS356 V.S 147
CCS356 V.S 148
Software Re-Engineering

CCS356 V.S 149

Reverse Engineering

CCS356 V.S 150

CCS356 V.S 151