STM Unit 1 Complete notes for engineering students for better understanding

SOFTWARE TESTING
METHODOLOGIES (STM)
B.Tech CSE (AI) III-II
By
Mrs. K Lakshmi Viveka
Associate 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 efficiently and effectively.
S/W Testing = S/W Verification + S/W 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

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.

Function vs. Structure
Functional Testing Structural Testing
This test checks whether the software is
functioning in accordance with functional
requirements and specifications.
This test evaluates the code structure or
internal implementation of the code.
It is also known as black-box testing as no
knowledge of the internal code is required.
It is also known as white-box or clear-box
testing as thorough knowledge and access of
the code is required.
It ensures that the system is error-free.
Finds errors in the internal code logic and data
structure usage.
It is a quality assurance testing process
ensuring the business requirements are met.
It does not ensure that the user requirements
are met.
Functional testing checks that the output is
given as per expected.
Performed the entire software in accordance
with the system requirements.
The functional testing tool works on event
analysis methodology.
Perform on low-level modules/software
components.
It provides information that prevents business
loss.
It provides information on improving the
internal structure of the application.
Functional testing tool works on event analysis
methodology.
Structural testing tools follow data analysis
methodology.
Before writing a functional test case, a tester is
required to understand the application’s
requirements.
Writing a structural test case requires
understanding the coding aspects of the
application.

Designer vs. Tester
Designer Tester
Designs test cases, test plans, and testing
strategies
Executes test cases, reports bugs, and
validates fixes
Defines test scenarios, test scripts, and
automation frameworks
Performs manual or automated testing and
ensures software quality
Involved in the early stages of the SDLC
(Software Development Life Cycle)
Primarily involved during the testing and
execution phases
Ensures comprehensive test coverage based
on requirements
Identifies defects, verifies fixes, and checks
for regressions
Knowledge of test design techniques,
automation tools, and programming
Analytical thinking, attention to detail, and
defect detection
Test design tools like TestRail, Selenium (for
automation frameworks)
Defect tracking tools like JIRA, Test
execution tools like QTP, Appium
Works closely with business analysts and
developers to define test strategies
Works with developers to reproduce bugs
and verify fixes
Focus on test case creation for functional,
performance, and automation testing
Focus on manual execution, exploratory
testing, and regression testing
Ensuring well-structured and
comprehensive test cases
Ensuring the software is defect-free and
meets quality standards

Small vs. Large
Small Large
Testing individual units or components
of software.
Testing multiple integrated units or the
entire system.
Limited to a single function, method, or
module.
Covers interactions between modules,
systems, or external components.
Unit Testing, Component Testing.
Integration Testing, System Testing,
End-to-End Testing.
Low, focuses on a single component.
High, due to multiple interacting
components.
Simulated or limited test data. Realistic or production-like test data.
Easier to maintain due to isolated
scope.
Harder to maintain due to
interdependencies.
Lower, as only a small part is tested.
Higher, requires more time and
resources.
Identifies bugs early in development.
Detects issues that arise due to system
integration.

 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
 A reasonable metric for bug importance is
Importance = ($) = Frequency * (Correction cost + Installation Cost + Consequential
Cost)

 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:TheATM 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

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.

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
cannot be reproduced.
BUG LIFE CYCLE

 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
TAXONOMY OF 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
development but are often the hardest to remove.
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.

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.

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. 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.
2. STRUCTURAL BUGS

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 compilation.

 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.
3. DATA BUGS:

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

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.

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.

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.

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
software increases.

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.

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 payment
→ Order confirmation.

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), it may indicate a

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 solved;
otherwise, it is not.

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 for
patient records, appointments, and billing accuracy.

STM Unit 1 Complete notes for engineering students for better understanding

More Related Content

Similar to STM Unit 1 Complete notes for engineering students for better understanding

Recently uploaded

STM Unit 1 Complete notes for engineering students for better understanding