Unit – I: Software Testing and Testing Methods

1.1 Software Testing

Definition
Software Testing is the process of evaluating and verifying a software application to ensure
that it functions according to specified requirements and to identify errors, defects, or missing
functionality.
Explanation
Software testing is a critical phase in the Software Development Life Cycle (SDLC). It
ensures that the developed software performs correctly, efficiently, and securely before it is
delivered to users.
When developers write software code, there may be mistakes due to incorrect logic,
misunderstanding of requirements, integration issues, or unexpected user inputs. Software
testing helps detect these problems so that they can be corrected before the software is released.
Testing checks different aspects of software such as:
• Functionality: Whether the software performs the intended tasks.
• Performance: Whether the system responds quickly and efficiently.
• Usability: Whether the software is easy for users to understand and operate.
• Security: Whether the system protects sensitive data.
• Reliability: Whether the system works consistently without crashing.
Software testing can be done manually by testers or automatically using testing tools. Proper
testing improves software quality, reduces maintenance cost, and increases customer
satisfaction.
Real-Time Example
Consider an online shopping website such as Amazon.
When a user places an order, the following things must work correctly:
1. The product should be added to the cart.
2. The payment should be processed successfully.
3. The order confirmation message should be displayed.
4. The order details should be saved in the database.
If the payment is deducted but the order is not placed, it means there is a bug in the system.
Testing helps identify such problems before customers use the system.
Objectives of Testing
Definition
Objectives of testing refer to the goals or purposes of performing software testing to ensure the
quality, reliability, and correctness of the software system.
Explanation
The main objective of software testing is to verify that the software works according to the
specified requirements and to detect defects before the software is delivered to users.
Testing helps developers and organizations ensure that the software system is reliable, secure,
and user-friendly.
The major objectives of testing include:
1. Finding defects Testing helps identify bugs and errors in the software.
2. Verifying requirements Ensures that the software meets the requirements specified in
the SRS document.
3. Improving software quality Testing helps improve the reliability and performance of
software.
4. Ensuring user satisfaction Software should work correctly and be easy to use.
5. Preventing future failures Detecting defects early reduces the risk of system failure
after deployment.
Real-Time Example
Consider a bank ATM system.
Objectives of testing the ATM system include:
• Ensure correct PIN verification.
• Ensure correct cash withdrawal amount.
• Ensure transaction records are updated.
• Ensure the system works even during heavy usage.
If testing finds that the ATM dispenses incorrect cash amounts, the defect can be fixed before
the system is used by customers.
Software Requirement Specification (SRS)
Definition
Software Requirement Specification (SRS) is a detailed document that describes the functional
and non-functional requirements of a software system.
Explanation
The SRS document acts as a blueprint for software development. It clearly defines what the
software system should do and how it should perform.
This document is prepared during the requirement analysis phase of the software
development process and serves as an agreement between the client and the development
team.
The SRS document helps developers, testers, and project managers understand the system
requirements and ensures that the final software product meets the customer's expectations.
An SRS document typically includes:
• Functional Requirements Features and operations the software must perform.
• Non-Functional Requirements Performance, security, usability, and reliability
requirements.
• System Constraints Hardware or software limitations.
• User Interface Requirements How users interact with the system.
• System Behaviour How the system responds to inputs and conditions.
The SRS document is very important because testing is performed based on the
requirements defined in the SRS.
Real-Time Example
Consider developing a college online admission system.
The SRS document may include requirements such as:
• Students should be able to register online.
• Students should upload required documents.
• The system should generate a unique application number.
• Payment of admission fees should be processed online.
Testers will use this SRS document to verify whether the developed system performs all these
functions correctly.
1.2 Failure, Error, Fault, Defect, Bug Terminology
Failure
Definition
Failure is the inability of a software system or component to perform its required function
according to the specified requirements.
Explanation
A failure occurs when the software system does not behave as expected during execution. It is
the visible result of a problem in the system. Failures usually occur when a defect or fault in
the software is triggered during program execution.
Failure is noticed by the user or tester when the system produces incorrect results, crashes, or
behaves unexpectedly.
Failures can affect system performance, reliability, and user satisfaction.
Real-Time Example
Consider an online payment system.
A user tries to transfer ₹5000 from one bank account to another.
• The amount is deducted from the sender's account.
• But it is not credited to the receiver’s account.
This situation is called a software failure because the system did not perform the transaction
correctly.

Error
Definition
An error is a human mistake made during software development such as incorrect logic,
misunderstanding of requirements, or incorrect coding.
Explanation
Errors occur when developers, designers, or analysts make mistakes while writing code,
designing algorithms, or understanding system requirements.
Errors are the root cause of faults and defects in the software system. If an error remains
undetected, it may lead to incorrect program behavior.
Errors may occur in:
• Requirement analysis
• Design phase
• Coding phase
 • Documentation
Real-Time Example
Suppose a developer writes a program to calculate interest using the formula:
Interest = Principal × Rate × Time
But mistakenly writes the formula as:
Interest = Principal × Rate ÷ Time
This mistake is called an error because it occurred due to incorrect logic by the developer.

Fault
Definition
A fault is a defect in the software code or design that occurs due to an error made by a
developer.
Explanation
A fault is the incorrect implementation of software caused by a human error. It exists in the
program code or system design.
A fault may remain hidden in the system until the program is executed with specific input
conditions.
When a fault is executed during program execution, it may lead to a failure.
Thus the relationship is:
Error → Fault → Failure
Real-Time Example
Suppose a program should check:
if (age >= 18)
But the developer mistakenly writes:
if (age > 18)
Because of this mistake, a person with age 18 will not be allowed.
This incorrect condition in the program is called a fault.

Defect
Definition
A defect is a flaw or deviation in the software system that causes it to produce incorrect or
unexpected results.
Explanation
A defect is identified during testing when the actual result of the software differs from the
expected result.
Defects can occur due to errors in:
• Requirement specification
• System design
• Program coding
• Integration of modules
When testers find defects, they report them to developers so that they can fix the problem.
Defects are usually recorded in bug tracking systems.
Real-Time Example
In a college result management system, if the system calculates a student's percentage
incorrectly due to a wrong formula in the program, it is considered a defect.

Bug
Definition
A bug is an informal term used to describe a defect or flaw in a software program that causes
incorrect or unexpected behaviour.
Explanation
The term bug is commonly used by programmers and testers to refer to defects found in the
software.
When testers identify a problem in the system during testing, they report it as a bug report.
Developers then analyze the bug, fix the problem in the code, and verify the fix.
Bug tracking tools such as JIRA, Bugzilla, and Redmine are commonly used in software
development.
Real-Time Example
In a mobile banking application, if the login page accepts an incorrect password and still
allows the user to log in, it is considered a bug because the system behavior is incorrect and
insecure.
Relationship Between Terms
In software testing these terms are connected in the following sequence:
Human Mistake → Error → Fault → Defect → Failure
Example Flow:
Developer writes wrong code → Error
Wrong code present in program → Fault
Tester finds incorrect behavior → Defect / Bug
System crashes during execution → Failure
1.3 Test Case, Entry and Exit Criteria for Testing
Test Case
Definition
A Test Case is a set of conditions, inputs, actions, and expected results used to verify whether
a particular feature of the software works correctly.
Explanation
A test case is a basic unit of testing used by testers to check the functionality of a software
system. It describes what to test, how to test, and what the expected result should be.
Test cases are designed based on the Software Requirement Specification (SRS) document.
Each test case focuses on verifying one specific functionality of the system.
A typical test case contains the following components:
• Test Case ID – Unique identifier for the test case
• Test Description – What feature is being tested
• Preconditions – Conditions required before executing the test
• Test Steps – Steps to perform the test
• Test Data – Input values used in the test
• Expected Result – Correct output expected from the system
• Actual Result – Output generated by the system
• Status – Pass or Fail
Test cases help ensure that all system requirements are properly tested.
Real-Time Example
Example: Login Function of a Website

Test Case
Test Steps Test Data Expected Result
ID

Enter valid username and

TC01 user123 / pass123 Login successful
password

user123 / Error message

TC02 Enter invalid password
wrongpass displayed

This helps testers verify whether the login system works correctly.
Entry Criteria
Definition
Entry Criteria are the conditions that must be satisfied before starting the testing process.
Explanation
Entry criteria ensure that the testing process starts only when the software is ready for testing.
These criteria define the requirements and conditions that must be fulfilled before test
execution begins.
If entry criteria are not satisfied, testing may produce incorrect results or waste time and
resources.
Common entry criteria include:
• Requirement documents (SRS) should be approved.
• Test plan should be prepared.
• Test cases should be designed and reviewed.
• Testing environment should be ready.
• Required test data should be available.
• Software build should be delivered by developers.
These conditions help testers begin the testing process effectively.
Real-Time Example
Consider testing a mobile banking application.
Before testing begins:
• The development team must provide the application build.
• Test cases for login, balance check, and fund transfer must be prepared.
• The testing environment must be ready.
Only after these conditions are satisfied can testing start.
Exit Criteria
Definition
Exit Criteria are the conditions that must be fulfilled before the testing process can be stopped
or considered complete.
Explanation
Exit criteria determine when the testing process should end. These criteria help ensure that the
software has been tested adequately and meets the required quality standards.
Testing is usually completed when the defined exit criteria are achieved.
Common exit criteria include:
• All planned test cases have been executed.
• All critical defects have been fixed.
• Defect rate is within acceptable limits.
• Test coverage requirements are achieved.
• Test reports are prepared.
• Stakeholders approve the software release.
Exit criteria help ensure that the software is ready for deployment and use by customers.
Real-Time Example
Consider a college admission management system.
Testing may stop when:
• All test cases for registration, login, document upload, and fee payment are executed.
• All major bugs are fixed.
• The system works correctly for all functions.
At this point, the testing team confirms that the software is ready for deployment.

Difference Between Entry and Exit Criteria

Aspect Entry Criteria Exit Criteria

Meaning Conditions to start testing Conditions to stop testing

Stage Before testing begins After testing is completed

Purpose Ensure readiness for testing Ensure testing is sufficient

Example Test environment ready All test cases executed

1.4 Methods of Testing: Static and Dynamic Testing
Static Testing
Definition
Static Testing is a software testing method in which the software code, design, or
documentation is examined without executing the program.
Explanation
Static testing is performed in the early stages of software development to detect errors before
the program is executed. In this method, testers and developers analyze documents, program
code, design specifications, and requirement documents to identify mistakes.
The main purpose of static testing is to detect errors early, which helps reduce the cost and
effort required to fix problems later in development.
Static testing focuses on checking:
• Requirement documents
• Design documents
• Source code
• Test plans and test cases
Common techniques used in static testing include:
• Review – Examination of documents or code by team members.
• Walkthrough Author explains the document or code step by step to others.
• Inspection – Formal and detailed review process to detect defects.
Advantages of static testing:
• Errors are detected early in development.
• Reduces development cost.
• Improves software quality.
Real-Time Example
Consider the development of a college admission system.
Before coding begins, the development team reviews the Software Requirement
Specification (SRS) document.
During the review, testers find that the requirement for document upload size limit is not
specified.
This issue is identified without running the software, so it is an example of static testing.
Dynamic Testing
Definition
Dynamic Testing is a software testing method in which the program is executed with test data
to verify its functionality and performance.
Explanation
Dynamic testing involves running the software application and checking whether it behaves as
expected. It helps identify errors that occur during program execution.
This type of testing verifies whether the software performs correctly according to the specified
requirements.
Dynamic testing focuses on checking:
• Program functionality
• System performance
• Input and output behavior
• System response to different conditions
Dynamic testing is usually performed after the software code is developed.
Types of dynamic testing include:
• Unit Testing – Testing individual modules or components.
• Integration Testing – Testing interaction between modules.
• System Testing – Testing the complete system.
• Acceptance Testing – Testing performed by the customer.
Dynamic testing ensures that the software works correctly under real operating conditions.
Real-Time Example
Consider testing a mobile banking application.
A tester performs the following steps:
1. Enter username and password.
2. Click the login button.
3. Check whether the system successfully logs in.
If the system shows an error message even when the correct password is entered, it indicates a
defect in the software.
Since the tester executed the software to observe its behavior, this process is called dynamic
testing.
Difference Between Static Testing and Dynamic Testing

Aspect Static Testing Dynamic Testing

Meaning Testing without executing the program Testing by executing the program

Stage Early stage of development After coding is completed

Focus Code, design, documents Software functionality

Tools/Techniques Review, Walkthrough, Inspection Unit, Integration, System Testing

Purpose Detect errors early Verify software behavior

1.5 White Box Testing
Definition
White Box Testing is a software testing technique in which the internal structure, design, and
code of the software are examined to verify that the program logic works correctly.
Explanation
White Box Testing is also called Structural Testing, Glass Box Testing, or Clear Box
Testing. In this method, testers have knowledge of the internal working of the software such
as program logic, code structure, conditions, and loops.
The main objective of white box testing is to ensure that all internal paths, conditions, and
statements of the program are tested.
It helps in identifying errors related to:
• Logical mistakes in the code
• Incorrect conditions and loops
• Security vulnerabilities
• Data flow errors
White box testing is usually performed by developers or testers with programming
knowledge.
Real-Time Example
Consider a program for calculating student grades.
The program checks:
• If marks ≥ 75 → Grade A
• If marks ≥ 60 → Grade B
• If marks ≥ 50 → Grade C
In white box testing, the tester checks whether each condition in the program code works
correctly for different inputs.

Inspections
Definition
Inspection is a formal review process in which software documents or source code are carefully
examined by experts to identify defects.
Explanation
Inspection is one of the most structured review techniques used in software testing. A team of
reviewers analyzes the code or documentation systematically to detect errors.
Inspection usually follows a defined process that includes preparation, examination, defect
identification, and correction.
The main purpose of inspection is to detect errors early in development before the program
execution stage.
Real-Time Example
During development of a banking software system, a team of experts reviews the program
code for the money transfer module to ensure that the logic for debit and credit operations is
correct.

Walkthroughs
Definition
A walkthrough is an informal review process in which the author of the document or code
explains it step-by-step to other team members to identify possible defects.
Explanation
In a walkthrough, the developer presents the code or design to the team and explains the logic
used in the program.
Other team members ask questions, suggest improvements, and identify possible issues.
Walkthroughs help improve team understanding and early detection of problems.
Real-Time Example
A developer explains the logic of a login authentication module to the testing team. During
discussion, testers notice that the system does not limit the number of incorrect login attempts.
This issue is detected through a walkthrough.

Technical Review
Definition
Technical review is a formal evaluation of software design, code, or documentation by a group
of technically qualified team members.
Explanation
The purpose of a technical review is to ensure that the software meets technical standards and
design requirements.
During the review, experts analyze the software architecture, algorithms, coding standards, and
system design.
Technical reviews help improve software quality and maintainability.
Real-Time Example
Before releasing a mobile banking application, senior software engineers review the system
architecture and security mechanisms to ensure the system follows proper technical standards.

Functional Testing
Definition
Functional testing is a testing technique used to verify whether the software functions according
to the specified requirements.
Explanation
Functional testing focuses on verifying the system’s features and functions based on the
requirements defined in the Software Requirement Specification (SRS).
The internal code structure is not the main concern; instead, the tester checks whether the
software produces correct outputs for given inputs.
Functional testing ensures that all system functions work properly.
Real-Time Example
In an ATM system, functional testing verifies:
• PIN verification
• Balance inquiry
• Cash withdrawal
• Transaction receipt generation

Code Coverage Testing

Definition
Code Coverage Testing is a technique used to measure how much of the program code is
executed during testing.
Explanation
The main purpose of code coverage testing is to ensure that all parts of the software code are
tested.
It identifies areas of the code that have not been tested.
Common types of code coverage include:
• Statement Coverage – Ensures every statement is executed.
• Branch Coverage – Ensures every decision branch is tested.
• Path Coverage – Ensures all possible execution paths are tested.
Higher code coverage usually indicates better testing quality.
Real-Time Example
In a tax calculation software, testers ensure that all conditions for different income ranges are
executed during testing.

Code Complexity Testing

Definition
Code Complexity Testing measures the complexity of a program to determine how difficult
the code is to understand, test, and maintain.
Explanation
Complex software code may contain many conditions, loops, and decision points, making it
difficult to test and maintain.
Code complexity analysis helps identify modules that are too complex and may contain a
higher risk of defects.
One common measure of complexity is Cyclomatic Complexity, which calculates the number
of independent paths in a program.
Reducing code complexity improves:
• Code readability
• Maintainability
• Testability
Real-Time Example
In a bank loan approval system, if the program contains many nested conditions for income
verification, credit score, and employment history, the code may become complex. Testing
helps identify these complex areas so they can be simplified.
1.6 Black Box Testing
Definition
Black Box Testing is a software testing technique in which the functionality of the software is
tested without knowing the internal structure or code of the program.
Explanation
Black Box Testing focuses on checking whether the software system behaves correctly
according to the specified requirements. In this method, the tester does not examine the
internal logic of the program; instead, the tester provides inputs and verifies the outputs.
The software is treated as a “black box”, meaning the internal working of the system is hidden
from the tester.
Black box testing mainly checks:
• Functional correctness
• Input and output behavior
• System interface
• User requirements
This type of testing is usually performed by testers or quality assurance engineers.
Real-Time Example
Consider a login page of a website.
The tester checks:
• Enter valid username and password → Login successful
• Enter incorrect password → Error message displayed
The tester verifies the system output without checking the internal program code. This is an
example of black box testing.

Requirement Based Testing

Definition
Requirement Based Testing is a testing technique in which test cases are designed based on the
requirements specified in the Software Requirement Specification (SRS) document.
Explanation
In requirement based testing, every test case is derived from the functional requirements of
the system. The main objective is to ensure that the developed software satisfies all the
requirements defined by the customer.
Testers carefully study the SRS document and create test cases that verify each requirement.
Benefits of requirement based testing:
• Ensures complete requirement coverage
• Helps detect missing functionality
• Improves software quality
Real-Time Example
Consider an online railway reservation system.
Requirements may include:
• User registration
• Ticket booking
• Ticket cancellation
• Payment processing
Test cases are created to verify whether each of these requirements works correctly.

Boundary Value Analysis

Definition
Boundary Value Analysis (BVA) is a black box testing technique used to test the values at the
boundaries or limits of input ranges.
Explanation
Many software errors occur at the boundary values rather than in the middle of the input range.
Therefore, boundary value analysis focuses on testing the minimum, maximum, and just
above or below the limits.
Typical boundary values include:
• Minimum value
• Maximum value
• Just below minimum
• Just above maximum
Testing these boundary conditions helps identify defects related to incorrect handling of limits.
Real-Time Example
Suppose a system allows student marks between 0 and 100.
Test cases may include:
• -1 (below minimum)
 • 0 (minimum value)
• 1 (just above minimum)
• 99 (just below maximum)
• 100 (maximum value)
• 101 (above maximum)
Testing these values helps verify whether the system handles boundary conditions correctly.

Equivalence Partitioning
Definition
Equivalence Partitioning is a black box testing technique in which input data is divided into
groups or partitions where each group is expected to behave similarly.
Explanation
Instead of testing every possible input value, equivalence partitioning divides input data into
valid and invalid classes. One representative value from each partition is tested.
This technique reduces the number of test cases while still providing effective test coverage.
Types of partitions:
• Valid partition – Inputs that should be accepted by the system.
• Invalid partition – Inputs that should be rejected by the system.
Real-Time Example
Suppose a system accepts age between 18 and 60 years.
Partitions may include:
• Age < 18 → Invalid partition
• Age between 18 and 60 → Valid partition
• Age > 60 → Invalid partition
Instead of testing all ages, testers select representative values such as:
• 15 (invalid)
• 30 (valid)
• 65 (invalid)
This technique helps reduce testing effort while maintaining good test coverage.