1.

Functional Testing – Fully Explained

📌 Definition
Functional Testing is a type of software testing that verifies whether the software functions
according to the specified requirements.
It focuses on what the system does, not how it does it.

➡️ Functional testing is based on black-box testing techniques.

⭐ Key Purpose of Functional Testing

1. Ensure each function works according to business requirements
2. Verify user interactions (inputs → outputs)
3. Detect functional defects
4. Validate data processing and workflows
5. Check integration between modules

⭐ What Functional Testing Checks

Functional testing checks the following:

✔️ Correctness of Features

 Does the login button work?

 Does the form submit data correctly?

✔️ Input-Output Behavior

 Correct outputs generated for given inputs.

✔️ User Interface behavior

 Buttons, menus, links working or not.

✔️ Error Handling

 Shows proper error messages for invalid data.

✔️ Database Updates
  Data stored/updated correctly.

⭐ Characteristics of Functional Testing

 User-centric → tests from user's perspective
 Requirement-driven → follows SRS/FRS
 Black-box approach → internal code is not checked
 Execution-based → runs the software with real inputs

⭐ Types of Functional Testing

Functional testing includes:

1️⃣ Unit Testing

Testing smallest part (function/method).

2️⃣ Integration Testing

Testing interaction between components.

3️⃣ System Testing

Testing the complete system end-to-end.

4️⃣ Sanity Testing

Quick check to confirm basic functionality.

5️⃣ Smoke Testing

Initial check of critical functionalities.

6️⃣ Regression Testing

Re-testing to confirm new changes haven't broken old functionality.

7️⃣ User Acceptance Testing (UAT)

Customer verifies if the software meets requirements.

⭐ Functional Testing Example
Scenario: Enter age (allowed range: 18 to 60)

Expected behavior:

 If age = 18 to 60 → Accept
 Otherwise → Show error

Functional test cases:

Test Case Input Expected Output

TC1 25 Accepted
TC2 10 Error message
TC3 70 Error message

This verifies the correctness of functionality.

✔️ Summary of Functional Testing

 It checks functionality according to requirements.
 Does not consider internal code structure.
 Uses black-box techniques like:
o Equivalence Partitioning (EP)
o Boundary Value Analysis (BVA)
o Decision Table
o State Transition Testing

All Types of Functional Testing (Explained

Separately)
Functional Testing includes the following major types:

1. Unit Testing
2. Integration Testing
3. System Testing
4. Smoke Testing
5. Sanity Testing
6. Regression Testing
7. User Acceptance Testing (UAT)
8. Interface Testing
9. API Testing
 10. Localization Testing
11. Globalization Testing
12. Ad-hoc Testing
13. Exploratory Testing

Below, each type is fully explained separately.

✅ 1) Unit Testing – (Smallest Test Unit)

✔️ Definition

Unit testing is testing individual components, functions, or modules of the software in

isolation.

✔️ Who Performs It?

Developers

✔️ Objective

 To verify correctness of individual pieces of code

 Ensure each module works as expected

✔️ Example

Testing a function that calculates the total bill in a shopping cart.

✔️ Tools

JUnit, NUnit, TestNG

✅ 2) Integration Testing – (Combining

Modules)
✔️ Definition

Integration testing checks the data flow and interaction between integrated modules.

✔️ Why Needed?
Modules work individually but may fail when combined.

✔️ Approaches

 Big Bang
 Top Down
 Bottom Up
 Hybrid

✔️ Example

Testing if login module correctly passes user ID to dashboard module.

✅ 3) System Testing – (End-to-End Testing)

✔️ Definition

System testing validates the entire application as a complete system.

✔️ Focus

 Functional flow
 Data movement
 Complete business logic
 End-to-end scenarios

✔️ Example

Testing entire e-commerce website flow: login → add to cart → payment → order
confirmation.

✔️ Performed By

QA/Testers (independent team)

✅ 4) Smoke Testing – (Build Verification

Testing)
✔️ Definition
Smoke testing is a quick test to ensure the major functionalities work after a new build is
deployed.

✔️ Purpose

Check whether build is stable enough to proceed with deeper testing.

✔️ Example

 Does login work?

 Can the homepage load?
 Can the main menu open?

If these fail → testers reject the build.

✅ 5) Sanity Testing – (Focused

Functionality Test)
✔️ Definition

Sanity Testing verifies specific bug fixes or new features to ensure they work as expected.

✔️ Difference from Smoke Testing

Smoke Sanity
Broad Narrow
Checks stability Checks accuracy
Performed on new build Performed after bug fixes

✔️ Example

Developer fixes a bug in the “Add to Cart” function → testers only recheck this feature.

✅ 6) Regression Testing – (Rechecking Old

Features)
✔️ Definition
Regression testing ensures that new changes have not broken existing functionality.

✔️ When Used?

 After bug fixes

 After enhancements
 After new version release

✔️ Example

After adding a coupon feature, testers ensure:

 Payment still works

 Cart still updates
 Order summary is correct

✅ 7) User Acceptance Testing (UAT)

✔️ Definition

UAT is the final testing done by the client or end user to ensure the system meets business
requirements.

✔️ Purpose

Confirm that the software is ready for real-world use.

✔️ Types of UAT

 Alpha testing
 Beta testing

✔️ Example

Client checks if hotel booking system shows accurate availability and pricing.

✅ 8) Interface Testing
✔️ Definition

Interface testing ensures communication between:

  Software modules
 Client and server
 UI and database
 API and application

✔️ What it checks?

 Data formatting
 Response codes
 Connection failures
 Error messages

✔️ Example

Booking page sends correct data to payment gateway.

✅ 9) API Testing
✔️ Definition

Testing the Application Programming Interfaces to verify request-response behavior.

✔️ What is checked?

 JSON/XML responses
 Status codes
 Authorization
 Data output

✔️ Example

Testing if /login API returns correct token for valid credentials.

✔️ Tools

Postman, SoapUI, RestAssured

✅ 10) Localization Testing

✔️ Definition
Checking that the software meets the local language, currency, and regional formatting.

✔️ Example

For India:

 Currency = ₹
 Date format = DD/MM/YYYY
 Hindi/Regional text display

✅ 11) Globalization Testing

✔️ Definition

Ensures software works for users around the world without cultural/language issues.

✔️ Focus Areas

 Unicode support
 Multi-language input
 Multiple currencies
 Time zones

✅ 12) Ad-hoc Testing

✔️ Definition

Unstructured testing performed without test cases or documentation.

✔️ Purpose

To find unexpected bugs using random testing.

✔️ Example

Tester randomly clicks buttons, enters various values to break the system.

✅ 13) Exploratory Testing

✔️ Definition

Testers explore the application while learning and designing tests simultaneously.

✔️ Characteristics

 No predefined test cases

 Tester’s creativity is used
 Very effective for new/unfamiliar applications

✔️ Example

Tester explores a newly developed travel booking website freely.

🎯 Quick Summary Table

Type of Functional Testing Key Idea
Unit Testing Test individual units
Integration Testing Test combined modules
System Testing Test whole system end-to-end
Smoke Testing Basic check of build stability
Sanity Testing Verify specific bug fixes
Regression Testing Recheck old features
UAT Client validation
Interface Testing Test communication between systems
API Testing Test request-response outputs
Localization Testing Test language, currency for region
Globalization Testing Global usability testing
Ad-hoc Testing Random unstructured testing
Tester-driven learning + testing
Boundary Value Analysis (BVA) – Detailed
Explanation
Boundary Value Analysis is one of the most important black-box testing techniques used
in functional testing.

📌 Definition
Boundary Value Analysis (BVA) is a testing technique in which test cases are designed to
include values at the boundaries of input ranges, because defects often occur at the
extremes or limits.

➤ Simple Definition:

Test the values at the minimum and maximum limits.

⭐ Why Boundary Testing?

Many errors occur at boundary edges rather than the center of input values.

Example:

 Age range: 18 to 60
→ Errors commonly occur at:
o 17
o 18
o 60
o 61

So we test around these limits.

⭐ When is BVA Used?

Whenever requirements define a range, limit, minimum, or maximum.

Examples:

 Age = 18–60
  Marks = 0–100
 Password length = 8–15 characters
 Items in cart = max 10

⭐ BVA Test Values

For a range a to b, BVA uses:

 Lower boundary: a
 Just below lower boundary: a − 1
 Just above lower boundary: a + 1
 Upper boundary: b
 Just below upper boundary: b − 1
 Just above upper boundary: b + 1

⭐ Example of BVA (Age Range)

Requirement: Age must be between 18 and 60.

Boundary values:

 Lower boundary: 18
 Upper boundary: 60

Create test cases:

Test Case Input Explanation

TC1 17 Below minimum
TC2 18 Minimum value
TC3 19 Just above minimum
TC4 59 Just below maximum
TC5 60 Maximum value
TC6 61 Above maximum
⭐ Another Example: Password (Length 8–
15)
Boundary values:

 7 → invalid
 8 → valid
 9 → valid
 14 → valid
 15 → valid
 16 → invalid

Test Cases:

Case Input Length Expected Result

TC1 7 Reject
TC2 8 Accept
TC3 9 Accept
TC4 14 Accept
TC5 15 Accept
TC6 16 Reject

⭐ Advantages of BVA
Benefit Explanation
Finds critical defects Boundary areas contain maximum bugs
Fewer test cases More efficient than testing every value
Easy to understand Simple logic, easy to design
Highly effective Most real-world systems use ranges

⭐ Limitations of BVA
Limitation Explanation
Works only for ranges Not suitable for logical/boolean cases
Cannot test all combinations Only boundary focus, not full coverage
Not effective for complex inputs Multiple field dependency not handled
✔️ Summary of BVA
 Focuses on testing the boundary limits.
 Uses values: min, min−1, min+1, max−1, max, max+1.
 Most effective for input fields with ranges.

Equivalence Class Testing (Equivalence

Partitioning) – Fully Explained
✅ Definition
Equivalence Class Testing, also called Equivalence Partitioning (EP), is a black-box
testing technique in which input data is divided into groups (classes) of valid and invalid
values, and only one value from each group is tested.

The idea is:

👉 If one value in a group works, the rest of the values in the same group will also work.
👉 If one value fails, other values in the same group will also likely fail.

⭐ Why Use Equivalence Class Testing?

 Reduces number of test cases
 Covers maximum possible scenarios
 Saves time and effort
 Ensures effective testing

Instead of testing all inputs, you test only representatives.

⭐ Key Concept
The input domain is divided into partitions, and each partition represents a set of inputs that
are treated the same by the system.

There are two main types of partitions:

1. Valid Equivalence Class

2. Invalid Equivalence Class

⭐ Types of Equivalence Classes

1️⃣ Valid Equivalence Classes
A set of input values for which the system should accept and process normally.

Example:
If age must be between 18 and 60
→ Valid class = 18 to 60

2️⃣ Invalid Equivalence Classes

A set of inputs that the system should reject or show an error.

Examples:
Age < 18
Age > 60
Age = letters or special characters

⭐ Steps in Equivalence Class Testing

1. Identify the input conditions
2. Divide inputs into valid and invalid classes
3. Pick one representative value from each class
4. Create test cases using these representative values
5. Execute and check expected results
⭐ Example 1: Age Input Field
Requirement:

✔️ Age must be between 18 and 60, inclusive.

Step 1: Identify Valid Class

 Valid Class: 18 to 60

Choose any one value → Example: 30

Step 2: Identify Invalid Classes

1. Below minimum: < 18 → Example: 10

2. Above maximum: > 60 → Example: 70
3. Non-numeric: letters or symbols → Example: "ABC"

Equivalence Class Test Cases

Class Type Range / Condition Example Value Expected Result

Valid 18–60 30 Accepted
Invalid < 18 10 Rejected
Invalid > 60 70 Rejected
Invalid Non-numeric "ABC" Error message

⭐ Example 2: Password Length (8–15

characters)
Requirement:

Password must be 8 to 15 characters long.

Valid Class
  Length 8–15
Example: "Password1"

Invalid Classes

 Less than 8 characters → Example: "Pass1"

 More than 15 characters → "VeryLongPassword123"
 Blank input → ""

Equivalence Classes Table

Class Type Condition Representative Value

Valid 8–15 chars "Pass1234"
Invalid < 8 chars "Hi123"
Invalid > 15 chars "ThisPasswordIsTooLong"
Invalid Empty ""

⭐ Example 3: Number of Items (1–10)

Requirement:

User can add 1 to 10 items only.

Valid Class:

 1 to 10

Pick one: 5

Invalid Classes:

 0 or negative → 0, -2
 More than 10 → 15
⭐ Advantages of Equivalence Class Testing
Benefit Explanation
Reduces test cases Tests only representative values
Saves time Less effort, faster testing
Good coverage Covers all valid and invalid input groups
Easy to design Simple and logical technique

⭐ Limitations of EP
Limitation Explanation
Does not check boundaries Cannot detect boundary-based defects alone
May miss edge errors BVA needed along with EP
Only works well for clear ranges Ambiguous requirements reduce accuracy

⭐ Difference Between EP and BVA

Equivalence Partitioning Boundary Value Analysis
Tests one value from each class Tests values at boundaries
Focus on reducing test cases Focus on catching edge errors
Example: 18–60 → test 30 Example: test 17,18,19,59,60,61

Both are usually used together for best results.

🎯 Summary
 Equivalence Class Testing divides inputs into valid and invalid partitions.
 Only one value from each class is tested.
 Greatly reduces number of test cases while maintaining coverage.
 Often combined with Boundary Value Analysis (BVA) for more accuracy.
Decision Table Based Testing – Fully
Explained
1. What is Decision Table Testing? (Definition)
Decision Table Based Testing is a black-box test design technique used to test systems
where the output depends on different combinations of inputs or conditions.
It represents complex business rules in a tabular format (conditions vs. actions).

It helps testers identify:

 All possible input combinations

 Corresponding system actions
 Missing or contradictory business rules

Decision tables are especially useful when the logic is complicated and depends on
multiple conditions.

2. Why Decision Table Testing is Used?

Because many systems follow conditional logic:

IF some conditions are true → THEN perform some actions

Decision table testing ensures:

 Each important combination of conditions is tested

 No rule is forgotten
 Logical errors in decision-making are detected early
 A systematic approach to handle complex scenarios

3. Structure of a Decision Table

A decision table has four main parts:

Area Meaning
Condition Stub List of all input conditions
Condition Entries TRUE / FALSE / Values for each rule
Action Stub List of all possible outputs/actions
Action Entries Actions taken (✓, X, or value) for each rule
General Format

Conditions Rule 1 Rule 2 Rule 3 Rule 4

C1 T T F F
C2 T F T F
Actions
A1 ✓ X ✓ X
A2 X ✓ X ✓

4. Steps to Create a Decision Table

Step 1: Identify the Conditions
List all relevant conditions or inputs.

Example:

 “Is user valid?”

 “Is password correct?”
 “Is account active?”

Step 2: Identify the Possible Actions

List all possible outcomes.

Example:

 Allow login
 Show error message
 Lock account

Step 3: Form All Possible Condition Combinations

Each condition has:

 True/False
or
 Specific values (High/Medium/Low)

For n conditions → possible combinations = 2ⁿ

Step 4: Fill Condition Entries for Each Rule

Specify values (T/F) for each rule.
Step 5: Define Action Entries
For each rule, specify the action(s) that must occur.

Step 6: Simplify the Decision Table (Optional)

If some rules produce identical outcomes → merge them.

5. Detailed Example of Decision Table

Testing
Example Scenario: Loan Approval System

Loan depends on:

1. Income > 50,000

2. Credit Score > 700

Conditions

 C1: Income > 50,000

 C2: Credit Score > 700

Actions

 A1: Approve Loan

 A2: Reject Loan

Decision Table

Conditions Rule 1 Rule 2 Rule 3 Rule 4

C1: Income > 50k T T F F
C2: Credit Score > 700 T F T F
Actions
A1: Approve ✓ X X X
A2: Reject X ✓ ✓ ✓

Interpretation

 Rule 1 → Both conditions true → Approve

 Rule 2 → Good income but poor credit → Reject
 Rule 3 → Poor income but good credit → Reject
  Rule 4 → Both poor → Reject

6. Advantages of Decision Table Testing

✔ Systematic coverage

All combinations of inputs are considered.

✔ Useful for complex business logic

Banking, insurance, finance, validation rules.

✔ Prevents missing conditions

Every rule is explicitly written.

✔ Helps find contradictions or gaps

Detect incomplete or inconsistent requirements.

7. Limitations of Decision Table Testing

✘ Combinational Explosion

Conditions = n → Rules = 2ⁿ
If conditions are many, table becomes huge.

✘ Hard to maintain

Modifying a rule requires updating multiple combinations.

✘ Not suitable for simple systems

Better alternatives exist like BVA, ECT.

✘ Requires clear conditions

Ambiguous requirements lead to wrong tables.

8. Summary
Point Explanation
Definition A black-box technique using tables to test combinations of inputs and outputs
Purpose Validate business logic & decision-making processes
Structure Condition stub, Condition entries, Action stub, Action entries
Best use Systems with multiple rules and dependencies
Benefit Complete coverage of combinations
Limitation Exponential increase in test rules

Cause–Effect Graphing Technique – Fully

Explained
1. What is Cause–Effect Graphing? (Definition)
Cause–Effect Graphing is a black-box test design technique that identifies the logical
relationship between inputs (causes) and outputs (effects) using a Boolean graph.

Its goal is to convert requirements into a graphical model showing how conditions lead to
actions.

From this graph, we later create decision tables and finally test cases.

✔ 2. Why Use Cause–Effect Graphing?

Because in many systems:

 Multiple inputs influence a single output

 Complex rules or conditions exist
 Some inputs depend on others
 Constraints must be followed (only one may be true, etc.)

This technique helps testers understand exact dependencies and produce minimum but
effective test cases.
✔ 3. Key Components
3.1 Causes
These are input conditions or events.
Example:

 C1: User is valid

 C2: Password is correct
 C3: Account active

3.2 Effects
These are output actions of the system.
Example:

 E1: Login successful

 E2: Show error
 E3: Lock account

3.3 Graph Symbols

Cause–Effect Graphs use Boolean logic symbols:

Logic Symbol Meaning

AND • ∧ All conditions must be true
OR ≥1 Any condition true
NOT ¬ Negation
XOR ⊕ Only one condition true
Produces effect
→ →

✔ 4. Steps in Cause–Effect Graphing (Very

Important for Exams)
Step 1 → Identify Causes and Effects
Read requirements → extract all input conditions (causes) and system outputs (effects).
Step 2 → Build the Cause–Effect Graph
Represent:

 Causes as left nodes

 Effects as right nodes
 Logical operators between them

Step 3 → Add Constraints

Constraints help define relationships like:

Types of Constraints

Constraint Meaning
Exclusive (E) Only one condition can be true
Inclusive (I) At least one must be true
One and Only (O) Exactly one condition is true
Requires (R) Condition C1 requires C2
Mask (M) If C1 is true, C2 must be ignored

These constraints help ensure valid test combinations.

Step 4 → Convert Graph Into a Decision Table

Once logic is clear, convert to a table listing:

 Conditions (T/F)
 Effects (occur/not occur)

Step 5 → Generate Test Cases

Each rule in the decision table becomes one test case.

✔ 5. Example of Cause–Effect Graphing

Requirement Example
A simple login system behaves as follows:

1. Login is successful only if

o UserID is valid (C1)
o Password is correct (C2)
2. If UserID is invalid (¬C1) → Show “Invalid User” (E2)
3. If password is wrong (¬C2) → Show “Wrong Password” (E3)

Step 1: Identify Causes and Effects

Causes

 C1: Valid UserID

 C2: Correct Password

Effects

 E1: Login Successful

 E2: Show “Invalid User”
 E3: Show “Wrong Password”

Step 2: Cause–Effect Graph Logic

Logic Rules

 E1 happens only when: C1 AND C2

 E2 happens when: NOT C1
 E3 happens when: C1 AND NOT C2

Graph Structure
C1 ——AND——→ E1
C2 ——AND——→ E1

C1 —NOT—→ E2
C2 —NOT—(AND with C1)→ E3

Step 3: Decision Table

Rule C1 C2 E1 E2 E3
1 (Valid login) T T ✓ X X
2 (Invalid user) F X X ✓ X
 Rule C1 C2 E1 E2 E3
3 (Wrong password) T F X X ✓

Step 4: Generate Test Cases

✔ TC1 – Valid login

Input: valid user, correct password

Expected Output: login success

✔ TC2 – Invalid user

Input: invalid user

Expected Output: “Invalid User”

✔ TC3 – Wrong password

Input: valid user, incorrect password

Expected Output: “Wrong Password”

✔ 6. Advantages of Cause–Effect Graphing

1. Reduces number of test cases

Generates minimum test cases with maximum coverage.

2. Ensures logical completeness

No condition or effect is missed.

3. Best for complex logic

Banking, systems, access control, embedded systems.

4. Helps validate requirements

Any missing or contradictory rules are detected.

✔ 7. Limitations of Cause–Effect Graphing

1. Graph becomes complex

When input conditions > 10 or business rules too many.

2. Requires skilled testers

Understanding Boolean logic is necessary.

3. Time consuming

Especially identifying constraints.

4. Not suitable for simple requirements

Better alternatives: BVA, ECT.

✔ 8. Summary Table
Section Explanation
What? Technique to convert logical conditions into a graph
Used for Complex rules and dependent conditions
Components Causes, Effects, logical operators
Final Output Decision table → test cases
Benefit Minimum test cases, maximum rule coverage
Limitation Difficult for complicated systems

Structural Testing (White Box Testing)

Definition
Structural Testing is a white-box testing technique that tests the internal structure and
logic of the program, rather than its functionality.
It ensures that all statements, conditions, branches, and paths in the code are executed at least
once.

Key focus areas in Structural Testing

 Control flow of the program
 Loops
  Branches (if–else, switch)
 Logical conditions
 Data flow
 Independent paths

Structural Testing mainly includes:

 Statement Coverage
 Branch/Decision Coverage
 Condition Coverage
 Path Coverage
 DD Path Testing

✔ Purpose of Structural Testing

 To find hidden logical errors
 To ensure maximum code coverage
 To detect dead code or unreachable statements
 To validate control flow and decisions

✅ 2. Path Testing (Most Important

Structural Technique)
Definition
Path Testing is a structural testing method in which the tester identifies and executes all
possible execution paths in the program.

This helps confirm that:

 All logic is correct

 All decisions are executed
 No undefined or unreachable path exists

Path Testing uses:

 Control Flow Graph (CFG)

 Cyclomatic Complexity
 Independent paths
✔ Control Flow Graph (CFG)
A CFG is a graph where:

 Nodes = statements
 Edges = flow of control
 Decision nodes = branching points

✔ Independent Path
A path that introduces at least one new edge not included earlier.
To find the number of independent paths, we use:

Cyclomatic Complexity V(G)

Formula:

V(G) = E – N + 2

or

V(G) = Number of decision nodes + 1

This gives the minimum number of test cases for full path coverage.

✔ Example of Path Testing

Code:
1. Start
2. Read X
3. If (X > 0)
4. Print "Positive"
5. Else
6. Print "Not Positive"
7. End

CFG includes one decision → V(G) = 1 + 1 = 2 independent paths

Paths:

 P1: 1 → 2 → 3(T) → 4 → 7
 P2: 1 → 2 → 3(F) → 6 → 7
Thus, two test cases are needed.

✅ 3. DD Path (Decision-to-Decision Path)

DD-Path is an advanced form of path testing used to simplify and structure complex control
flow graphs.

Definition
A DD-Path (Decision-to-Decision Path) is a path in the program’s CFG that starts at:

 A decision node, or
 The entry node, or
 A junction node

and ends at the next decision, junction, or exit node.

This breaks the code into simple, meaningful segments for easier analysis.

✔ Why DD-Path Testing?

In large programs, testing all paths is impossible because combinations explode.
DD-Path Testing produces:

 Minimum number of paths

 Maximum meaningful coverage

It is a more refined version of path testing.

✔ DD-Path Types
1. Entry DD-Path → from program start to first decision
2. Decision DD-Path → between two decision points
3. Junction DD-Path → merge points
4. Exit DD-Path → last segment before exit
✔ DD-Path Construction Rules
 Combine all straight-line statements into one DD-path.
 Start a new path when:
o A decision occurs
o A merge/Junction occurs
o A loop begins or ends

DD-paths form the base for deriving test paths.

✔ Example of DD-Path Analysis

Code:
1. Start
2. A = input
3. If (A > 10)
4. B = A + 5
5. Else
6. B = A - 5
7. Print B
8. End

DD-Paths:

DD-Path Nodes Included Description

P1 1→2 Entry to first decision
P2 3→4 True branch path
P3 3→6 False branch path
P4 7→8 After merge to exit

Final Paths using DD Paths:

 Path 1: P1 → P2 → P4
 Path 2: P1 → P3 → P4

This matches the true and false conditions of the decision.

🔥 Why DD-Path is useful?
DD-Path:

 Reduces complexity
 Converts CFG into manageable blocks
 Helps identify independent paths clearly
 Makes path testing practical even for large programs

🔥 Difference between Path Testing and

DD-Path Testing
Path Testing DD-Path Testing
Tests all possible execution paths Tests simplified decision-to-decision paths
Complex when many conditions Reduces complexity
Based on raw CFG Based on simplified DD-Path graph
Hard for big programs Easier to analyze and test
Uses cyclomatic complexity Uses blocks of code (paths)

Cyclomatic Complexity – Full Explanation

1. Definition
Cyclomatic Complexity (CC) is a software metric used in white-box testing to measure
the complexity of a program's control flow.

It tells:

 The minimum number of test cases required to achieve complete path coverage
 The number of independent paths in the program

It was introduced by Thomas McCabe.

Data Flow Testing (White-Box Testing
Technique)
Definition
Data Flow Testing is a structural (white-box) testing technique that focuses on how
variables are defined, used, and updated (killed) throughout the program.

It checks whether:

 Variables are properly assigned (defined)

 Variables are correctly used
 Variables are not used before being assigned
 Variables are not assigned multiple times unnecessarily
 Variables are properly destroyed or no longer used

Goal:
To detect data-related bugs, such as:

 Uninitialized variables
 Unused variables
 Incorrect variable usage
 Multiple definitions
 Wrong updates

⭐ Key Concepts in Data Flow Testing

Each variable goes through 3 stages:

1. Definition (def)

The variable is assigned a value.

Example:

x = 10

2. Usage (use)

The variable is used in:

 Computation use (c-use) (e.g., in expressions)

 Predicate use (p-use) (e.g., inside IF or WHILE condition)
Example:

if (x > 0) → p-use
y = x + 5 → c-use

3. Kill (kill or undef)

When a variable:

 Goes out of scope

 Or is redefined with a new value

Example:

x = 10
x = 20 ← previous value “killed”

⭐ Data Flow Anomalies (Errors)

Anomaly Meaning
dd Defined twice without a use
du Defined → used (Correct)
du- (def → use missing) Defined but never used
ud (use before define) ERROR
dk (def → kill) Assigned but never used

These anomalies help detect logical errors directly related to variable usage.

⭐ Types of Data Flow Testing

✔ 1. All-Def Testing

Every definition of every variable must be covered by at least 1 path.

✔ 2. All-Use Testing

Every definition must reach all its uses (c-use and p-use).

✔ 3. All DU-Paths Testing (Most Comprehensive)

Every definition-to-use path for each variable must be executed.

This ensures maximum variable-flow coverage.
⭐ Example of Data Flow Testing
1. Read x
2. If (x > 0)
3. y = x + 5
4. Else
5. y = x - 5
6. Print y

Variable Flow:

Variable Definition Use

x Line 1 Line 2 (p-use)
y Line 3 or 5 Line 6 (c-use)

Data flow testing ensures:

 x must be defined before using in line 2

 y must be defined in both branches before printing

⭐ Advantages of Data Flow Testing

 Detects hidden logical errors
 Detects incorrect variable use
 Better than simple branch or statement coverage
 Finds bugs such as uninitialized variables

⭐ Limitations
 Requires understanding of code
 Not suitable for very large programs
 Time-consuming

📌 Short Summary (Exam)

Data Flow Testing validates whether variables are properly defined, used, and killed. It
uses paths between variable definitions and their uses to detect data anomalies like use-
before-define, multiple definitions, and unused definitions.

--------------------------------------------------------
---
✅ 2. Mutation Testing (White-Box Testing
Technique)
Definition
Mutation Testing is a fault-based testing technique where the program’s source code is
intentionally modified (mutated) to create slightly changed versions, called mutants, to
check if existing test cases can detect the changes.

If a test case fails after a mutation →

⭐ Mutant is killed (good test case)

If a test case does NOT fail →

❌ Mutant survives (weak test case)

⭐ Purpose of Mutation Testing

To check:

 Test case effectiveness

 Quality of tests
 Ability to detect small hidden faults

It reveals weakness in your test suite.

⭐ What is a Mutant?
A mutant is a modified version of the original program created by introducing small
changes, such as:
Mutation Operators (Common Changes)

1. Arithmetic Operator Change

+ → - , * → / , % → *

2. Logical Operator Change

&& → ||
> → <
>= → ==

3. Relational Operator Change

== → !=
> → >=

4. Constant Replacement

5 → 0

5. Statement Removal

Remove a line of code

⭐ Mutation Testing Process

Step 1 → Create Mutants

Small modifications in code.

Step 2 → Run existing test cases

Apply original test suite on modified programs.

Step 3 → Evaluate Mutants

 If test detects the fault → mutant killed

 If not → mutant survived

Step 4 → Improve test cases

Add more tests to kill surviving mutants.

⭐ Example of Mutation Testing

Original code:
if (x > 10)

Mutant created:
if (x >= 10) (operator changed)

If test case uses:

 x = 10 → mutation detected → mutant killed

 x = 11 → mutation NOT detected → mutant survives

Thus, mutation testing reveals missing test conditions.

⭐ Mutation Score
Formula:

Mutation Score = (Killed Mutants / Total Mutants) × 100

Higher score = stronger test suite.

⭐ Advantages of Mutation Testing

 Very powerful
 Reveals weak test cases
 Ensures high test quality
 Detects hidden logic errors

⭐ Limitations
 High cost (many mutants created)
 Time-consuming
 Needs automation tools
Mutation Testing creates small faults (mutants) in the program and checks whether the
existing test cases can detect them. If a test case fails for a mutant, the mutant is “killed,”
showing strong test cases. Surviving mutants indicate gaps in testing.

🎯 Need Anything More?

I can also provide:
✔ Examples for both techniques
✔ Data-flow graphs
✔ Mutation operators list
✔ Difference between Mutation Testing & Path Testing

⭐ 2. What Does Cyclomatic Complexity

Measure?
It measures:

 The number of decision points in code

 The number of linearly independent paths
 The structural complexity of the program

Higher complexity → more difficult to test, maintain, debug.

⭐ 3. Why is Cyclomatic Complexity

Important?
1. Determines number of test cases needed for path testing
2. Helps identify complex and error-prone modules
3. Helps maintain code quality
4. Detects unreachable code or missing logic

⭐ 4. Cyclomatic Complexity Formulas

✔ Formula 1: Using Edges and Nodes
V(G) = E – N + 2

Where:

 E = Number of Edges
 N = Number of Nodes
 V(G) = Cyclomatic Complexity

✔ Formula 2: Using Decision Points

V(G) = D + 1

Where:

 D = Number of decision nodes

(IF, ELSE, WHILE, FOR, CASE, AND/OR conditions)

✔ Formula 3: Using Regions

V(G) = Number of regions in flow graph

Each enclosed area = one region

⭐ 5. Example of Cyclomatic Complexity

Example Code:
1. Start
2. If (X > 0)
3. Print "Positive"
4. Else
5. Print "Not positive"
6. End

Step 1 → Count Decision Nodes

There is 1 IF decision
So,
V(G) = D + 1 = 1 + 1 = 2

This means:

✔ Minimum 2 test cases are required

✔ Two independent paths exist

Paths:

 Path 1: X > 0 (TRUE)

 Path 2: X ≤ 0 (FALSE)

⭐ 6. Cyclomatic Complexity Example with

Flow Chart
If a program has:

 3 decisions (IF / WHILE / CASE)

V(G) = 3 + 1 = 4 paths

You must create 4 test cases for full path coverage.

⭐ 7. Interpretation of Cyclomatic
Complexity Values
CC Value Meaning
1–10 Simple, easy to test
11–20 Moderate complexity
21–50 Complex, needs careful testing
>50 Very complex → redesign recommended

⭐ 8. Advantages of Cyclomatic Complexity

✔ Testing
  Determines number of path test cases
 Ensures all flows are tested

✔ Development

 Helps detect logical errors early

✔ Maintenance

 Helps identify modules that need simplification

⭐ 9. Limitations
 Does not measure data complexity
 Does not detect runtime errors
 Only measures control flow, not actual quality