Software Testing – Unit 1

Introduction to Software Testing

Software testing is the process of checking whether a software application

works correctly according to user requirements and specifications. It helps
identify errors, defects, and missing functionalities before the software is
released.

Testing ensures:

 Correctness

 Reliability

 Performance

 Security

 Quality of software

The main goal is to deliver a bug-free and high-quality product.

Purpose of Software Testing

The purposes of software testing are:

1. Finding Defects

o Detect errors and bugs in software.

2. Ensuring Quality

o Verify that the software meets requirements and standards.

3. Improving Reliability

o Ensure the software works properly under different conditions.

4. Customer Satisfaction

o Deliver software that fulfills user expectations.

5. Reducing Maintenance Cost

o Early bug detection reduces future repair costs.

6. Security Verification

o Identify vulnerabilities and security risks.

Productivity and Quality in Software

Productivity

Productivity refers to the efficiency of software development.

It measures:

 Time taken to develop software

 Cost of development

 Amount of work completed

Higher productivity means:

 Faster development

 Lower cost

 Better resource utilization

Quality

Software quality means how well the software satisfies requirements and
user needs.

Quality factors include:

 Correctness

 Reliability

 Efficiency

 Usability

 Maintainability

 Security

Relationship Between Productivity and Quality

 High productivity without quality leads to poor software.

 High quality with low productivity increases cost and time.

 Good software engineering balances both productivity and quality.

Testing Vs Debugging

Testing Debugging

Process of identifying defects Process of fixing defects

Done by testers Done by developers

Testing Debugging

Finds failures Finds root causes

Checks software behavior Corrects program code

Starts after development modules Starts after bugs are

are ready identified

Example

 Testing finds that login is not working.

 Debugging identifies the coding error causing the issue and fixes it.

Common Software Testing Models

Software testing models define the approach and process followed for
testing software during development. These models help improve
software quality and ensure systematic testing.

1. Waterfall Model

The Waterfall Model is a sequential software development and testing

model.

Phases

1. Requirement Analysis

2. System Design

3. Implementation

4. Testing

5. Deployment

6. Maintenance

Features

 Each phase is completed before the next phase starts.

 Testing is performed after coding is finished.

Advantages

 Simple and easy to understand

 Suitable for small projects

Disadvantages

 Difficult to change requirements later

 Bugs detected late

2. V-Model (Verification and Validation Model)

The V-Model is an extension of the Waterfall Model where testing activities

are planned alongside development.

Structure

Development phase on one side and testing phase on the other side
forming a “V” shape.

Example

 Requirement Analysis ↔ Acceptance Testing

 System Design ↔ System Testing

 Module Design ↔ Integration Testing

 Coding ↔ Unit Testing

Advantages

 Early test planning

 Better quality assurance

Disadvantages

 Not suitable for frequently changing requirements

3. Spiral Model

The Spiral Model combines iterative development and risk analysis.

Phases

1. Planning

2. Risk Analysis

3. Engineering

4. Evaluation

These phases repeat in cycles called spirals.

Features
  Focuses on risk management

 Suitable for large projects

Advantages

 Better risk handling

 Flexible changes

Disadvantages

 Expensive

 Complex management

4. Incremental Model

In this model, software is developed and tested in small parts called

increments.

Features

 Each increment adds new functionality.

 Testing is done for every increment.

Advantages

 Early delivery of software

 Easier debugging

Disadvantages

 Requires proper planning

 Integration issues may occur

5. Agile Testing Model

Agile testing follows Agile software development principles.

Features

 Continuous testing

 Frequent releases

 Customer involvement

Testing Types Used

  Unit Testing

 Integration Testing

 Acceptance Testing

Advantages

 Faster feedback

 Flexible changes

 Better customer satisfaction

Disadvantages

 Requires experienced team

 Continuous communication needed

6. Prototype Model

A prototype (sample version) is created before the actual software.

Process

1. Gather basic requirements

2. Develop prototype

3. User evaluation

4. Improve system

Advantages

 Better understanding of requirements

 Early user feedback

Disadvantages

 May increase development cost

 Users may confuse prototype with final product

7. Big Bang Model

Development starts with minimal planning and testing happens after

development.

Features
  No strict process

 Suitable for small projects

Advantages

 Simple model

 Less planning required

Disadvantages

 High risk

 Difficult debugging

8. Iterative Model

Software is developed repeatedly in cycles.

Features

 Each iteration improves the system.

 Testing is performed in every cycle.

Advantages

 Easy to identify defects early

 Flexible improvements

Disadvantages

 Requires continuous management

 More resources needed

Comparison of Testing Models

Model Best For Main Feature

Waterfall Small projects Sequential process

Stable Testing with

V-Model
requirements development

Large risky
Spiral Risk analysis
projects
Model Best For Main Feature

Increment
Modular systems Step-by-step delivery
al

Agile Dynamic projects Continuous testing

Unclear
Prototype Early sample system
requirements

Big Bang Small experiments Minimal planning

Repeated
Iterative Evolving systems
development

Bugs in Software

A bug is an error, flaw, or fault in a software program that causes incorrect

or unexpected results.

Causes of Bugs

 Wrong logic

 Poor communication

 Coding mistakes

 Incomplete requirements

 Design errors

 Lack of testing

Types of Bugs

1. Functional Bugs

Errors in software functionality.

Example:

 Login button not working.

2. Syntax Bugs

Mistakes in programming syntax.

Example:

 Missing semicolon.
3. Logical Bugs

Incorrect program logic.

Example:

 Wrong calculation output.

4. Runtime Bugs

Errors occurring during execution.

Example:

 Divide by zero error.

5. Performance Bugs

Software becomes slow or inefficient.

Example:

 Web page loading slowly.

6. Security Bugs

Weaknesses affecting security.

Example:

 Unauthorized data access.

7. User Interface Bugs

Problems in design or layout.

Example:

 Misaligned buttons.

8. Compatibility Bugs

Software not working on different devices or browsers.

Example:

 Website not opening in some browsers.

Testing and Design Style

Software design style affects testing efficiency and software quality.

Good Design Style

 Modular design
  Simple structure

 Reusable components

 Proper documentation

 Easy maintenance

Benefits for Testing

 Easier bug identification

 Faster testing

 Better code coverage

 Reduced complexity

Poor Design Style

 Complex code

 Tight coupling

 Lack of documentation

Effects:

 Difficult testing

 More bugs

 Increased maintenance cost

Summary

Software testing is essential for developing reliable and quality software. It

helps detect bugs, improve performance, and satisfy user requirements.
Understanding testing models, bug types, and good design practices helps
produce efficient and maintainable software systems.

Software Testing – Unit 2

Flow / Graphs and Path Testing

Flow Graphs
A flow graph is a graphical representation of the logical flow of a program.

It shows:

 Program statements

 Decision points

 Execution paths

Components of Flow Graph

1. Nodes

o Represent statements or blocks of code.

2. Edges

o Represent the flow of control between nodes.

3. Decision Nodes

o Represent conditions like if, while, for.

Example of Flow Graph

Program

if (a>b)
c=a;
else
c=b;

Flow

 Start

 Condition check

 True path

 False path

 End

Path Testing

Path Testing is a white-box testing technique where all possible execution

paths of a program are tested.

Goal:
  Ensure every path executes correctly.

 Detect logical errors.

Objectives of Path Testing

 Check all independent paths

 Increase code coverage

 Detect hidden bugs

 Validate program logic

Types of Paths

1. Independent Path

A path introducing at least one new statement or condition.

2. Control Flow Path

Represents execution flow from start to end.

3. Loop Path

Path involving loops.

Cyclomatic Complexity

Cyclomatic Complexity measures the number of independent paths in a

program.

Formula

V (G)=E−N +2

Where:

 E = Number of edges

 N = Number of nodes

Higher complexity means:

 More testing required

 More complex program

Achievable Paths

Achievable paths are execution paths that can actually occur during
program execution.

Some paths may be impossible because of:

 Logical conditions

 Program restrictions

Example

if(a>10 && a<5)

This condition is impossible.

So, that execution path is unachievable.

Importance of Achievable Paths

 Reduces unnecessary testing

 Improves testing efficiency

 Focuses on valid execution paths

Path Instrumentation

Path instrumentation means inserting extra code into a program to

monitor execution paths during testing.

It helps:

 Track path execution

 Measure coverage

 Detect errors

Purpose of Path Instrumentation

 Verify path execution

 Identify untested paths

 Analyze program behavior

Instrumentation Techniques

1. Counters

2. Trace statements

3. Logging mechanisms

4. Monitoring tools

Example

printf("Path 1 Executed");

This statement helps identify whether a path executed.

Application of Path Testing

Path testing is used in:

 Banking software

 Embedded systems

 Operating systems

 Web applications

 Safety-critical systems

Advantages

 Finds logical errors

 Improves code quality

 Ensures better coverage

Disadvantages

 Difficult for large programs

 Time consuming

 Complex path analysis

Transaction Flow Testing Techniques

Transaction Flow Testing checks the sequence of operations in a
transaction-oriented system.

A transaction may include:

 Input

 Processing

 Output

Transaction Flow Graph

Represents:

 Transaction start

 Processing steps

 Decision points

 Transaction end

Steps in Transaction Flow Testing

1. Identify transactions

2. Build transaction flow graph

3. Identify paths

4. Design test cases

5. Execute tests

Types of Transaction Errors

 Missing transaction

 Incorrect processing

 Wrong sequence

 Incomplete transaction

Example

ATM Withdrawal Transaction

 1. Insert card

2. Enter PIN

3. Select amount

4. Withdraw cash

5. Print receipt

Testing ensures:

 Correct sequence

 Proper validation

 Successful completion

Advantages of Transaction Flow Testing

 Detects transaction failures

 Improves reliability

 Ensures smooth workflow

Limitations

 Complex for large systems

 Requires detailed analysis

Software Testing – Unit 3

Data Flow Testing Strategies

Introduction

Data Flow Testing is a white-box testing technique that focuses on the flow
of data through variables in a program.

It checks:

 Variable declaration
  Initialization

 Usage

 Modification

 Deletion

The goal is to detect errors related to improper handling of data.

Basic Concepts in Data Flow Testing

1. Definition (DEF)

A variable is assigned a value.

Example:

int a = 10;

Here, a is defined.

2. Usage (USE)

Variable value is used in the program.

Types of Usage

a) Computational Use (C-USE)

Used in calculations.

Example:

c = a + b;

b) Predicate Use (P-USE)

Used in conditions.

Example:

if(a > b)

3. Kill

Variable value becomes invalid or destroyed.

Example:

a = 0;
Data Flow Anomalies

Data flow anomalies are improper variable operations.

Common Anomalies

Anoma
Meaning
ly

Variable defined twice

DD
without use

Variable defined and then

DU
used

Variable defined and then

DK
killed

KU Variable killed and later used

Data Flow Testing Strategies

1. All-Defs Strategy

Ensures every variable definition is tested at least once.

Objective

Check whether each defined variable is properly used.

2. All-Uses Strategy

Tests all possible uses of variables after definitions.

Covers

 C-USE paths

 P-USE paths

3. All DU-Paths Strategy

Tests all definition-to-use paths.

This is the strongest data flow testing strategy.

Advantages of Data Flow Testing

 Detects variable-related errors

 Improves code reliability

 Finds unused variables

 Helps identify improper initialization

Limitations

 Complex for large programs

 Requires detailed control flow analysis

Domain Testing

Introduction

Domain Testing verifies whether program input values are processed

correctly within valid boundaries.

A domain is the set of valid input values accepted by the program.

Domains and Paths

Domain

A domain represents valid input conditions.

Example:

if(age >= 18)

Valid domain:

 Age ≥ 18

Invalid domain:

 Age < 18

Paths

Paths are execution routes followed by the program based on input

conditions.
Different domains lead to different paths.

Domain Boundaries

Testing mainly focuses on:

 Boundary values

 Valid inputs

 Invalid inputs

Example

Condition

if(mark >= 35)

Test Cases

 34 → Invalid

 35 → Boundary

 36 → Valid

Boundary Value Analysis

Boundary values are more error-prone.

Testing focuses on:

 Minimum value

 Maximum value

 Just below boundary

 Just above boundary

Domain Errors

Types of Domain Errors

1. Boundary Shift Error

Incorrect boundary condition.

Example:
Using > instead of >=

2. Missing Domain Error

Some valid inputs are not handled.

3. Overlapping Domain Error

Two conditions overlap incorrectly.

Interface Testing

Introduction

Interface Testing checks communication between different software

modules or systems.

It ensures:

 Proper data transfer

 Correct interaction

 Error handling

Types of Interfaces

1. User Interface

2. Module Interface

3. API Interface

4. Database Interface

5. Hardware Interface

Objectives of Interface Testing

 Verify data exchange

 Detect communication failures

 Ensure compatibility between modules

Interface Testing Process

1. Identify interfaces

2. Design test cases

3. Send test data

4. Verify responses

5. Check error handling

Common Interface Errors

Error Type Description

Data mismatch Incorrect data format

Wrong parameter
Parameter error
passing

Communication Module interaction

failure problem

Timing issue Delay in response

Example of Interface Testing

Online Payment System

Modules:

 Login

 Payment Gateway

 Bank Server

Testing checks:

 Correct payment request

 Successful response

 Proper error messages

Advantages of Interface Testing

 Improves system integration

  Detects communication problems

 Enhances reliability

Limitations

 Complex in distributed systems

 Requires multiple module coordination

Software Testing – Unit 4

Linguistic Metrics

Introduction

Linguistic metrics are measurements based on the language structure and

complexity of software code or documentation.

They evaluate:

 Readability

 Complexity

 Maintainability

 Understandability
These metrics help improve software quality and reduce errors.

Types of Linguistic Metrics

1. Program Length

Measures the total number of operators and operands used in a program.

2. Vocabulary Size

Measures the number of unique operators and operands.

3. Readability Metric

Checks how easy the code is to understand.

Factors affecting readability:

 Meaningful variable names

 Proper indentation

 Comments

 Simplicity

4. Complexity Metric

Measures how difficult the program is to understand and maintain.

Metrics in Software Testing

Introduction

Metrics are numerical measurements used to evaluate software quality

and testing effectiveness.

Importance of Metrics

 Measure software quality

 Improve testing process

 Identify defects
  Reduce maintenance cost

Structural Metrics

Introduction

Structural metrics measure the internal structure and complexity of

software.

These are mainly used in white-box testing.

Types of Structural Metrics

1. Cyclomatic Complexity

Measures the number of independent paths in a program.

Formula:
V (G)=E−N +2

Where:

 E = Number of edges

 N = Number of nodes

Higher complexity means:

 More testing required

 Higher risk of defects

2. Lines of Code (LOC)

Measures total lines in the program.

Types

 Physical LOC

 Logical LOC

3. Nesting Depth

Measures levels of nested loops and conditions.

Higher nesting:
  Increases complexity

 Reduces readability

4. Control Structure Metric

Measures usage of:

 Loops

 Conditions

 Decision statements

Path Products and Path Expressions

Path Products

Path products represent combinations of paths in a control flow graph.

They help:

 Analyze program behavior

 Represent execution sequences

Example

If:

 Path A = Login

 Path B = Payment

Then:

 AB represents login followed by payment.

Path Expressions

A path expression is a symbolic representation of all possible execution

paths.

Used in:

 Flow graph analysis

 Path testing
Example

For a loop:

(A)(B)*

Meaning:

 A executes once

 B executes repeatedly

* indicates repetition.

Advantages of Path Expressions

 Simplifies path representation

 Helps identify execution patterns

 Useful in automation

Syntax Testing

Introduction

Syntax Testing verifies whether input data follows the correct syntax rules.

It is commonly used in:

 Compilers

 Command processors

 Input validation systems

Objectives of Syntax Testing

 Detect invalid input structures

 Verify grammar rules

 Ensure proper input formatting

Syntax Rules

Syntax defines:
  Order of symbols

 Keywords

 Operators

 Statements

Example

Correct Syntax

int a = 10;

Incorrect Syntax

int = a 10;

Syntax Testing Techniques

1. Grammar-Based Testing

Uses formal grammar rules for generating test cases.

2. Mutation Testing

Creates invalid syntax intentionally to test error handling.

3. Random Syntax Generation

Generates random inputs following syntax rules.

Formats in Syntax Testing

Formats define the structure of input data.

Examples of Formats

Date Format

DD/MM/YYYY

Example:

 12/05/2026
Email Format

username@[Link]

Password Format

Rules may include:

 Minimum length

 Numbers

 Special characters

Format Testing

Checks whether data follows the required format.

Example Test Cases for Email

Resul
Input
t

abc@[Link]
Valid
m

Invali
[Link]
d

Invali
@[Link]
d

Test Cases

Introduction

A test case is a set of conditions used to verify software functionality.

Components of a Test Case

1. Test Case ID

2. Objective
 3. Input Data

4. Execution Steps

5. Expected Result

6. Actual Result

7. Status (Pass/Fail)

Example Test Case

Field Value

Test Case ID TC01

Objective Verify Login

Valid
Input
username/password

Expected
Login successful
Result

Status Pass

Characteristics of Good Test Cases

 Simple

 Clear

 Reusable

 Accurate

 Easy to execute

Advantages of Test Cases

 Improves testing coverage

 Helps defect tracking

 Ensures requirement validation

Software Testing – Unit 5

Logic Based Testing

Introduction

Logic Based Testing is a testing technique that verifies the logical behavior
of software programs.

It focuses on:

 Conditions

 Decisions

 Boolean expressions

 Control flow

The goal is to ensure that the program logic works correctly for all possible
conditions.

Objectives of Logic Based Testing

  Verify decision-making logic

 Detect logical errors

 Improve code correctness

 Ensure proper execution flow

Logical Operators Used

1. AND (&&)

2. OR (||)

3. NOT (!)

Example

if(age >= 18 && citizen == 1)

Condition becomes true only if both conditions are satisfied.

Types of Logic Errors

 Incorrect conditions

 Missing conditions

 Wrong operators

 Incorrect nesting

Decision Tables

Introduction

A Decision Table is a tabular representation of conditions and

corresponding actions.

It helps test combinations of inputs systematically.

Components of Decision Table

1. Conditions

Input conditions or rules.

2. Actions

Operations performed based on conditions.

3. Rules

Combination of conditions and actions.

Structure of Decision Table

Conditio Rule Rule Rule

ns 1 2 3

Condition
Y Y N
A

Condition
Y N Y
B

Action X Yes No Yes

Example – ATM Withdrawal

Conditions

 Valid card

 Correct PIN

 Sufficient balance

Actions

 Allow withdrawal

 Reject transaction

Advantages of Decision Tables

 Covers multiple conditions

 Easy to understand

 Reduces missing test cases

Limitations

 Large tables become complex

  Difficult for many conditions

Transition Testing

Introduction

Transition Testing verifies system behavior when moving from one state to
another.

It is mainly used in:

 Embedded systems

 Real-time systems

 Workflow applications

State

A state is a condition or situation of a system at a particular time.

Example of States in ATM

1. Idle State

2. Card Inserted State

3. PIN Verification State

4. Transaction State

5. Exit State

State Transition

A transition occurs when the system changes from one state to another
due to an event.

Example

 Insert card → System moves from Idle State to Card Inserted State.

State Graph

Introduction
A State Graph is a graphical representation of system states and
transitions.

Components of State Graph

1. States

Represented using circles.

2. Transitions

Represented using arrows.

3. Events

Trigger state changes.

Example of State Graph

Idle → Card Inserted → PIN Verified → Transaction → Exit

Advantages of State Graph

 Easy visualization

 Helps identify missing transitions

 Improves testing coverage

State Testing

Introduction

State Testing verifies:

 Correct state transitions

 Proper responses

 Invalid state handling

Objectives of State Testing

 Verify all states

 Test valid transitions

  Test invalid transitions

 Ensure system stability

Types of State Testing

1. Valid State Testing

Checks expected transitions.

Example:

 Correct PIN → Transaction allowed

2. Invalid State Testing

Checks unexpected transitions.

Example:

 Transaction without PIN verification

Steps in State Testing

1. Identify states

2. Identify transitions

3. Create state graph

4. Design test cases

5. Execute tests

Example – Login System

Current Next
Event
State State

Enter valid
Logged Out Logged In
credentials

Logged
Logged In Logout
Out

Error
Logged Out Wrong password
State
Advantages of State Testing

 Detects transition errors

 Improves reliability

 Useful for complex systems

Limitations

 Difficult for very large systems

 Large number of states increases complexity

Comparison of Techniques

Technique Purpose

Logic Based
Verify logical conditions
Testing

Test condition
Decision Tables
combinations

Transition
Verify state changes
Testing

State Graph Visualize transitions

Test states and

State Testing
transitions