Unit 1

Introduction: purpose of software testing

The primary purpose of software testing is to identify errors, faults, or omissions in a

software application compared to its specified requirements, aiming to detect defects
("bugs") and ensure the software functions as intended before it is released to users;
essentially, it's a process to verify that the developed software meets the quality
standards and functionalities outlined in the project specifications.

Key points about software testing:

Defect detection:
The main goal is to find bugs or issues in the software by executing it under different
conditions and inputs.
Quality assurances
Testing helps to ensure the software is reliable, robust, and performs as expected.
Risk mitigation:
By identifying problems early in the development cycle, testing helps to reduce the risk
of critical issues arising later in the project.
Requirement verification:
Testing verifies whether the software fulfills all the functional and non-functional
requirements defined for it.
User experience improvement:
Testing can help identify usability issues and improve the overall user experience.

Productivity of software testing

Software testing productivity is a measure of how much work is completed in a given
time period. It is calculated by comparing the value of the software produced to the cost
and effort of developing it.

Measure the productivity in software testing:-

●​ Evaluate the development environment: Consider the environment in which
the software is being developed
●​ Measure throughput: Determine how much work is being completed in a given
time period
●​ Check cycle time: Determine how long it takes to complete a cycle of work
●​ Assess lead time: Determine how long it takes to start a cycle of work
●​ Measure test case execution: Determine how many test cases are executed
per day
metrics can be used to measure the productivity in software testing:-

Defect density
The number of defects found in a specific area of the software
Total defect containment efficiency
The ratio of defects found during testing to defects found during production
Function points
A metric used to measure the amount of functionality shipped during a set period of time
Application points
A metric used to measure the amount of functionality shipped during a set period of time
Story points
A metric used to measure the amount of functionality shipped during a set period of time

Quality in software testing

quality in software testing, understanding fundamental testing concepts, different testing

types (functional, performance, usability), test design techniques, defect management,
software development life cycles (SDLC), test automation frameworks, and best
practices for ensuring quality throughout the software development process; with a
strong emphasis on critical thinking and the ability to identify potential issues in software
applications.
Key study area in quality software testing:
Software Testing Basics:
●​ What is software testing and its importance
●​ Software Development Life Cycle (SDLC) and its phases
●​ Verification vs Validation
●​ Different types of software testing (functional, non-functional, regression,
integration, system, acceptance)
●​ Test levels (unit, integration, system, acceptance)
Test Design Techniques:
●​ Black-box testing vs White-box testing
●​ Equivalence partitioning
●​ Boundary value analysis
●​ Decision table testing
●​ Use case testing
Defect Management:
●​ Defect lifecycle (identification, logging, prioritization, resolution)
●​ Defect tracking tools
●​ How to write effective defect reports
Test Automation:
●​ Benefits of test automation
●​ Test automation frameworks (Selenium, Junit, TestNG)
●​ Automation testing methodologies (keyword-driven, data-driven, BDD)
Non-Functional Testing:
●​ Performance testing (load, stress, endurance)
●​ Usability testing
●​ Security testing
Agile Testing:
●​ Agile methodologies (Scrum, Kanban)
●​ Continuous integration and continuous delivery (CI/CD)
●​ Test-driven development (TDD)

Testing Vs Debugging

Testing and debugging are both crucial aspects of software development but serve
different purposes in the software testing lifecycle. Here’s a comparison:

1. Testing

Definition: Testing is the process of evaluating a software application to ensure it meets

specified requirements and is free of defects. It aims to find and report issues in the
software.
Objective: Ensure the software works as intended under various conditions.
●​ Validate and verify the functionality, performance, and security of the application.
Who Performs It: Typically performed by dedicated QA testers or test engineers.
Methods:
●​ Manual Testing: Execution of test cases manually without tools.
●​ Automated Testing: Using tools to execute pre-defined test scripts.
Types include functional, regression, performance, security, and usability
testing.
Tools Used: Selenium, JUnit, TestNG, LoadRunner, etc
Outcome: A report detailing defects, bugs, or issues that need to be addressed.

2. Debugging

Definition: Debugging is the process of identifying, analyzing, and fixing defects or

bugs in the code.
Objective:
●​ To locate the root cause of a defect.
●​ Resolve issues to ensure the software behaves as expected.
Who Performs It: Typically performed by developers or programmers.
Process:
●​ Reproduce the issue reported during testing
●​ Use debugging tools or techniques to analyze the problem.
●​ Fix the identified defect and verify the solution.
Tools Used: Debuggers integrated into IDEs (e.g., Visual Studio, Eclipse), GDB, or
specialized debugging tools.
Outcome: Resolved defects and improved functionality of the software.

TESTING VS DEBUGGING

Aspects Testing Debugging

Definition Testing is the process to find bugs Debugging is the process of

and errors.​ correcting the bugs found during
testing.

Purpose The purpose of testing is to identify The purpose of debugging is to

defects or errors in the software fix those defects or errors.
system

Focus It is the process to identify the It is the process to give

failure of implemented code.​ absolution to code failure.

Access Testing can be done by insiders Debugging is done only by

as well as outsiders.​ insiders. An outsider can’t do
debugging

Approach Testing involves executing the Debugging involves analyzing

software system with test cases the symptoms of a problem and
identifying the root cause of the
problem

Tools and Technique Testing can involve using Debugging typically involves
automated or manual testing tools using tools and techniques such
as logging, tracing, and code
inspection

Initiation Testing is initiated after the code is Debugging commences with the
written. execution of a test case.No

Team Involve Testing is done by the tester.​ Debugging is done by either

programmer or the developer
Model for Testing

Testing and design style in software testing refers to the approaches and methodologies used to
ensure that the software is designed and tested systematically to meet user requirements,
maintain high quality, and minimize defects.

1. Waterfall Model

Description: Testing is performed after the development phase is complete.

Process:
1. Requirements analysis
2. System design
3. Implementations
4. Testing
5. Deployment
6. Maintenance

Advantages:
●​ Simple and easy to manage.
●​ Works well for small projects with clearly defined requirements.
Disadvantages:
●​ Late detection of defects.
●​ Not suitable for complex or changing requirements.

2. V-Model (Verification and Validation Model)

Description: Testing activities are planned parallel to development stages.

Process:
Corresponds to each development phase (e.g., unit testing, integration testing, system
testing, etc.).
Advantages:
●​ Early identification of defects.
●​ Each phase has specific deliverables.
Disadvantages:
●​ Rigid; changes are difficult to accommodate.
●​ Requires a clear and detailed understanding of requirements.

3. Agile Model

Description: Testing is integrated into iterative development cycles (sprints).

Process:
●​ Continuous testing and feedback within short iterations.
●​ Emphasizes collaboration between developers and testers.
Advantages:
●​ Flexible and adaptive to changes.
●​ Testing starts early, ensuring quicker defect resolution.
Disadvantages:

●​ Requires strong team communication and discipline.

●​ Difficult to measure progress in initial stages.

4. Spiral Model

Description: Combines iterative development with systematic risk analysis.

Process:
●​ Divided into four phases: planning, risk analysis, development/testing, and evaluation.
●​ Testing is done iteratively in each cycle.
Advantages:
●​ Risk-focused; suitable for large, complex projects.
●​ Early identification and mitigation of risks.
Disadvantages:
●​ High cost and time requirements.
●​ Needs highly skilled teams.

5. Incremental Model

Description: The application is developed and tested in small, manageable increments.

Process:
●​ Each increment adds functionality and is tested throughly before moving forward.
Advantages:
●​ Easier to manage smaller iterations.
●​ Early delivery of partially functional software.
Disadvantages:
●​ Integration issues may arise with multiple increments.
●​ Requires clear and modular design.

6. Big Bang Model

Description: Testing is performed only after all development is complete.

Process:
●​ Focuses on combining and testing the entire system at once.
Advantages:
●​ Suitable for small projects with minimal requirements.
Disadvantages:
●​ High risk of major defects.
●​ Difficult to trace the root cause of issue
7. Hybrid/Custom Models

Description: Combines elements from various models to suit specific project needs.
Advantages:
●​ Tailored to fit unique requirements.
●​ Combines the strengths of multiple models.

Disadvantages:
●​ Complexity in defining and managing custom processes.

Bugs

●​ The Bug is the informal name of defects, which means that software or application is not
working as per the requirement.
●​ In software testing, a software bug can also be issue, error, fault, or failure. The bug
occurred when developers made any mistake or error while developing the product.

In software testing, the bug can occur for the following reasons:

●​ Wrong coding
●​ Missing coding
●​ Extra coding

Wrong coding

●​ Wrong coding means improper implementation.

●​ For example: Suppose if we take the Gmail application where we click on the "Inbox"
link, and it navigates to the "Draft" page, this is happening because of the wrong coding
which is done by the developer, that's why it is a bug.

Missing coding

●​ missing coding means that the developer may not have developed the code only for that
particular feature.
●​ For example: if we take the above example and open the inbox link, we see that it is not
there only, which means the feature is not developed only.

Extra coding

●​ extra coding means that the developers develop the extra features, which are not
required according to the client's requirements.
Types of bugs

There are many types of bugs in software testing:

●​ Functional bugs
●​ Security bugs
●​ Usability bugs
●​ Integration bugs
●​ Logic bugs
●​ Performance bugs
●​ Unit level bugs
●​ Syntax bugs

Functional bugs

●​ A feature of the software doesn't work as expected. For example, a button that doesn't
open a new window when clicked.

Security bugs

●​ A vulnerability that allows unauthorized access to the system, which could lead to data
theft or other malicious actions.

Usability bugs

●​ Issues that make it difficult for users to interact with the software, such as unclear error
messages or a confusing user interface.

Integration bugs

●​ When two or more modules or systems don't interact as expected. These bugs can be
difficult to fix because they involve large amounts of code.
Logic bugs

●​ A flaw in the algorithm or logic used in the code. This can cause the software to behave
unexpectedly.

Performance bugs

●​ Issues that affect the efficiency of the software, such as slow loading speeds.

Unit level bugs

●​ Bugs that occur in a relatively small amount of code, making them easier to isolate and
fix.

Syntax bugs

●​ Unintentional errors that appear in the source code of a program, preventing it from
being compiled.

Testing and Design Style

●​ In software testing, testing and design styles refer to approaches and practices
used to ensure the quality of the software while integrating it into the overall
software design and development process.
●​ These styles are influenced by methodologies, tools, and techniques aimed at
validating software functionality, performance, and reliability. Here's a breakdown:

Testing Styles

1. Black Box Testing

●​ Focuses on testing the functionality of the software without considering its

internal code structure.
●​ Testers only consider inputs and expected outputs.
●​ Types: Functional Testing, Non-Functional Testing (e.g., performance, usability).

2. White Box Testing

●​ Examines the internal workings and logic of the application.
●​ Requires knowledge of the code and focuses on code coverage, paths, loops,
and conditions.
●​ Types: Unit Testing, Integration Testing.
3. Gray Box Testing

●​ Combines aspects of both black-box and white-box testing.

●​ Testers have partial knowledge of the internal structure and access to the
system's internals for more informed test cases.

4. Manual Testing

●​ Test cases are executed by humans without automation.

●​ Useful for exploratory, usability, and ad hoc testing.

5. Automated Testing

●​ Involves the use of tools and scripts to execute test cases.

●​ Best for regression, load, and performance testing.
●​ Examples: Selenium, JUnit, Cypress.

6. Exploratory Testing

●​ Simultaneously designs and executes tests while exploring the software.

Focuses on discovering unknown issues.

7. Regression Testing

●​ Verifies that new changes or updates have not adversely affected existing
functionality.

8. Performance Testing

●​ Tests the system's performance, such as speed, scalability, and stability, under
various conditions.

Design Styles in Testing

1. Test-Driven Development (TDD)

●​ A development style where tests are written before the actual code.
●​ Helps to define requirements clearly and ensures minimal defects.
2. Behavior-Driven Development (BDD)

●​ Focuses on testing the system's behavior from the end-user perspective.

●​ Utilizes tools like Cucumber and Gherkin to write tests in natural language.

3. Acceptance Test-Driven Development (ATDD)

●​ Similar to TDD but focuses on user acceptance criteria.

●​ Collaboration between developers, testers, and stakeholders ensures alignment.

4. Model-Based Testing

●​ Generates test cases from models of the system (state machines, activity
diagrams).
●​ Efficient for systems with complex logic.

5. Risk-Based Testing

●​ Focuses testing efforts on areas of the system with the highest risk of failure or
impact on business.

6. Continuous Testing

●​ Integrated into the CI/CD pipeline to ensure quality throughout development.

●​ Allows for real-time feedback and faster iterations.
 UNIT 2

Flow, Graph, and Path Testing in Software Testing

Flow testing, graph-based testing, and path testing are structural (white-box) testing
techniques that use graphical representations of program logic to identify test cases.
These methods help ensure that all possible execution paths in a program are tested.

Flow Testing
●​ Flow testing is a general approach that analyzes control flow within a program. It
involves:
●​ Control Flow Analysis: Checking loops, conditionals, and function calls.
●​ Data Flow Analysis: Tracing how data moves through the program.
●​ State Transitions: Ensuring correct state changes.

Key Techniques
●​ Control Flow Graph (CFG): Represents the logic of a program using nodes
(statements) and edges (flow of execution).
●​ Decision Coverage: Ensures all decisions (if-else, loops) are executed.
●​ Loop Testing: Focuses on loop conditions and boundaries.

Graph-Based Testing
Graph-based testing uses graphical representations like flowcharts or state transition
diagrams to model the logic of a system.

Types of Graphs Used

●​ Control Flow Graph (CFG): Shows program execution paths.
●​ Data Flow Graph (DFG): Tracks variables and their changes.
●​ State Transition Diagram (STD): Represents system states and transitions
Graph-Based Test Techniques
●​ Node Coverage: Ensures every node (statement) is executed.
●​ Edge Coverage: Ensures every edge (transition between statements) is tested.
●​ Path Coverage: Covers independent paths to detect logic errors.
●​ State Transition Testing: Used for testing finite-state machines.

Path Testing

Path testing focuses on finding independent execution paths through a program to

detect potential defects.
Steps in Path Testing

1. Create a Control Flow Graph (CFG).

2. Identify Independent Paths (paths that introduce new logic).
3. Calculate Cyclomatic Complexity (McCabe's Complexity):
Formula: V(G) = E - N + 2P
E = Number of edges
N = Number of nodes
P = Number of connected components (typically 1 for a single function)
4. Derive Test Cases from independent paths.
5. Execute Test Cases to ensure all logic flows are covered.

Path Testing Techniques

●​ Basis Path Testing: Ensures all independent paths are tested.
●​ Predicate Testing: Verifies logical conditions (e.g., nested if statements).
●​ Loop Testing: Focuses on different loop conditions (zero iterations, one iteration,
multiple iterations).
Example: Control Flow Graph (CFG)
Consider the following code:
if (A > B) {
C = A - B;
} else {
C = A + B;
}
print(C);

Corresponding Control Flow Graph

(Start)
|
(A>B?)
/ \
Yes No
| |
C=A-B C=A+B
\ /
(print C)
|
(End)
For this program:

●​ Nodes: Start, Decision (A > B), Two Assignments, Print, End.

●​ Edges: Execution flows connecting the nodes.
●​ Paths: (Start → A>B? → Yes → Print → End), (Start → A>B? → No → Print →
End)
●​ Path testing ensures both branches (A > B and A <= B) are tested.

Achievable Paths

In software testing, achievable paths refer to the different possible execution routes that
can be taken through a program or system based on various inputs, conditions, and
decision points. This concept is crucial in structural (white-box) testing, especially when
performing techniques like path testing or control flow testing.

Key Concepts of Achievable Paths:

1. Control Flow Graph (CFG):

●​ A graphical representation of all the paths a program can take during execution.
●​ Nodes represent statements or conditions, and edges represent the flow of
control.
2. Path:
●​ A sequence of nodes and edges in the control flow graph, representing the
execution flow from the start to the end of the program.
3. Achievable (Feasible) Path:
●​ A path that can actually be executed with some combination of inputs.
●​ Not all paths in the control flow graph are achievable because some may depend
on impossible conditions (e.g., contradictory conditions).
4. Unachievable (Infeasible) Path:
●​ A path that cannot be executed, no matter what input is provided.
●​ This may occur due to logical contradictions or program constraints.

Why Are Achievable Paths Important?

●​ Complete Test Coverage: Ensuring that all feasible paths are tested helps
identify hidden bugs.
●​ Optimizing Test Cases: Focus on paths that can actually occur, avoiding wasted
effort on infeasible paths.
●​ Improved Software Quality: Detects edge cases and complex logic errors.
Example:

def check_number(x):
if x > 0:
print("Positive")
else:
if x == 0:
print("Zero")
else:
print("Negative")

Possible Paths (from start to end):

1. Path A: x > 0 → print "Positive"
2. Path B: x <= 0 AND x == 0 → print "Zero"
3. Path C: x <= 0 AND x != 0 → print "Negative"
All three are achievable paths because we can find values of x (e.g., 1, 0, -1) to satisfy
each condition.

How to Identify Achievable Paths:

1. Create a Control Flow Graph (CFG).

2. Analyze Decision Points (if, switch, loops).
3. Identify all theoretical paths.
4. Determine if each path is achievable by finding corresponding inputs.

Common Testing Techniques Involving Achievable Paths:

●​ Basis Path Testing: Focuses on achieving maximum path coverage by identifying

a set of linearly independent paths.
●​ Decision Coverage (Branch Testing): Ensures that every decision condition is
tested with both true and false outcomes.
●​ Condition Coverage: Tests all boolean conditions within decisions.
 Path Instrumentation in Application Transaction Flow Testing
Techniques

Path Instrumentation is a technique used in software testing to monitor and analyze the
execution paths of an application. It helps in identifying performance bottlenecks,
debugging issues, and ensuring proper transaction flow.

Application Transaction Flow Testing

This type of testing ensures that transactions within an application are executed
correctly, following the intended workflow. It is widely used in banking, e-commerce, and
enterprise applications where data integrity and process accuracy are critical.

Techniques Used in Path Instrumentation for Transaction Flow Testing :-

1. Code Instrumentation

●​ Inserting special logging or monitoring statements in the code to track execution

paths.
●​ Used for performance analysis and debugging.

2. Runtime Monitoring

●​ Capturing real-time data on function calls, loops, and decision branches.

●​ Helps in detecting unexpected deviations in transaction flow.

3. Control Flow Analysis

●​ Examines the sequence of execution paths to ensure all possible paths are
tested.
●​ Identifies untested or dead code sections.

4. Automated Logging & Reporting

●​ Records transaction flow logs for later analysis.

●​ Helps in debugging errors and optimizing performance.
5. Coverage-Based Testing

●​ Ensures maximum path coverage by analyzing executed and non-executed

paths.
●​ Helps in achieving complete transaction validation.

6. Load & Performance Testing

●​ Simulating multiple transactions to measure response time and system stability.

●​ Identifies bottlenecks and inefficiencies.

7. Error Path Testing

●​ Checks how the system behaves under failure conditions.

●​ Ensures proper error handling and recovery mechanisms.

Benefits of Path Instrumentation in Transaction Flow Testing

●​ Improves application reliability and performance.

●​ Helps in early defect detection.
●​ Ensures transaction integrity and correctness.
●​ Provides better insights into system behavior under different conditions.

UNIT 3

Data Flow Testing Strategies

Data Flow Testing is a structural testing technique that focuses on the flow of data within
a program. It examines the points where variables receive values (definitions) and
where those values are used (uses) to detect anomalies like uninitialized variables,
unused variables, and incorrect variable usage.

Key Concepts in Data Flow Testing

●​ Definition (def): When a variable is assigned a value.

●​ Use (use): When a variable is read or used in computations.
●​ DU Chain (Definition-Use Chain): The path between a variable’s definition and its
corresponding use.
Types of Data Flow Testing Strategies

1. All-Defs (All Definitions Coverage)

●​ Ensures that every defined variable is used at least once in some execution path.
●​ Helps detect unused or redundant variable assignments.

2. All-Uses Coverage

●​ Ensures that every variable definition reaches all its possible uses.
●​ Covers both computation uses (c-use) and predicate uses (p-use).
●​ C-use (Computational Use): When a variable is used in calculations or
assignments.
●​ P-use (Predicate Use): When a variable is used in decision-making (e.g., in
if-conditions, loops).

3. All DU Paths (All Definition-Use Paths Coverage)

●​ Tests all possible paths between a variable’s definition and its uses.
●​ Ensures thorough testing of data flow dependencies.
●​ Helps detect issues like unintended variable modifications and memory leaks.

4. All-P-Uses Coverage

●​ Focuses on covering all predicate uses of variables in decision-making

statements.
●​ Ensures that variables affecting program control flow are tested thoroughly.

5. All-C-Uses Coverage

●​ Focuses on covering all computational uses of variables.

●​ Ensures that every variable involved in calculations has been tested.

Benefits of Data Flow Testing

●​ Detects uninitialized variables and incorrect variable usage.

●​ Improves code reliability and maintainability.
●​ Identifies redundant computations and memory leaks.
●​ Enhances test coverage beyond traditional control flow testing.
Domain Testing: Domains and Paths

Domain Testing is a software testing technique that focuses on checking how a program
behaves with different input values. It is useful for validating input boundaries,
equivalence classes, and error conditions.

Domains in Domain Testing

A domain refers to a set of valid input values for a program or function. It helps in
identifying test cases that cover all possible inputs systematically.

Types of Domains

1. Single-Dimensional Domains
●​ Inputs that vary along one dimension (e.g., a range of integers like 1 to 100).

2. Multi-Dimensional Domains
●​ Inputs that depend on multiple factors (e.g., (x, y) coordinates in a 2D plane).

3. Open and Closed Domains

●​ Open Domains: Do not include boundary values (e.g., 0 < x < 10).
●​ Closed Domains: Include boundary values (e.g., 0 ≤ x ≤ 10).

Paths in Domain Testing

A path refers to a sequence of execution flows in a program based on different input

domains. Domain testing ensures that all important paths are tested, especially at
boundary values and critical input ranges.

Path Testing in Domain Testing

1. Valid Path Testing

Ensures that inputs within the defined domain follow the expected execution flow.

2. Invalid Path Testing

●​ Tests how the system behaves when inputs fall outside the allowed domain.
3. Boundary Path Testing
●​ Focuses on values at the edges of the domain (e.g., minimum, maximum, just
inside, just outside).

4. Decision-Based Path Testing

●​ Tests paths that depend on conditions and branching (e.g., if-else statements).

Example of Domain and Path Testing

Example Scenario:

A function accepts input x in the range 1 to 100 and returns "Valid" if x is within the
range, otherwise "Invalid".

Test Domains:

●​ Valid Inputs: {1, 50, 100} (inside the domain)

●​ Invalid Inputs: {0, 101} (outside the domain)
●​ Boundary Values: {1, 100} (edge cases)

Test Paths:

●​ Path 1: Input x = 50 → Execution follows "Valid" path.

●​ Path 2: Input x = 0 → Execution follows "Invalid" path.
●​ Path 3: Input x = 100 → Execution follows "Valid" path (boundary test).

Domains and Interface Testing

Domains in Software Testing

A domain in software testing refers to a specific area or category where software

applications are developed and tested. Some common domains include:
●​ Banking & Finance (e.g., online banking, payment gateways)
●​ Healthcare (e.g., hospital management, medical devices)
●​ E-commerce (e.g., online shopping, inventory management)
●​ Education (e.g., learning management systems, school portals)
●​ Telecom (e.g., mobile networks, billing systems)
●​ Gaming (e.g., video games, multiplayer platforms)
●​ Cybersecurity (e.g., antivirus software, firewalls)
●​ Each domain has unique testing requirements based on its functionality, security,
and user expectations.
Interface Testing

●​ Interface Testing is a type of software testing that checks how two different
systems or components communicate with each other. It ensures that data flows
correctly and that the interaction between modules works as expected.

Types of Interfaces in Software Testing

●​ User Interface (UI) – Ensures a smooth experience for users (buttons, forms,
navigation).
●​ Application Programming Interface (API) – Tests communication between
applications via API calls.
●​ Database Interface – Verifies database connections, queries, and data retrieval.
●​ Hardware Interface – Ensures proper interaction between software and physical
devices.

What to Test in Interface Testing?

●​ Data transfer between components
●​ Error handling and messages
●​ Performance and response time
●​ Security (e.g., access control, data encryption)

Tools Used for Interface Testing

●​ Postman (for API testing)
●​ Selenium (for UI testing)
●​ JMeter (for performance testing)

UNIT 4

Linguistic
"Linguistic" means related to language and communication.
Importance in software testing
●​ Software testing is not just about checking the software.
●​ It also needs good communication using clear and correct language.
Linguistic used in Testing
1. Writing Test Cases
●​ Test cases must be written clearly.
●​ Example:
Bad: "Check login."
Good: "Check if the user can log in with correct username and password."
2. Understanding Requirements
●​ Requirements are often written in normal language.
●​ Testers must read and understand them properly.

3. Reporting Bugs
●​ Bug reports must be clear and simple.
●​ Developers need to understand the issue easily.

4. Team Communication

●​ Testers talk with developers, designers, and clients.

●​ Clear communication avoids mistakes and saves time.

Example: Bug Report

Bad: "App not work properly."
Good: "The app crashes when the user clicks 'Submit' without entering data.”

Metrics

●​ Metrics are measurements that help us understand how well the software testing
process is working.
●​ They give us numbers and data to check quality, progress, and performance.

Importance of metrics

●​ To track testing progress

●​ To measure software quality
●​ To find problems early
●​ To improve the testing proces
●​ To make better decisions

Types of Metrics in Software Testing

1. Test Case Metrics

●​ Total number of test cases

●​ Test cases passed
●​ Test cases failed
●​ Test cases not run
2. Defect Metrics (Bug Metrics)

●​ Total number of defects (bugs)

●​ Severity of defects (High/Medium/Low)
●​ Defects fixed
●​ Defects re-opened

3. Test Execution Metrics

●​ % of test cases executed

●​ % of tests passed/failed
●​ Time taken to test

4. Product Quality Metrics

●​ Number of bugs found after release

●​ Customer-reported issues

Example:

●​ If 100 test cases were written and 90 passed, we can say:

●​ 90% pass rate
●​ We still need to fix or retest the remaining 10%

Structural Metrics

Structural metrics focus on the design and architecture of the software, analyzing its
internal structure and complexity. These metrics help in assessing maintainability and
testability.
Examples of Structural Metrics:
Cyclomatic Complexity (McCabe’s Complexity):
●​ Measures the complexity of a program based on the number of independent
paths in the control flow graph.
Formula:
V(G) = E - N + 2P
E = Number of edges
N = Number of nodes
P = Number of connected components
Depth of Inheritance Tree (DIT):

●​ Measures the hierarchy level of a class in object-oriented programming.

Coupling and Cohesion:

●​ Coupling: Measures interdependence between modules (lower is better).

●​ Cohesion: Measures how well functions within a module are related (higher is
better).

Path Products and Path Expressions

Path analysis is used to evaluate the execution flow in a program, ensuring all possible
paths are tested.

Path Products:

●​ Represent the execution flow in a program using algebraic expressions.

●​ A path product consists of nodes (statements) and edges (transitions) in the
control flow graph.

●​ Example:If a program has a decision point (if-else condition), it will have two
paths:
1. Path A → B → C
2. Path A → D → E

●​ Using path products, we express the execution flow as:

P_1 = A \cdot B \cdot C
P_2 = A \cdot D \cdot E ]

Path Expressions:

●​ A path expression represents all possible paths in a program in algebraic form.

●​ It is derived by combining path products into a single expression.
●​ Example: For the above case, the path expression is:
●​ P = A \cdot (B \cdot C + D \cdot E)
Applications of Path Products & Path Expressions:

●​ Used in test case generation to ensure all paths are covered.

●​ Helps in cyclomatic complexity calculation.
●​ Assists in program verification and debugging.

Syntax Testing

Definition:

●​ Syntax Testing is a type of software testing used to check if the input values
follow the correct format or rules.
●​ The goal is to make sure the system accepts valid inputs and rejects invalid
ones.

Purpose:

To test how well the software handles input validation and to ensure that users cannot
enter wrong or harmful data.

Example:

Let’s say a form asks for an email address:

●​ Valid Input: [email protected] → System should accept it
●​ Invalid Input: user123gmail.com → System should show an error (missing @)

Where Syntax Testing is used:

●​ Login forms
●​ Signup forms
●​ Payment gateways
●​ Online applications
●​ Anywhere user input is required

Formats in Syntax Testing

What is a Format?
●​ A format means the correct structure or pattern that an input must follow.
●​ In syntax testing, we check if the input matches the required format.
Common Input Formats to Test:

1. Email Format
Example:
●​ [email protected]
●​ Must contain @ and a domain
●​
2. Phone Number Format
Example:
●​ 9876543210
●​ Usually 10 digits, only numbers
●​
3. Date Format
Example:
●​ 25/12/2025
●​ Format: DD/MM/YYYY
●​
4. PIN Code Format
Example:
●​ 638008
●​ 6 digits, no letters or symbols

5. Password Format
Example:
●​ Test@1234
●​ Minimum 8 characters, with letters, numbers, symbols

Formats Matter:
●​ If users enter the wrong format, the system may not work properly. Syntax testing
checks these formats and ensures only valid inputs are accepted.

Test Cases in Syntax Testing

●​ A test case is a step-by-step instruction used to test a specific function or feature

in the software.
●​ In syntax testing, test cases are written to check whether the input follows the
correct format.
What to Include in a Test Case:

1. Input value
2. Expected result
3. Actual result (after testing)
4. Pass/Fail status

Simple Examples of Syntax Test Cases:

Test Case 1:
●​ Input: [email protected]
●​ Expected Result: Accepted (valid email format)
Test Case 2:
●​ Input: johnexample.com
●​ Expected Result: Rejected (missing @ symbol)
Test Case 3:
●​ Input: 9876543210
●​ Expected Result: Accepted (valid phone number)
Test Case 4:
●​ Input: 1234A67890
●​ Expected Result: Rejected (letters not allowed in phone number)

Why Write Test Cases ?

●​ To make sure the system works correctly with valid data

●​ To check that the system shows error for wrong format
●​ To ensure data safety and accuracy

UNIT 5

Logic-Based Testing

What is Logic-Based Testing?

●​ Logic-Based Testing is a type of software testing where we test the logical

conditions and decisions in a program.
●​ It checks if the software behaves correctly when different true/false (yes/no)
conditions are used.
Why is it Important?

●​ To make sure all logical paths (like if-else, conditions) work correctly
●​ To find errors in decision-making in the code
●​ To check how the software reacts to different situations

Example:

Suppose a login form checks this logic:

●​ > If username and password are correct → Login successful
●​ Else → Show error message
Logic-Based Testing will test both cases:
●​ Correct username and password
●​ Wrong username or password

Where It's Used:

●​ In programs with conditions, loops, decisions
●​ When we want to test every possible outcome of the logic
●​
Common Techniques in Logic-Based Testing:

1. Decision Coverage – Tests all the true/false outcomes of conditions

2. Condition Coverage – Tests all parts of a condition separately
3. Path Testing – Tests all possible paths through the code

Decision Tables

What is a Decision Table?

●​ A Decision Table is a simple way to show different conditions and their related
actions.
●​ It helps in testing complex logic where there are multiple conditions and different
outcomes.

Why Use a Decision Table?

●​ To make decisions clear and organized

●​ To test all possible combinations of conditions
●​ To avoid missing any important logic or rule
Parts of a Decision Table:

1. Conditions – The inputs or rules (true/false or yes/no)

2. Actions – What the system should do
3. Rules – Combination of condition values that lead to a specific action

Simple Example:

Let’s say a system gives a discount only if:

●​ Customer is a member
●​ Purchase amount is above ₹1000
We can create a decision table like this (written simply, without a table):

●​ Case 1: Member = Yes, Amount > 1000 → Give Discount

●​ Case 2: Member = Yes, Amount ≤ 1000 → No Discount
●​ Case 3: Member = No, Amount > 1000 → No Discount
●​ Case 4: Member = No, Amount ≤ 1000 → No Discount
●​
Where it is used:

●​ In testing business rules

●​ In systems with multiple conditions
●​ In logic-based testing

Transition Testing

What is Transition Testing?

●​ Transition Testing is used to test how the software moves (transitions) from one
state to another.
●​ It checks if the system behaves correctly when certain actions cause a change in
state.

What is a State?
●​ A state is the condition of the system at a specific time.
●​ Example: Logged Out, Logged In, Payment Done, Order Placed, etc.
Why Use Transition Testing?

●​ To check if the system changes states correctly

●​ To test valid and invalid transitions
●​ To ensure all possible paths work as expected

Example: Login System

States:
●​ Logged Out
●​ Logged In

Transitions:

●​ Enter correct username/password → Move to "Logged In"

●​ Click logout → Move to "Logged Out"
●​ Enter wrong credentials → Stay in "Logged Out"

Transition Testing will check:

●​ What happens when the user logs in?

●​ What happens when the user logs out?
●​ What if the login fails?

Used In:

●​ ATM machines (Insert card → Enter PIN → Select operation → Eject card)
●​ Online shopping (Add to cart → Checkout → Payment → Order confirmed)
●​ Mobile apps and websites with navigation

States

●​ A State is the current situation or status of a system at a given time.

●​ It changes when an event happens or the user performs an action.
Examples of States:

In a Login System:

●​ State 1: Logged Out

●​ State 2: Logged In
In an ATM:

●​ Card Not Inserted

●​ Card Inserted
●​ PIN Entered
●​ Transaction Completed
●​ Card Ejected

In a Shopping App:

●​ Browsing Products
●​ Product Added to Cart
●​ Checkout
●​ Payment Completed
●​ Order Shipped

State Graph

A State Graph is a diagram that shows:

●​ States (as circles or boxes)

●​ Transitions (as arrows from one state to another)
●​ It helps visualize the behavior of a system and how it reacts to user actions.

Components of a State Graph:

1. Initial State: Where the system starts

2. Final State: Where the system ends
3. Transitions: The action or input that causes the state to change
4. Events: The user actions that trigger transitions

Example (Login System):

●​ Initial State: Logged Out

●​ Action: Enter correct username and password
●​ New State: Logged In
●​ Action: Click Logout
●​ New State: Logged Out again
Graph (Text Format):

[Logged Out] --(Login success)--> [Logged In]

[Logged In] --(Logout)--> [Logged Out]

State Testing

●​ State Testing is a type of black-box testing used when the software has different
states and transitions.

What Do We Test?

●​ Valid transitions → Does the system move to the correct state?

●​ Invalid transitions → What happens if the user tries something wrong?
●​ All possible paths → Are all the state changes tested?

Example Scenario: ATM Machine

States:

1. Idle
2. Card Inserted
3. PIN Entered
4. Transaction Done
5. Card Ejected

Transitions:

●​ Insert Card → Move to "Card Inserted"

●​ Enter Correct PIN → Move to "PIN Entered"
●​ Withdraw Cash → Move to "Transaction Done"
●​ Eject Card → Back to "Idle"

Benefits of State Testing:

●​ Helps find navigation errors

●​ Covers real user scenarios
●​ Ensures the software responds correctly in every state
●​ Improves overall reliability and quality