UNIT 3:

Integration Testing

Introduction

Software testing for large systems is carried out at different levels of testing such as:

• Unit Testing
• Integration Testing

• System Testing

• Acceptance Testing

Each level has its own objectives. At the integration level, several components or units are
tested together as a group to verify their interactions.

Definition of Integration Testing

Integration Testing is the testing performed after unit testing where individual units or modules
are combined and tested together to verify the interfaces and interactions between them.

The main purpose of integration testing is:

1. To detect defects that occur at the interfaces of units.

2. To assemble individual modules into working subsystems and finally into a complete
system ready for system testing.

Need for Integration Testing

During unit testing, each module is tested independently. However, a module that works
correctly in isolation may fail when combined with other modules.
Therefore integration testing is required to ensure:

• Correct interaction between modules

• Proper data flow between modules

• Correct parameter passing between functions

• Proper execution of calling relationships between modules

Many defects occur at module interfaces, which makes integration testing very important.
Goals of Integration Testing

The major goals of integration testing are:

1. Interface defect detection

To identify errors that occur when modules interact with each other.

2. Subsystem creation
To combine individual units and create working subsystems.

3. System assembly
To gradually assemble subsystems into a complete system.

4. Verification of module interaction

To check whether modules correctly communicate and exchange data.

5. Preparation for system testing

After successful integration testing, the system becomes ready for system testing.

Integration Testing Process

Integration testing generally follows an iterative process.

1. Individual modules first pass unit testing.

2. Modules are integrated one at a time with already tested modules.

3. The interfaces between modules are tested.

4. The integrated modules form a subsystem.

5. Subsystems are combined to form the complete system.

Integrating modules step by step helps testers focus on new interfaces and interactions between
modules.

Advantages of Stepwise Integration

Integrating modules gradually provides several advantages:

• Reduces complexity during testing

• Makes error detection easier

• Avoids massive failures that occur when many modules are integrated at once
 • Helps developers isolate and fix defects quickly

• Allows independent subsystems to be integrated in parallel

Designing Integration Tests

Integration test cases can be designed using:

1. Black Box Testing

Focuses on testing the functional behavior of the combined modules.

Sources for black box tests include:

• Requirements documents

• User manuals

• System specifications

These tests check whether the subsystem performs its expected functionality.

2. White Box Testing

Focuses on internal structure and data flow between modules.

White box testing ensures:

• correct parameter passing

• correct data flow

• correct control flow between modules

Both black box and white box techniques are recommended for integration testing.

Important Aspects Checked During Integration Testing

Testers must verify several interface-related aspects such as:

• Correct number of parameters passed

• Correct parameter order

• Correct parameter type

• Proper use of parameters within modules
 • Correct data flow between modules

For example, when one procedure calls another, the tester must ensure that input parameters are
correctly passed and the output value returned is accurate.

Integration Test Planning

Integration testing should be planned after high-level design is completed.

Important documents used for planning include:

• Requirements specification

• User manual
• Usage scenarios

• Structure charts

• Data flow descriptions

• Module interface descriptions

These documents help testers identify the order of integration and required test cases.

Integration Testing in Object-Oriented Systems

In object-oriented systems, integration testing focuses on interactions among classes.

Two major approaches are used:

1. Thread-based testing
Classes required for responding to one input or event are integrated and tested together.
2. Use-based testing
Independent classes are tested first, followed by dependent classes until the entire system
is integrated.

Another technique called cluster testing tests a group of collaborating classes together.

Conclusion

Integration testing is a critical level of software testing that verifies the interaction between
modules after unit testing. It focuses mainly on detecting interface defects and ensuring
proper communication between components.
By gradually integrating modules and testing their interactions, developers can build reliable
subsystems and finally assemble a complete system that is ready for system testing.

Alpha Testing

Introduction

After a software system has passed unit testing, integration testing, and system testing, it is
necessary to verify whether the software works correctly in an environment that closely
resembles the real user environment.

Before releasing the software to customers, developers perform Alpha Testing to detect defects
that were not identified during earlier testing stages.

Definition of Alpha Testing

Alpha Testing is a type of acceptance testing performed by the developer or testing team
within the organization to identify defects before the product is released to external users.

It is conducted in a controlled environment at the developer’s site.

The main objective of alpha testing is to:

• Evaluate the software from the user’s perspective

• Identify remaining defects

• Ensure that the software works correctly before releasing it to customers.

Purpose of Alpha Testing

The major purposes of alpha testing include:

1. Detecting defects before product release

2. Evaluating system performance in a simulated user environment

3. Improving product quality

4. Ensuring the system meets user requirements

5. Reducing failures after product release

Thus alpha testing acts as a final internal quality check before the product reaches real users.

Characteristics of Alpha Testing

Alpha testing has several important characteristics:

• Conducted at the developer’s location

• Performed by developers or internal testers

• Takes place before beta testing

• Conducted in a controlled testing environment

• Helps detect defects that were not found during system testing

Alpha testing ensures that the software is stable enough for external testing.

Alpha Testing Process

The alpha testing process generally includes the following steps:

1. Preparation of Test Environment

o A testing environment similar to the real user environment is created.

2. Execution of Test Cases

o Testers execute various functional and usability tests.

3. Identification of Defects

o Any errors or unexpected behaviors are recorded.

4. Bug Fixing

o Developers analyze and fix the detected defects.

5. Retesting
o The corrected software is tested again to verify that defects are fixed.

This process continues until the system becomes stable.

Advantages of Alpha Testing

Alpha testing provides several benefits:

• Detects major defects before product release

• Improves software quality

• Reduces maintenance cost after release
 • Ensures better system reliability

• Helps developers understand user expectations

Thus alpha testing helps deliver a more stable and reliable product.

Limitations of Alpha Testing

Despite its advantages, alpha testing has some limitations:

• Testing is done in a controlled environment, not the real environment.

• Internal testers may not fully represent actual users.

• Some real-world problems may still remain undetected.

Therefore beta testing is performed after alpha testing.

Difference Between Alpha Testing and Beta Testing

Feature Alpha Testing Beta Testing

Testing Location Developer’s site User environment

Testers Developers / internal testers Real users

Environment Controlled environment Real-world environment

Purpose Detect defects before release Validate product with users

Conclusion

Alpha testing is an important stage of acceptance testing that helps identify defects before the
software is released to external users. It is performed by developers in a controlled environment
to ensure that the product meets user requirements and functions correctly.

By performing alpha testing, organizations can improve software quality, reduce post-release
failures, and increase user satisfaction.
Beta Testing

Introduction

Sometimes software products fail after delivery because they do not meet customer
requirements. This may occur due to incorrect implementation, changing business requirements,
usability problems, or incomplete understanding of requirements.

To avoid such problems, software is released to a group of external users for testing before the
final release. This stage of testing is called Beta Testing.

Definition of Beta Testing

Beta Testing is the mechanism of sending the software product under test to the customers and
receiving feedback from them.

It is defined as:

Testing done by potential or existing users, customers, and end users at their own site
without the involvement of developers.

Beta testing is also called field testing because it is performed in a real user environment.

Beta Version and Beta Software

Before final release, companies provide a beta version of the software.

• Beta Software – Preview version released to the public before the final product release.

• Beta Version – Software that contains almost all features but may still contain some
errors.

• Beta Testers – Users who test the beta version of the software.

Purpose of Beta Testing

The main objectives of beta testing are:

1. To check whether the software satisfies business and operational needs of customers.

2. To identify defects in the real user environment.

3. To collect feedback from customers and end users.
 4. To ensure the product meets customer expectations before final release.

Thus beta testing ensures that the software performs correctly in real-world conditions.

Activities in Beta Testing Program

The following activities are normally performed in a beta testing program:

1. Collect list of customers who will participate in beta testing.

2. Prepare beta testing schedule and inform the customers.

3. Provide documents and train customers on product usage.

4. Ensure the software satisfies beta testing entry criteria.

5. Send the beta product to customers for testing.

6. Customers perform testing in their own environment.

7. Collect feedback and defect reports from customers.

8. Prioritize defects and fix them.

9. Release updated versions to the same users for verification.

10. When testing is completed, close the beta program and release the final version.

Main Features of Beta Testing

The important features of beta testing are:

• It involves external users or customers.

• Testing is done outside the organization.

• Testing occurs in a real-time environment.

• Black-box testing techniques are usually used.

Advantages of Beta Testing

Beta testing provides several benefits:

• Helps identify defects in real user conditions.

• Provides direct feedback from customers.
 • Improves product quality before final release.

• Ensures the product satisfies user requirements and expectations.

It also reduces the risk of product rejection after release.

Difference Between Alpha Testing and Beta Testing

Alpha Testing Beta Testing

Performed by developers or internal testers Performed by customers or end users

Conducted at developer’s site Conducted at user’s site

Performed in controlled environment Performed in real-time environment

External users are not involved External users are involved

This shows that beta testing is the final stage before product release.

Conclusion

Beta testing is an important phase of acceptance testing where the software is tested by real
users in their own environment. It helps collect customer feedback, detect remaining defects, and
verify whether the product satisfies real-world requirements.

Therefore, beta testing ensures that the software product is ready for final release and meets
user expectations effectively.

Importance of Defect Classification

Introduction

A defect is a flaw, mistake, or error in software that causes the program to produce incorrect or
unexpected results.

Defect classification is the process of categorizing defects into different types based on their
nature, severity, or source.

It helps testers and developers understand the defects better and improve the overall quality of
the software.
Importance of Defect Classification

1. Helps in Understanding the Nature of Defects

Defect classification helps the testing team understand what type of problem occurred in the
software.

Example:

• A calculation error in a banking system is a functional defect.

• A slow response time in a website is a performance defect.

By classifying defects, developers can quickly identify the type of issue.

2. Improves Defect Analysis

Classification helps teams analyze which types of defects occur frequently.

Example:
If many defects belong to the interface category, it means the design or integration of modules
needs improvement.

This analysis helps the team identify weak areas in the software development process.

3. Helps in Prioritizing Defects

Not all defects are equally important. Some defects must be fixed immediately, while others can
be fixed later.

Example:

• Critical defect – System crash during online payment.

• Minor defect – Typographical error in a webpage.

Through classification, defects can be categorized as:

• Critical

• Major

• Minor

• Cosmetic
This helps the development team prioritize bug fixing effectively.
4. Improves Software Quality

When defects are properly classified, teams can identify root causes of problems and take
corrective actions.

Example:
If many defects occur due to requirement misunderstandings, the organization may improve
the requirement analysis process.

Thus defect classification contributes to better software quality and fewer errors in future
projects.

5. Helps in Process Improvement

Defect classification allows organizations to evaluate the effectiveness of their development

an0d testing processes.

Example:
If most defects occur during the coding phase, the team may need better code reviews or coding
standards.

This helps organizations improve development practices.

6. Supports Better Communication

When defects are classified clearly, it becomes easier for:

• testers
• developers

• project managers

to communicate about issues.

Example:
Instead of saying “the system has a problem,” a tester can report:

“This is a performance defect causing slow page loading.”

This improves clarity and collaboration in the team.

Examples of Defect Classification

Defect Type Example

Functional defect Incorrect calculation in banking interest

Interface defect Login button not responding

Performance defect Website takes too long to load

Security defect Unauthorized access to user data

Cosmetic defect Misaligned text on webpage

Conclusion
Defect classification plays a crucial role in software testing. It helps identify, analyze, prioritize,
and manage defects effectively. By classifying defects properly, organizations can improve
software quality, enhance development processes, and deliver reliable software products.

Role of Testers and Developers in Maintaining an Effective Defect Repository

Introduction

A defect repository is a centralized database used to store, track, and manage all defects
identified during software testing. It contains information such as defect description, severity,
status, priority, steps to reproduce the defect, and resolution details.

Maintaining an effective defect repository is important because it helps the team analyze
defects, improve product quality, and prevent similar defects in the future.

Both testers and developers play important roles in maintaining and improving the defect
repository.

Role of Testers in Maintaining an Effective Defect Repository

Testers are mainly responsible for identifying, recording, and managing defects in the
repository.
1. Identifying Defects

The primary role of testers is to detect defects during testing activities.

Example:
If a login page crashes when incorrect credentials are entered, the tester identifies it as a defect.
2. Reporting Defects Clearly

Testers must record defects in the repository with clear and complete information, including:

• Defect title
• Description of the defect

• Steps to reproduce the defect

• Expected result

• Actual result

• Screenshots or logs

Clear reporting helps developers understand the problem quickly.

3. Assigning Severity and Priority

Testers classify defects based on their severity and priority.

Example:

• Critical defect – System crash during payment processing.

• Minor defect – Alignment issue in webpage text.

Proper classification helps developers prioritize bug fixes.

4. Updating Defect Status

Testers monitor the defect status throughout the testing process.

Common statuses include:

• New

• Open

• Assigned

• Fixed

• Retested
• Closed
Testers update the repository after retesting the fixed defects.

5. Verifying Bug Fixes

After developers fix defects, testers retest the software to verify the fixes.
If the problem is resolved:

• the defect is marked closed.

If not:

• the defect is reopened.

6. Maintaining Accurate Defect Records

Testers ensure that the defect repository remains accurate, organized, and up-to-date. This
helps the team perform defect analysis and quality improvement.

Role of Developers in Supporting and Improving the Defect Repository

Developers also play an important role in ensuring the effectiveness of the defect repository.

1. Analyzing Reported Defects

Developers review the defects reported by testers and analyze the root cause of the problem.

Example:
A defect in calculation may occur due to incorrect logic in the program code.

2. Fixing Defects

The main responsibility of developers is to correct the defects identified in the repository.

They modify the source code to remove the error and improve the functionality of the software.

3. Updating Defect Status

After fixing a defect, developers update the defect repository with information such as:

• status changed to fixed

• comments about the solution
 • code changes made

This helps testers know that the defect is ready for verification.

4. Providing Technical Details

Developers provide technical explanations and root cause analysis for defects.

Example:
A developer may explain that a defect occurred due to memory allocation errors or incorrect
database queries.

This information helps improve future development practices.

5. Preventing Recurring Defects

Developers use the defect repository to study frequently occurring defects and take preventive
measures.

Example:

• improving coding standards

• performing better code reviews

• improving design practices

This reduces the number of defects in future releases.

Conclusion

An effective defect repository helps teams track and manage defects efficiently. Testers are
responsible for identifying, reporting, and verifying defects, while developers analyze and fix
the defects and provide technical insights.

Through collaboration between testers and developers, the defect repository becomes a valuable
tool for improving software quality and development processes.
Five Level Structure of Testing Maturity Model (TMM)

Introduction

The Testing Maturity Model (TMM) is a framework used to evaluate and improve the
software testing process in an organization.

It defines five maturity levels that represent the stage of development of the testing process. As
the maturity level increases, the testing process becomes more structured, organized, and
effective.

The five levels of TMM are:

1. Initial Level

2. Definition Level

3. Integration Level
4. Management and Measurement Level

5. Optimization / Defect Prevention Level

Five Levels of Testing Maturity Model

1. Initial Level (Level 1)

At this level, testing is informal and unstructured.

Characteristics:
• No formal testing process

• Testing is performed only after coding

• Testing is mainly debugging activities

• No proper test planning or documentation

Example:
Developers run the program and check if it works, but no systematic testing strategy is
followed.

2. Definition Level (Level 2)

At this level, the organization begins to define basic testing processes.
Characteristics:

• Testing process is documented

• Test plans and test cases are created

• Basic testing standards are followed

• Test activities are separated from development

Example:
A project team prepares a test plan and test cases before executing tests.

3. Integration Level (Level 3)

At this level, testing is integrated into the software development life cycle (SDLC).

Characteristics:

• Testing activities start early in development

• Testing is integrated with requirements and design phases

• Test strategies and methodologies are clearly defined

• Testing teams collaborate closely with developers

Example:
Testers review requirements and design documents to identify defects early.

4. Management and Measurement Level (Level 4)

At this stage, the testing process becomes well-managed and measurable.

Characteristics:

• Testing activities are monitored and controlled

• Metrics are used to measure testing effectiveness

• Defect data is collected and analyzed

• Test progress and quality are evaluated using measurements

Example:

• Tracking defect density

• Measuring test coverage
This helps organizations evaluate the quality of the software product.

5. Optimization Level / Defect Prevention Level (Level 5)

This is the highest level of testing maturity.

Characteristics:

• Focus on continuous improvement of testing processes

• Defect prevention techniques are applied

• Advanced testing tools and automation are used

• Root cause analysis is performed to prevent future defects

Example:
Organizations analyze defect patterns and improve development and testing practices to avoid
similar defects in future projects.

Summary of Five Levels of TMM

Level Name Key Feature

Level 1 Initial Unstructured testing

Level 2 Definition Basic testing processes defined

Level 3 Integration Testing integrated with SDLC

Level 4 Management & Measurement Testing measured and controlled

Level 5 Optimization / Defect Prevention Continuous improvement

Conclusion

The Testing Maturity Model helps organizations evaluate and improve their testing processes.
By progressing through the five levels, organizations can develop structured testing practices,
improve defect detection, and enhance software quality.

If you want, I can also give the simple diagram professors expect for TMM (5-level pyramid
diagram) which can add extra marks in exams.
11 Principles of Software Testing

Software testing principles are fundamental guidelines that help testers design effective tests and
detect defects efficiently.

1. Testing Shows Presence of Defects

Testing can show that defects exist in software, but it cannot prove that the software is
completely error-free.

Even if no bugs are found, it only means that defects were not discovered during testing.

2. Exhaustive Testing is Impossible

Testing all possible inputs, outputs, and execution paths is impossible because software systems
are very complex.

Therefore testers select representative test cases instead of testing every possibility.

3. Early Testing Saves Time and Cost

Testing should begin as early as possible in the software development life cycle (SDLC).

Early defect detection:

• reduces cost

• reduces development effort

• improves software quality

4. Defect Clustering

A small number of modules usually contain most of the defects.

This means:

• 80% of defects are often found in 20% of modules.

Testers should focus more testing effort on critical modules.

5. Pesticide Paradox
If the same test cases are repeated again and again, they will eventually stop detecting new
defects.

Therefore:

• Test cases must be reviewed and updated regularly

• New test cases should be added.

6. Testing Depends on Context

Different applications require different testing strategies.

Examples:
• Banking software → needs security and reliability testing

• Gaming software → needs performance and usability testing

Thus testing methods vary based on the type of software.

7. Absence of Errors Fallacy

Finding and fixing defects does not guarantee that the software is useful.

If the software does not meet user requirements, it will still fail even if no defects exist.

8. Testing is Risk Based

Testing should focus on high-risk areas of the software.

Critical components should be tested more thoroughly because failures in these areas can cause
serious problems.

9. Testing Requires Independence

Testing should be performed by independent testers rather than the developers who wrote the
code.

Independent testers can identify defects more objectively.

10. Complete Testing Requires Planning

Testing should be systematically planned and controlled.

A proper testing process includes:

• test planning

• test design
• test execution

• defect reporting

11. Testing is a Continuous Process

Testing is not a one-time activity. It continues throughout the software development life cycle.

Testing occurs during:

• requirements stage

• design stage
• coding stage

• maintenance stage

Conclusion

The 11 principles of software testing guide testers in designing effective tests and detecting
defects efficiently. By following these principles, organizations can improve software quality,
reduce development costs, and ensure that the final product meets user expectations.

Equivalence Class Partitioning and Boundary Value Analysis

Introduction

In software testing, it is impossible to test every possible input value. Therefore, testers use test
case design techniques to reduce the number of test cases while still ensuring good coverage.

Two commonly used techniques are:

• Equivalence Class Partitioning (ECP)

• Boundary Value Analysis (BVA)
These techniques help testers design effective test cases with minimum effort.
1. Equivalence Class Partitioning (ECP)

Definition

Equivalence Class Partitioning is a black-box testing technique in which the input data is
divided into groups called equivalence classes.

Each class represents a set of inputs that are expected to produce similar behavior in the
software.
Instead of testing every input, one value from each class is selected for testing.

Types of Equivalence Classes

1. Valid Equivalence Class – Inputs that should be accepted by the system.

2. Invalid Equivalence Class – Inputs that should be rejected by the system.

Example for ECP

Suppose a program accepts marks between 0 and 100.

Equivalence Classes

Class Type Input Range Example Test Value

Invalid Class Marks < 0 -5

Valid Class 0 to 100 50

Invalid Class Marks > 100 120

Instead of testing every value from 0–100, we select one value from each class.

Thus only three test cases are sufficient.

2. Boundary Value Analysis (BVA)

Definition

Boundary Value Analysis is another black-box testing technique that focuses on testing values
at the boundaries (limits) of input ranges.
Most software defects occur at the edges of input ranges, so testing boundary values increases
the chances of detecting errors.

Boundary Values

For a range 0 to 100, the important boundary values are:

• Minimum value

• Just above minimum

• Just below maximum

• Maximum value
• Values outside the range

Example for BVA

For the same condition marks between 0 and 100:

Boundary Test Case Value

Just below minimum -1

Minimum value 0

Just above minimum 1

Just below maximum 99

Maximum value 100

Just above maximum 101

These values help detect errors that occur near the boundary limits.

Comparison of ECP and BVA

Feature Equivalence Class Partitioning Boundary Value Analysis

Technique type Black-box testing Black-box testing

Main concept Divide inputs into groups Test boundary limits

Feature Equivalence Class Partitioning Boundary Value Analysis

Test case selection One value per class Values at edges of range

Purpose Reduce number of test cases Detect boundary errors

Conclusion

Equivalence Class Partitioning and Boundary Value Analysis are important test case design
techniques used in software testing. ECP reduces the number of test cases by grouping inputs,
while BVA focuses on testing boundary values where errors are most likely to occur. Together,
these techniques improve test coverage and defect detection efficiency.

Control Flow Graph and Cyclomatic Complexity in White Box Testing

Introduction

White box testing is a testing technique in which the internal structure, logic, and flow of the
program are examined.

Two important concepts used in white box testing are:

• Control Flow Graph (CFG)

• Cyclomatic Complexity

These concepts help testers understand the program structure and determine the number of
independent test paths required for testing.

1. Control Flow Graph (CFG)

Definition

A Control Flow Graph (CFG) is a graphical representation of the flow of control in a

program.

It shows:
• the sequence of program statements

• decision points
 • possible execution paths

In CFG:

• Nodes represent statements or blocks of statements

• Edges represent the flow of control between nodes

Significance of Control Flow Graph

1. Represents Program Structure Clearly

It shows how control moves from one statement to another.

2. Helps Identify Execution Paths

Testers can analyze different paths through the program.

3. Helps in Designing Test Cases

CFG helps testers determine the paths that must be tested.
4. Used to Calculate Cyclomatic Complexity
The graph is used to determine the number of independent paths.

2. Cyclomatic Complexity

Definition

Cyclomatic Complexity is a software metric that measures the complexity of a program.

It indicates the number of independent paths in a program that must be tested to achieve
complete path coverage.

Cyclomatic complexity helps testers determine the minimum number of test cases required for
thorough testing.

Formula for Cyclomatic Complexity

Cyclomatic complexity can be calculated using:

V(G) = E − N + 2
Where

• E = Number of edges in the control flow graph

• N = Number of nodes in the control flow graph
Another simple formula:

V(G) = Number of decision nodes + 1

Example: Sum of N Numbers

Pseudo Code

Start

Read n

sum = 0

i=1

while (i <= n)

sum = sum + i
i=i+1

print sum

Stop

This program calculates the sum of the first n numbers.

Control Flow Graph for the Program

Nodes represent program statements:

1. Start

2. Read n

3. Initialize sum and i

4. Check condition (i ≤ n)

5. Add i to sum

6. Increment i
7. Print sum
 8. Stop

Flow:

Start → Read n → Initialize → Condition check

If condition true → Add → Increment → back to condition
If condition false → Print sum → Stop

Cyclomatic Complexity Calculation

Decision node:

• while (i ≤ n)
Number of decision nodes = 1

Using formula:

Cyclomatic Complexity = Decision nodes + 1

V(G) = 1 + 1
V(G) = 2

Meaning of Result

Cyclomatic complexity 2 means:

• There are two independent execution paths.

• Minimum two test cases are required.

Possible Test Paths

Path 1:
n = 0 → loop not executed

Path 2:
n > 0 → loop executed
Testing these paths ensures complete path coverage.

Importance in White Box Testing

Control Flow Graph and Cyclomatic Complexity help testers:

• understand program logic
 • identify independent paths

• design effective test cases

• measure program complexity

• improve test coverage

These techniques ensure systematic and efficient white box testing.

Conclusion

Control Flow Graph provides a visual representation of program execution, while Cyclomatic
Complexity measures the program's logical complexity. Together they help testers identify
independent paths and determine the minimum number of test cases required for effective white
box testing.

Black Box Testing (13 Marks)

Introduction

Black box testing is a software testing technique in which the tester evaluates the functionality
of the software without examining the internal code or program structure.

The tester focuses only on:

• input values

• output results

• system behavior

Since the internal structure of the program is hidden, it is called black box testing.

Definition

Black box testing is a method of testing where the tester checks the software system based on
requirements and specifications without knowledge of the internal implementation.

Features of Black Box Testing

• No knowledge of program code is required

• Based on software requirements and specifications

• Focuses on input-output behavior
 • Performed from the user’s perspective

Techniques Used in Black Box Testing

1. Equivalence Class Partitioning

Input data is divided into equivalence classes where each class represents similar behavior.

Example:
If a program accepts numbers 1–100, test cases may be:
• 50 (valid class)

• -5 (invalid class)
• 120 (invalid class)

2. Boundary Value Analysis

Testing focuses on boundary values where errors commonly occur.

Example:
For range 1–100, test values:

• 0
• 1

• 2

• 99

• 100
• 101

3. Decision Table Testing

Used when system behavior depends on multiple conditions.

Example:
Bank loan approval based on income and credit score.

4. State Transition Testing

Used when the system behavior depends on state changes.

Example:
ATM machine states: idle → card inserted → PIN entered.

Advantages of Black Box Testing

• No programming knowledge required

• Tests software from user perspective

• Effective in identifying missing functions

• Suitable for large systems

Limitations of Black Box Testing

• Cannot test internal program logic

• Some paths in the program may remain untested

• Difficult to identify hidden errors

Example

Consider a login system.

Input:

• Username

• Password

Test cases:
• Correct username and password

• Incorrect password

• Empty fields

The tester checks whether the system behaves correctly without seeing the program code.

Conclusion
Black box testing is an important testing technique that verifies the functional requirements of
software. It focuses on inputs and outputs and ensures that the system behaves according to user
expectations.

White Box Testing (13 Marks)

Introduction

White box testing is a testing technique where the internal structure, logic, and code of the
software are examined.

The tester must have knowledge of the programming logic and internal implementation.

It is also known as:

• Glass box testing

• Structural testing
• Clear box testing

Definition

White box testing is a testing technique that verifies the internal working, control flow, and
data flow of a program.

Features of White Box Testing

• Requires knowledge of program code

• Tests internal logic and program structure

• Ensures all paths and statements are tested

• Usually performed by developers or skilled testers

Techniques Used in White Box Testing

1. Statement Coverage

Ensures that every statement in the program is executed at least once.

Example:
if (a > b)

max = a

else

max = b
Both branches should be executed.

2. Branch Coverage

Ensures that each decision branch (true and false) is tested.

Example:
Testing both conditions of an if statement.

3. Path Coverage

Ensures that all independent paths in the program are executed.

Used to detect logical errors in complex programs.

4. Control Flow Testing

Uses Control Flow Graph (CFG) to represent program execution paths.

5. Cyclomatic Complexity

Measures the number of independent paths in a program.

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

Where:

• E = edges

• N = nodes

Advantages of White Box Testing

 • Tests internal logic thoroughly

• Helps identify hidden errors in code

• Improves code quality

• Ensures complete path coverage

Limitations of White Box Testing

• Requires programming knowledge

• Time consuming for large systems

• Cannot detect missing functionality

Example

Program to check whether a number is positive or negative.

if (num >= 0)

print "Positive"

else

print "Negative"

White box testing ensures both branches are tested.

Conclusion
White box testing focuses on internal program logic and structure. It helps testers verify code
correctness, improve program quality, and ensure all execution paths are properly tested.
ASSIGNMENT

1. Scenario – Identify Testing Axioms

a) Testing Axioms Identified

1. Testing should start early

2. Exhaustive testing is impossible
 3. Defect clustering

4. Pesticide paradox

5. Absence of errors fallacy

b) Explanation with Scenario

1. Testing should start early
Testing started only after coding → defects could have been found earlier in
requirements/design.

2. Exhaustive testing is impossible

Team tried testing all input combinations but failed due to time constraints.

3. Defect clustering
Most defects occurred in a few critical modules.

4. Pesticide paradox
Same test cases executed every release → no new defects found.

5. Absence of errors fallacy

Software passed all test cases but users were still dissatisfied.

2. Scenario – Testing Axioms

a) Testing Axioms Identified

1. Testing shows presence of defects, not absence

2. Testing alone cannot guarantee quality

3. Testing depends on context

b) Explanation

1. Presence of defects, not absence

No defects found during testing does not mean the software is error-free.

2. Testing alone cannot guarantee quality

Quality must be ensured through proper design, development, and testing.

3. Testing depends on context

Different strategies used for banking system and gaming application.

3. Online Shopping Application

a) Defect Classification

Problem Defect Type

System crashes for invalid payment Functional defect

Checkout page slow Performance defect

Apply coupon button misaligned UI/Cosmetic defect

Email sent to wrong address Functional/Logic defect

b) Importance of Defect Classification

1. Helps identify type of defects.

2. Helps prioritize bug fixing.

3. Improves defect analysis.

4. Helps improve development process.

5. Prevents similar defects in future.

Example: If many performance defects occur → optimize system performance.

4. Defect Repository
a) Definition

A defect repository is a centralized database used to store, track, and manage defects found
during testing.

b) How it Supports Test Design

1. Helps testers study past defects.

2. Helps design better test cases.

3. Prevents repetition of past errors.

4. Helps identify high-risk modules.

c) Key Information Stored

• Defect ID
 • Defect description

• Severity

• Priority

• Defect type
• Root cause

• Status

• Environment details

• Resolution information

5. Defect Repository Maintenance

a) Role of Testers

1. Identify and report defects.

2. Provide clear reproduction steps.

3. Assign severity and priority.

4. Verify bug fixes.

5. Update defect status.

b) Role of Developers

1. Analyze reported defects.

2. Fix the defects in code.

3. Update defect status in repository.

4. Provide root cause analysis.

5. Improve coding practices.

c) How Collaboration Reduces Recurring Defects

1. Clear communication between testers and developers.

2. Proper documentation of defects.
 3. Root cause analysis.

4. Better test case design.

5. Prevents similar defects in future releases.

Question 1 – Black Box Testing (BVA & ECP)

a) Test Cases using BVA and ECP for Age (18–60)

Equivalence Class Partitioning (ECP)

Class Type Range Example Test Case

Invalid Age < 18 15

Valid 18–60 30

Invalid Age > 60 65

Boundary Value Analysis (BVA)

Boundary Case Test Value

Just below minimum 17

Minimum value 18

Just above minimum 19

Just below maximum 59

Maximum value 60

Just above maximum 61

b) Domain Testing Improvement

• Tests entire input domain of the form.

• Ensures system handles valid and invalid inputs correctly.

• Helps detect boundary and input validation errors.
 • Improves overall test coverage.

c) When Random Testing is Useful

• When input combinations are large or unpredictable.

• To detect unexpected errors.

• Useful for testing email, password, and form fields with random values.

Question 2 – State-Based & Cause–Effect Testing

a) State-Based Test Cases

Current State Input/Event Next State

Search Select ticket Seat Selection

Seat Selection Confirm seats Payment

Payment Successful payment Confirmation

Payment Payment failure Payment retry

Any state Session timeout Cancellation

b) Cause–Effect Graph (Booking Confirmation)

Causes

• C1: Seat selected

• C2: Payment successful

• C3: Session active

Effects

• E1: Booking confirmed

• E2: Booking cancelled

Logic
If C1 AND C2 AND C3 → E1 (Confirmation)
If Payment fails OR Session timeout → E2 (Cancellation)

c) Benefits of Cause–Effect Graphing

• Identifies logical relationships between inputs and outputs.

• Reduces number of test cases.

• Helps design systematic test cases.

Question 3 – Requirements-Based & Compatibility Testing

a) Requirements-Based Testing

• Tests are derived from system requirements and specifications.

• Ensures each requirement has corresponding test cases.

• Confirms application behaves according to functional requirements.

Example:
Login, balance check, fund transfer features tested as per requirements.

b) Compatibility Testing Strategy

Test application on:

• Different devices (mobile, tablet)

• Different OS versions (Android, iOS)

• Different screen sizes

• Different browsers

Goal: Ensure app works consistently across environments.

c) Importance of User Documentation Testing

• Ensures user manuals and help guides are accurate.

• Helps users understand features and operations.

• Improves user experience.
Example: Instructions for fund transfer or password reset.

Question 4 – White Box Testing (Coverage & CFG)

a) White Box Test Cases

Test cases should cover:

• Different customer types

• Different purchase amounts

• All decision conditions

Example:

Customer Type Purchase Amount Expected Discount

Regular 500 Small discount

Premium 2000 Higher discount

VIP 5000 Maximum discount

b) Control Flow Graph (CFG)

Nodes represent program statements.

Example Flow:

Start → Input details →

Decision: customer type →
Decision: purchase amount →
Apply discount → Output → End

Possible paths:

1. Regular customer path

2. Premium customer path

3. VIP customer path

c) Test Adequacy Criteria

Statement Coverage

• Every statement executed at least once.

Branch Coverage

• Every decision branch (true/false) executed.

Path Coverage

• All possible execution paths tested.

Question 5 – Code Logic & Test Adequacy

a) Code Complexity Testing

• Measures complexity using Cyclomatic Complexity.

• Identifies modules with many conditions and loops.

• Helps find error-prone code sections.

b) Static Testing vs Structural Testing

Static Testing Structural Testing

Done without executing code Code execution required

Reviews, inspections White box testing

Finds design and documentation errors Tests internal code logic

Example:

• Static: Code review

• Structural: Path testing

c) Test Adequacy Criteria

Test adequacy criteria ensure sufficient testing coverage.

Common criteria:
• Statement coverage
 • Branch coverage

• Path coverage

These help verify that all important code logic and paths are tested.