SOFTWARE TESTING

METHODOLOGIES (STM)
(JNTUH – R22)
B.Tech CSE (AI&ML) III-II
By
K SUDHAKAR
Assistant Professor
 UNIT-I
Introduction: Purpose of testing, Dichotomies, model for
testing, consequences of bugs, taxonomy of bugs Flow
graphs and Path testing: Basics concepts of path testing,
predicates, path predicates and achievable paths, path
sensitizing, path instrumentation, application of path
testing.
 UNIT - II
Transaction Flow Testing: transaction flows,
transaction flow testing techniques. Data Flow
testing: Basics of data flow testing, strategies
in data flow testing, application of data flow
testing. Domain Testing: domains and paths,
Nice & ugly domains, domain testing, domains
and interfaces testing, domain and interface
testing, domains and testability.
 UNIT-III
Paths, Path products and Regular
expressions: path products & path
expression, reduction procedure,
applications, regular expressions & flow
anomaly detection. Logic Based Testing:
overview, decision tables, path expressions,
kv charts, specifications.
 UNIT-IV
State, State Graphs and Transition testing: state
graphs, good & bad state graphs, state testing,
Testability tips.

UNIT-V
Graph Matrices and Application: Motivational
overview, matrix of graph, relations, power of a
matrix, node reduction algorithm, building
tools. (Student should be given an exposure to
a tool like Jmeter/selenium/soapUI/Catalon).
TEXT BOOKS:
1. Software Testing techniques - Baris Beizer,
Dreamtech, second edition.
2. Software Testing Tools – Dr. K. V. K. K. Prasad,
Dreamtech.
REFERENCE BOOKS:
1. The craft of software testing - Brian Marick,
Pearson Education.
2. Software Testing Techniques – SPD(Oreille)
3. Software Testing in the Real World – Edward
Kit, Pearson.
4. Effective methods of Software Testing, Perry,
John Wiley. 5. Art of Software Testing – Meyers,
John Wiley.
 Introduction:

What is Software Testing?

Software Testing is a method to assess the
functionality of the software program. The
process checks whether the actual software
matches the expected requirements and ensures
the software is bug-free. The purpose of software
testing is to identify the errors, faults, or
missing requirements in contrast to actual
requirements. It mainly aims at measuring the
specification, functionality, and performance of a
software program or application.
 Importance of Software Testing

Software testing is an important

process in the software development
lifecycle . It
involves verifying and validating that
a software application is free of bugs,
meets the technical requirements set
by its design and development , and
satisfies user=requirements
S/W Testing S/W Verification efficiently
+ S/W
and effectively.Validation
 Importance of Software Testing

Quality assurance
Risk minimization
Efficiency
Reliability
Security
 THE PURPOSE OF TESTING
 Detect software bugs, errors, or inconsistencies early in the
development cycle
 Validate that the software meets functional and non-functional
requirements.
 Ensure legal and security compliance
 To produce good quality software.
 MYTH: Good programmers write code without bugs. (It’s wrong!!!)
 In Reality: In 100 lines of Source Code 2 to 3 errors occur
PRODUCTIVITY AND QUALITY IN SOFTWARE:

 In Testing process, from starting stage to ending stage

different flaws (errors) occur, at that situation product is
discarded (change) or back again rework
 productivity means Sum of costs of materials + rework
+discarded components + quality assurance..
 Quality is depends on quality attributes that is Reliability
usability, performance, security and efficiency
GOALS OF SOFTWARE TESTING
PHASES IN TESTER’S MENTAL LIFE
 Phases in a tester's mental life can be categorized into the
following 5 phases:
1. Phase 0: (Until 1956: Debugging Oriented) There is
no difference between testing and debugging.
2. Phase 1: (1957-1978: Demonstration Oriented) The
purpose of testing here is to show that software works.
This failed because the probability of showing that
software works 'decreases' as testing increases.
3. Phase 2: (1979-1982: Destruction Oriented)
The purpose of testing is to show that software doesn’t
work.
4. Phase 3: (1983-1987: Evaluation Oriented) The
purpose of testing is not to prove anything but to reduce
the perceived risk of not working to an acceptable value
(Statistical Quality Control).
5. Phase 4: (1988-2000: Prevention Oriented)
Testability is the factor considered here. One reason is to
reduce the labor of testing.
DICHOTOMIES
Testing vs. Debugging
Functional Testing
Function vs. Structure
Structural Testing
This test checks whether the software is
functioning in accordance with functional This test evaluates the code structure or
requirements and specifications. internal implementation of the code.
It is also known as white-box or clear-box
It is also known as black-box testing as no testing as thorough knowledge and access of
knowledge of the internal code is required. the code is required.
Finds errors in the internal code logic and data
It ensures that the system is error-free. structure usage.
It is a quality assurance testing process It does not ensure that the user requirements
ensuring the business requirements are met. are met.
Functional testing checks that the output is Performed the entire software in accordance
given as per expected. with the system requirements.
The functional testing tool works on event Perform on low-level modules/software
analysis methodology. components.
It provides information that prevents business It provides information on improving the
loss. internal structure of the application.
Functional testing tool works on event analysis Structural testing tools follow data analysis
methodology. methodology.
Before writing a functional test case, a tester is Writing a structural test case requires
required to understand the application’s understanding the coding aspects of the
requirements. application.
 Designer vs. Tester
Designer Tester
Designs test cases, test plans, and testing Executes test cases, reports bugs, and
strategies validates fixes
Defines test scenarios, test scripts, and Performs manual or automated testing and
automation frameworks ensures software quality
Involved in the early stages of the SDLC Primarily involved during the testing and
(Software Development Life Cycle) execution phases
Ensures comprehensive test coverage based Identifies defects, verifies fixes, and checks
on requirements for regressions
Knowledge of test design techniques, Analytical thinking, attention to detail, and
automation tools, and programming defect detection
Test design tools like TestRail, Selenium (for Defect tracking tools like JIRA, Test
automation frameworks) execution tools like QTP, Appium
Works closely with business analysts and Works with developers to reproduce bugs
developers to define test strategies and verify fixes

Focus on test case creation for functional, Focus on manual execution, exploratory
performance, and automation testing testing, and regression testing
Ensuring well-structured and Ensuring the software is defect-free and
comprehensive test cases meets quality standards
 Small vs. Large
Small Large
Testing individual units or components Testing multiple integrated units or the
of software. entire system.
Limited to a single function, method, or Covers interactions between modules,
module. systems, or external components.
Integration Testing, System Testing,
Unit Testing, Component Testing. End-to-End Testing.
High, due to multiple interacting
Low, focuses on a single component. components.
Simulated or limited test data. Realistic or production-like test data.
Easier to maintain due to isolated Harder to maintain due to
scope. interdependencies.
Higher, requires more time and
Lower, as only a small part is tested. resources.
Detects issues that arise due to system
Identifies bugs early in development. integration.
MODEL FOR TESTING
 Above figure is a model of testing process.
 It includes three models:
 A model of the environment,
 a model of the program and
 a model of the expected bugs.
 Environment:
 A Program's environment is the hardware
and software required to make it run.
 For online systems, the environment may include
communication lines, other systems, terminals and
operators.
 The environment also includes all programs that
interact with and are used to create the program
under test - such as OS, linkage editor, loader,
compiler, utility routines.
 Because the hardware and firmware are stable, it is
not smart to blame the environment for bugs.
 Program:
 Most programs are too complicated to understand
in detail.
 The concept of the program is to be simplified in
order to test it.
 If simple model of the program doesn’t explain the
unexpected behavior, we may have to modify that
model to include more facts and details. And if that
fails, we may have to modify the program.
 Bugs:
 Bugs are more insidious (deceiving but harmful)
than ever we expect them to be.
 An unexpected test result may lead us to change our
notion of what a bug is and our model of bugs.
 Some optimistic notions that many programmers or
testers have about bugs are usually unable to test
effectively and unable to justify the dirty tests most
programs need.
OPTIMISTIC NOTIONS ABOUT
BUGS
1. Benign Bug Hypothesis: The belief that bugs are
nice, tame and logical. (Benign: Not Dangerous)
2. Bug Locality Hypothesis: The belief that a bug
discovered with in a component affects only that
component's behavior.
3. Control Bug Dominance: The belief those errors
in the control structures (if, switch etc) of programs
dominate the bugs.
4. Code / Data Separation: The belief that bugs
respect the separation of code and data.
5. Lingua Salvatore Est.: The belief that the
language syntax and semantics (e.g. Structured
Coding, Strong typing, etc) eliminates most bugs.
OPTIMISTIC NOTIONS ABOUT
BUGS

6. Corrections Abide: The mistaken belief that a

corrected bug remains corrected.
7. Silver Bullets: The mistaken belief that X (Language,
Design method, representation, environment) grants
immunity from bugs
8. Sadism Suffices: The common belief (especially by
independent tester) that a sadistic streak, low cunning,
and intuition are sufficient to eliminate most bugs.
Tough bugs need methodology and techniques.
9. Angelic Testers: The belief that testers are better at test
design than programmers is at code design.
Tests:
We do three distinct kinds of testing on a typical
software system. They are
1. Unit / Component Testing: A Unit is the smallest
testable piece of software that can be compiled,
assembled, linked, loaded etc.
2. Integration Testing: Integration is the process by
which components are aggregated to create larger
components. Integration Testing is testing done to
show that even though the components were
individually satisfactory (after passing Unit
testing), checks the combination of components are
incorrect or inconsistent.
3. System Testing: A System is a big component.
System Testing is aimed at revealing bugs that
cannot be attributed to components. It includes
testing for performance, security, accountability,
configuration sensitivity, startup and recovery
 CONSEQUENCES OF BUGS:
IMPORTANCE OF BUGS:
The importance of bugs depends on frequency, correction cost,
installation cost, and consequences.
 Frequency: How often does that kind of bug occur? Pay more
attention to the more frequent bug types
 Correction Cost: What does it cost to correct the bug after it is
found? The cost is the sum of 2 factors: The cost of discovery
& The cost of correction
These costs go up dramatically later in the development cycle
when the bug is discovered. Correction cost also depends on
system size
 Installation Cost: Installation cost depends on the number of
installations: small for single user program, but more for
distributed systems. Fixing on bug and distributing the fix could
exceed the entire system's development cost
 Consequences: What are the consequences of the bug? Bug
consequences can range from mild to catastrophic
Importance metric
 A reasonable = ($) =for
Frequency * (Correction
bug importance is cost + Installation
Cost + Consequential Cost)
 CONSEQUENCES OF BUGS:
The consequences of a bug can be measured in terms of
human, rather than machine, Some consequences of a
bug on a scale of one to ten are:
1. Mild: The symptoms of the bug offend us gently; a
misspelled output or a misaligned printout
2. Moderate: Outputs are misleading or redundant. The
bug impacts the systems performance
3. Annoying: The Systems behavior, because of the bug is
dehumanizing Example: Names are truncated or
arbitrarily modified
4. Disturbing: It refuses to handle legitimate
(authorized/legal) transactions. Example: The ATM wont
give money. Credit card is declared invalid
5. Serious: It loses track of its transaction. Not just the
transaction itself but the fact that the transaction occurred
and accountability is lost
 CONSEQUENCES OF BUGS:
6. Very Serious: The bug causes the system to do the
wrong transactions. Instead of gaining a pay check, the
system credits it to another account or converts deposits
to withdrawals
7. Extreme: The problems are not limited to a few users or
to few transaction types. They are frequent and arbitrary, (
instead of occasionally infrequent) or for unusual case
8. Intolerable: Long term unrecoverable corruption of the
database occurs and the corruption is not easily
discovered. Serious consideration is given to shutting the
system down
9. Catastrophic: The decision to shut down is taken out of
our hands because the system fails
10. Infectious: What can be worse than a failed system?
One that corrupts other systems even though it does not
fail in itself; that erodes the social physical environment;
that melts reactors and starts a war
BUG LIFE CYCLE
What is the Bug Life Cycle? / What is the Defect Life Cycle?
The Defect Life Cycle (or Bug Life Cycle) is the
process a bug follows from discovery to closure. It
starts when a tester finds and reports a bug, then the
development team fixes it. The tester verifies the fix,
and if resolved, the bug is closed; otherwise, it goes
back for further fixing.
 The Defect Life Cycle is different for each company
and project because they use different methods and
tools.
 The number of steps a defect goes through depends on
the testing tools and processes used.
 The main purpose of the defect lifecycle is to track and
fix bugs smoothly and efficiently.
BUG LIFE CYCLE
 Bug Status: Defect Status (or Bug Status) shows the
current stage of a defect in the fixing process. The
number of stages can vary by project, as shown in the
diagram below.
 BUG LIFE CYCLE
1. New – When a tester finds a new bug, it is reported and documented.
2. Assigned – The reported bug is given to the development team for fixing.
3. Open – The developer starts working on the bug; if not valid, it may be
rejected or deferred.
4. Fixed – The developer fixes the bug and updates the status.
5. Pending Retest – The fixed code is sent to the tester and is waiting to be
retested.
6. Retest – The tester checks if the bug is properly fixed.
7. Reopen – If the bug is still there, it is sent back to the developer for fixing
again.
8. Verified – If the tester finds no issues after retesting, the bug is marked as
verified.
9. Closed – The bug is confirmed as fixed and is officially closed.
10. Reopened – If the bug is not fixed, the tester reactivates it for further
fixing.
11. Deferred – If the bug is not urgent, it is postponed for a future release.
12. Rejected – The bug is rejected if it's a duplicate, not an actual bug, or
 TAXONOMY OF BUGS
 There is no universally correct way categorize
bugs. The taxonomy is not rigid.
 The major categories are:
1) Requirements, Features and
Functionality Bugs
2) Structural Bugs
3) Data Bugs
4) Coding Bugs
5) Interface, Integration andSystem Bugs
6) Test and Test Design Bugs
1. Requirements, Features and
Functionality Bugs
Requirements and Specifications Bugs:-
 Requirements and specifications can have mistakes

—they may be incomplete, unclear, or even

contradictory. Sometimes, they are hard to
understand or misunderstood.
 Even if the specifications are correct, they can

change during the design process. Features may be

added, removed, or modified.
 Bugs caused by bad requirements are expensive to

fix. In some cases, they make up a small

percentage of issues, but in others, they can be
more than 50%.
 The worst part is that these bugs appear early in
1. Requirements, Features and Functionality Bugs

Feature Bugs:-
If there is a problem in the specification, it usually
leads to a problem in the feature.
A feature can be wrong, missing, or
unnecessary.
 A missing feature or case is easier to find and fix.

 A wrong feature can be harder to fix because it

may require big design changes.

 An unnecessary feature can make the software

more complex, use more resources, and create

more bugs.
1. Requirements, Features and
Functionality Bugs
Feature Interaction Bugs:-
 Providing clear and well-defined feature

specifications is important, but not enough.

 Features often come in groups, and while

features within a group are usually well-tested,

problems arise from unexpected interactions
between different groups or individual features.
 For example, a phone has both call holding

and call forwarding. These features may work

fine on their own, but when used together, they
could cause unforeseen issues.
1. Requirements, Features and
Functionality Bugs
Specification and Feature Bug Remedies:-
Most feature bugs come from miscommunication between
people.
One solution is to use formal specification languages or
systems. These help in the short term but don’t fully solve
the problem in the long run.
 Short-term benefit: These languages help clearly define

requirements and detect inconsistencies or ambiguities.

 Long-term challenge: Even if we have a perfect
specification language that creates clear and complete
specifications with matching tests, the core problem
remains. We’ve only moved the issue to a higher level
instead of eliminating it.
Testing Techniques for functional
bugs:-
Most functional testing methods focus on
how the software behaves. Techniques
like transaction flow testing, syntax
testing, domain testing, logic
testing, and state testing help find
issues in the way the software functions.
These methods are useful for detecting
functional bugs in the system.
2. STRUCTURAL BUGS
1. Control and Sequence Bugs:-
 Control flow bugs happen due to issues like

missing steps, incorrect loops, unnecessary code,

or complex logic.
 These bugs are common in older programming

languages like Assembly (ALP) and COBOL and

can often be tested and fixed during unit testing.
 Structural testing, especially path testing,

helps catch these bugs by ensuring all possible

code paths work correctly based on the
specifications.
 2. STRUCTURAL BUGS
2. Logic Bugs:
 Bugs can occur due to misunderstandings of how case

statements and logic operators work, especially in

complex IF-THEN-ELSE conditions.
 If the bug affects data processing, it is called a

processing bug. If it affects program flow, it is a

control-flow bug.
3. Processing Bugs:
Processing bugs happen when calculations or data
handling go wrong, like incorrect conversions, ignoring
overflow, or using the wrong comparison (e.g., greater-
than-or-equal). They are common (about 12% of bugs)
but are usually caught with good unit testing.
2. STRUCTURAL BUGS
4. Initialization Bugs:-
 Initialization bugs happen often – They

include forgetting to set a variable before using it,

assuming it’s already set, or using the wrong
format or type.
 Some bugs slow things down – Extra or

unnecessary initialization may not break the

program but can reduce performance.
5. Data-Flow Bugs and Anomalies:-
Most initialization bugs happen when data is used
incorrectly, like using a variable before setting a
value, changing a value but not using it, or
initializing it twice without using it in between.
 3. DATA BUGS:
 Data bugs happen due to issues with data formats,
numbers, or initial values. They are as common as code
bugs but are often ignored.
 Software is relying more on data-driven control, meaning

data bugs can be just as important as code bugs and should

be taken seriously.
Dynamic Data Vs Static data:-
 Dynamic Data Issues: Dynamic data exists only for a

short time, usually during a single transaction. If a shared

resource is not cleaned properly, leftover data (garbage)
can cause bugs. This can be fixed by cleaning up after use,
having a common cleanup system, or not cleaning up at all.
 Static Data Issues: Static data remains fixed in the code

or database, like numbers, text, or patterns. Bugs caused by

static data can usually be detected and fixed during
3. DATA BUGS:
 Information, parameter, and control: Static or
dynamic data can serve in one of three roles, or in
combination of roles: as a parameter, for control, or for
information.
 Content is the actual data (like a number, text, or bit
pattern) stored in memory. It has no meaning until the
hardware or software interprets it. Bugs in content happen
when data gets corrupted or misread.
 Structure and attributes define how data is stored
and understood. Structure refers to the size and shape
of the data (e.g., an array), while attributes define its
meaning (e.g., an integer or a function). Bugs become
more complex as we move from content to attributes
because meaning is harder to define strictly.
4. CODING BUGS:
 Coding errors can lead to many other
types of bugs.
 Syntax errors are not a big problem if
the programming tool checks them
properly, but too many syntax errors
may indicate deeper logic and coding
issues.
 Mistakes in documentation are also
coding bugs because they can confuse
future programmers who maintain the
code.
 5. INTERFACE, INTEGRATION, AND
SYSTEM BUGS
 Various categories of bugs in Interface, Integration, and System
Bugs are:
1. External Interfaces:
External interfaces (like sensors, printers, and communication
lines) help a system interact with the outside world. They must be
robust and follow a clear protocol for communication.
Bugs can happen if the protocol is wrong, timing is incorrect, or the
system misinterprets input/output data, especially when handling
bad input.
2. Internal Interfaces:
Internal and external interfaces are similar, but internal
interfaces are more controlled. A good example is communication
between different routines in a system.
External interfaces must adapt to a fixed environment, while
internal interfaces can be adjusted
 5. INTERFACE, INTEGRATION, AND
SYSTEM BUGS
3. Hardware Architecture:
Hardware-related bugs happen due to misunderstandings of how
the hardware works, such as errors in address generation, input/output
operations, response delays, or incorrect interrupt handling.
To prevent these issues, use good programming and testing practices
and let hardware specialists handle the interface software.
4. Operating System Bugs:
Operating system bugs happen due to misunderstandings about how the
system works, often involving hardware and interface issues. To reduce
these bugs, use OS experts and clear interface modules for system calls.
This won’t remove all bugs but will make them easier to find and fix.
5. Software Architecture:
Software architecture bugs happen due to unexpected interactions
between different parts of the system. These bugs often don’t show up
in unit or integration testing.
Many of these bugs appear only under heavy load, such as missing or
incorrect handling of interrupts or wrong assumptions about memory
and register states. Careful integration and stress testing help find and
fix them.
 5. INTERFACE, INTEGRATION, AND
SYSTEM BUGS
6. Control and Sequence Bugs (Systems Level):
Common Causes of Bugs: These bugs happen due to timing
issues, wrong assumptions about event order, processing
incomplete data, waiting for impossible conditions, or
extra/missing process steps.
Solution: Using a well-structured sequence control system helps
prevent these issues. Special internal mechanisms can also
improve control and reduce errors.
7. Resource Management Problems:
Common Resource Issues: Memory is divided into different
types of resources like buffers, queues, and task blocks.
Problems can happen when a resource is not available, used
incorrectly, or locked by another process.
How to Avoid Issues: The best way to prevent these problems
is through simple design—use fewer types of resources, minimize
resource pools, and avoid private resource management.
5. INTERFACE, INTEGRATION, AND
SYSTEM BUGS
8. Integration Bugs:
Integration bugs happen when tested components
don’t work well together due to inconsistencies or
incompatibilities in how they communicate (e.g., data
structures, call sequences, or protocols).
These bugs are costly because they are usually found
late and require changes to multiple components or data
structures.
9. System Bugs:
System bugs arise from complex interactions between
multiple components like software, hardware, and OS,
making them hard to trace. Though rare (1.7%), they are
critical as they often appear only after deployment.
 6. TEST AND TEST DESIGN BUGS

1. Testing Challenges
Testers are not immune to bugs. Testing requires complex scenarios and
databases. Since tests involve code or similar execution methods, they can
also contain bugs.
2. Test Criteria
Even if the specification is correct and implemented properly, the criteria for
judging software behavior may be flawed or impractical. A well-designed test
criterion is essential, but the more complex it is, the more likely it is to have
bugs.
3. Remedies for Test Bugs
Test Debugging: Debugging test cases is easier than debugging programs
since tests are simpler and don’t require efficiency optimizations.
Test Quality Assurance: Developers should ensure that independent testing
teams follow quality monitoring practices.
Test Execution Automation: Automated tools minimize errors in test
execution, just as programming automation aids have reduced software bugs.
Test Design Automation: Automating test design, similar to software
development automation, helps reduce test-related bugs and improve
efficiency.
FLOW GRAPH AND PATH
TESTING
BASICS OF PATH TESTING:
PATH TESTING :
 Path testing involves selecting a set of
test paths through a program to ensure
thorough testing.
 It is the oldest structural testing
technique and is mainly used for unit
testing new software.
 This technique requires complete
knowledge of the program's structure
and is usually performed by
programmers.
 Its effectiveness decreases as the size of
THE BUG ASSUMPTION:

1. Bug assumption for path testing:

Software may take an unintended path due
to an error, such as executing "GOTO X"
instead of "GOTO Y”
2. Effectiveness of path testing:
Structured programming reduces many
such bugs, making path testing less
effective for modern languages but
essential for older languages like COBOL,
ALP, FORTRAN, and BASIC.
CONTROL FLOW GRAPHS:
The control flow graph is a graphical
representation of a program's control
structure. It uses the elements named
process blocks, decisions, and junctions.
FLOW GRAPH ELEMENTS: A flow graph
contains four different types of elements.
(1) Process Block (2) Decisions

(3) Junctions (4) Case

Statements
1. Process Block:

 A process block is a sequence of

uninterrupted program statements
executed as a unit, ensuring that if one
statement runs, all statements in the
block execute.
 It follows a straight-line execution with
a single entry and exit, containing one or
multiple instructions, subroutines, macros,
or function calls.
 The block can range from a single
statement to hundreds of
statements, maintaining a sequential
flow without decision points or junctions.
2. Decisions:
 A decision is a program point where control
flow diverges, such as machine language
conditional branch and skip instructions.
 Most decisions involve two-way branching,
though some allow three-way control flow.
3. Case Statements:
A case statement is a multi-way branch or
decisions.
Examples of case statement are a jump
table in assembly language, and the
PASCAL case statement.
From the point of view of test design, there
are no differences between Decisions and
Case Statements
4. Junctions:
A junction is a point in the program
where the control flow can merge.
Examples of junctions are: the target of
a jump or skip instruction in ALP, a label
that is a target of GOTO
CONTROL FLOW GRAPHS VS FLOWCHARTS
 NOTATIONAL EVOLUTION:
 The control flow graph is simplified representation of the
program's structure. The notation changes made in creation of
control flow graphs:
 LINKED LIST REPRESENTATION (OR)
LINKED LIST NOTATION FOR A CFG
 In a linked list notation, we represent the CFG using an adjacency
list, where each basic block (node) contains a list of successor
blocks.
PATH TESTING:
ACHIEVABLE PATHS
 Extract the program's control flow graph and
select covering paths.
 Interpret predicates for a chosen path and form

a Boolean expression.
 Expand the expression into a sum-of-products

form, where each term represents a condition

set.
 Solve inequalities to find input values; if

solvable, the path is achievable; otherwise, it's

not.
Here are some real-time examples of achievable
paths in software testing:
1. Login Authentication System
 Control Flow: User enters username and password →
System checks credentials → Redirects to dashboard on
success, or shows error message on failure.
 Achievable Path: Valid username & password →
Successful login → Dashboard displayed.
2. ATM Withdrawal Process
 Control Flow: Insert card → Enter PIN → Select
withdrawal → Enter amount → Dispense cash.
 Achievable Path: Correct card & PIN → Sufficient
balance → Cash dispensed successfully.
3. E-commerce Checkout Process
 Control Flow: Add items to cart → Provide shipping
details → Choose payment method → Payment
successful → Order confirmed.
 Achievable Path: Valid shipping details + Successful
PATH SENSITIZATION
• The act of finding a set of solutions to the path
predicate expression is called PATH
SENSITIZATION.
• In practice, for a selected path finding the
required input vector is not difficult. If there is
difficulty, it may be due to some bugs.
A real-time example of Path Sensitization can be seen in ATM PIN
validation:
Scenario: An ATM system checks if the user enters the correct PIN
and has sufficient balance before allowing a withdrawal.
Control Flow:
▫ User enters PIN → System verifies it.
▫ If correct, the system checks the balance.
▫ If sufficient balance, the withdrawal is processed; otherwise, an error
message is shown.
Path Predicate Formation:
▫ P: Correct PIN entered
▫ B: Sufficient balance
▫ W: Withdrawal successful
▫ The predicate expression: P * B → W
(Only when both P and B are true, W occurs)
Path Sensitization:
▫ If a tester wants to verify the successful withdrawal path, they must
provide an input set where P is correct and B is sufficient.
▫ If they intentionally provide an incorrect PIN or insufficient balance,
the path won’t be achievable—indicating a different path in the flow.
▫ If inputs satisfying the correct path cannot be found due to a flaw in
conditions (e.g., a bug preventing a correct PIN from being accepted),
Heuristic procedures
1. Pick easily sensitizable paths first. Select hard-to-sensitize
paths later to improve test coverage.
2. List all variables affecting decisions, show dependencies as
equations or functions, and describe relationships between variables
using logical or arithmetic expressions.
3. If the same condition appears in multiple decisions, they are linked
because they depend on the same variable.
4. Start with paths that have independent conditions; if dependent
conditions appear but coverage is met, there's a mistake.
5. If testing isn't complete, check paths with related conditions that
don’t depend on external processes.
6. If more testing is needed, add conditions that depend on other
factors but don’t affect each other, like loop conditions.
7. If needed, test paths that have both related and dependent
conditions to ensure full coverage.
8. List values for independent variables, define relationships for
dependent ones, document correlations, and identify forbidden input
combinations.
9. A path is achievable if its set of conditions (inequalities) can be
Examples for Path
Sensitization
1. Simple Independent Uncorrelated
Predicates
2. Independent Correlated Predicates
3. Dependent Predicates
4. Generic
1. Simple Independent Uncorrelated
Predicates

▫ Example: A student passes if Score ≥ 40 and

gets a distinction if Score ≥ 90.
▫ These conditions are independent and do not
affect each other.
2. Independent Correlated Predicates

▫ Example: A login system checks if Username

is valid and Password is correct.
▫ Both conditions are independent but
correlated because both must be true for
login success.
3. Dependent Predicates
▫ Example: A loop runs while X < 10, and
inside it, another condition checks if Y > 5.
▫ The second condition depends on the loop
execution, making it dependent.

4. Generic Case
▫ Example: An online shopping system verifies
user age ≥ 18 for purchase and card
balance > price for payment.
▫ While different, these conditions can be
interdependent if special cases (e.g., parental
consent) exist.
PATH INSTRUMENTATION

1. Path instrumentation is what we have to do to

confirm that the outcome was achieved by the
intended path.
Path Instrumentation Methods

1. General Strategy (Interpretive Trace

Program):
What is it? A way to track how a program runs and ensure it
follows the expected path.
How it works?
 Uses a tracing method (automatic or manual) to follow the

execution path.
 The trace helps confirm whether the expected result was

achieved.
 Computer-generated traces can be too large, so manual

checking might be easier sometimes.

Path Instrumentation Methods

2. Traversal or Link Makers:

What is it? A simple method to track program flow using labeled
links.
How it works?
 Give each link (connection between steps) a unique name.
 Record each link when it gets executed during the test.
 The sequence of recorded links shows the exact path the

program took.
 This helps testers ensure the program is running correctly by
tracking its path step by step.
Link Counters Technique

It is a method used in software testing to track

how many times each link (path) in a program
is executed.
Each link (decision path) in the program has
a counter that increments every time the link
is used.
How does it work?
 Assign a counter to each link in the program.
 Whenever a link is executed, increase its counter by
1.
 At the end of execution, check the counter values to
analyze which paths were used.
Example Scenario:

Imagine a traffic signal program:

If RED → Stop (Counter: 5 times used)

If GREEN → Go (Counter: 10 times used)
If YELLOW → Slow down (Counter: 2 times used)

If YELLOW is used too rarely, it might indicate an

issue in the logic that needs further testing!
The Link Counters Technique helps testers find
such problems and improve software quality!
Applications of Path Testing

1. Integration, Coverage, and Paths in Called

Components
 Ensures that all function calls and interactions between
different components work correctly.
 Helps verify that integrated modules follow the expected
execution paths without missing any logic.
Example: E-commerce app order processing (cart, payment,
shipping) tested for all scenarios (success/failure).
2. Application of Path Testing to New Code
 Used to check if newly written code executes all possible

paths correctly.
 Helps detect bugs early by ensuring all conditions and

branches are tested.

Example: Banking app's money transfer feature tested for
transaction accuracy (balance, recipient, fraud checks).
Applications of Path Testing

3. Application of Path Testing to

Maintenance
 Ensures that modifications or bug fixes do not introduce
new errors.
 Helps verify that existing functionality remains
unaffected after updates.
Example: Social media ranking algorithm update tested
to ensure posts, ads, and notifications function correctly.
4. Application of Path Testing to Rehosting
 Used when moving software to a new platform or

environment (e.g., cloud migration).

 Ensures the program still works correctly by testing all

paths in the new system.

 Example: Hospital system migrated to the cloud tested