BCA-404: Software Engineering | Unit 5: Software Testing Dept. of C.S.

, DDUGU GKP

BCA-404: SOFTWARE ENGINEERING

UNIT 5: SOFTWARE TESTING

Comprehensive Study Notes | Bachelor of Computer Application

Syllabus Coverage (Unit 5)

Objectives, Principles, Testability. Test Cases: White Box & Black Box Testing, Unit Testing,
Integration Testing. Testing Strategies: Verification & Validation, Unit Test, Integration
Testing, Validation Testing, System Testing.

1. Introduction to Software Testing

Software testing is a critical phase of the Software Development Life Cycle (SDLC) that involves
evaluating a software application to identify any gaps, errors, or missing requirements in contrast
to the actual requirements. It is the process of executing a program or system with the intent of
finding bugs or defects.

1.1 Objectives of Software Testing

• To detect faults/errors/bugs in the software before delivery to the client.
• To verify that the software meets the specified requirements.
• To validate that the software is fit for its intended purpose.
• To build confidence in the quality of the software product.
• To ensure the software is reliable, secure, and performs correctly under expected
conditions.
• To minimize the risk of software failure after deployment.

📌 KEY POINT: Testing can only show the presence of bugs, NOT their absence. The goal
is to find as many defects as possible before release.

2. Principles of Software Testing

Seven universal principles guide effective software testing:

Page 1 | Prepared for BCA Students

BCA-404: Software Engineering | Unit 5: Software Testing Dept. of C.S., DDUGU GKP

1. Testing shows presence of defects: Testing can prove that bugs exist, but cannot prove
there are zero bugs. Even exhaustively tested software may still have undiscovered defects.
2. Exhaustive testing is impossible: It is impossible to test every possible input, path, or
combination. Instead, testers use risk analysis and priorities to focus testing efforts.
3. Early testing: Testing activities should begin as early as possible in the SDLC. Defects found
early are much cheaper and easier to fix.
4. Defect clustering: A small number of modules tend to contain the majority of bugs. Testers
should focus efforts on these high-risk areas (Pareto Principle: 80% of bugs are in 20% of
code).
5. Pesticide paradox: Repeating the same tests over time will eventually stop finding new
bugs. Tests must be regularly reviewed and revised to discover new defects.
6. Testing is context-dependent: Different systems require different testing approaches.
Safety-critical software (e.g., medical, aerospace) needs far more rigorous testing than a simple
website.
7. Absence-of-errors fallacy: Finding and fixing 99% of bugs is useless if the software doesn't
meet the user's needs. Verification alone is not enough — validation is equally important.

3. Software Testability
Testability refers to the degree to which a software artifact (module, system, or component)
supports testing in a given test context. A highly testable program makes it easy to design,
execute, and evaluate tests.

3.1 Characteristics of Testable Software

Characteristic Description
Operability The better the software works, the more
efficiently it can be tested.
Observability Test results (outputs, state changes) are
easy to observe and measure.
Controllability The degree to which testers can control the
software inputs and state.
Decomposability Software can be broken into independent
modules for isolated testing.
Simplicity The less complex the software, the easier it
is to test thoroughly.
Stability Fewer changes means fewer disruptions to
test planning and execution.
Understandability Well-documented, clear code is easier to
design tests for.

Page 2 | Prepared for BCA Students

BCA-404: Software Engineering | Unit 5: Software Testing Dept. of C.S., DDUGU GKP

4. Test Cases
A test case is a set of conditions or variables used to determine if a system under test satisfies
requirements or works correctly. A good test case is one that has a high probability of finding an
undiscovered defect.

4.1 Components of a Test Case

• Test Case ID: Unique identifier for reference.
• Test Description: What is being tested.
• Preconditions: State of the system before test execution.
• Test Steps: Step-by-step procedure to execute the test.
• Test Input: Data provided to the system.
• Expected Output: The anticipated correct result.
• Actual Output: What the system actually produced.
• Pass/Fail Status: Whether the actual matches the expected output.

5. White Box Testing

White Box Testing (also called Glass Box Testing, Structural Testing, or Clear Box Testing) is a
testing technique where the tester has full knowledge of the internal structure, logic, and
implementation of the software. Tests are designed based on the code itself.

📌 KEY POINT: White Box Testing = Testing with knowledge of internal code. The tester can
see INSIDE the box (the application).

5.1 Objectives of White Box Testing

• Ensure that all independent paths within a module have been exercised at least once.
• Verify all logical decisions on their true and false sides.
• Execute all loops at their boundaries and within their operational bounds.
• Validate internal data structures to ensure their validity.

5.2 White Box Testing Techniques

A. Statement Coverage
Every statement in the code is executed at least once. It is the most basic form of white box
testing.

Page 3 | Prepared for BCA Students

BCA-404: Software Engineering | Unit 5: Software Testing Dept. of C.S., DDUGU GKP

• Formula: Statement Coverage = (Statements Executed / Total Statements) × 100%

• Limitation: Does not guarantee all branches are tested.

B. Branch / Decision Coverage

Every branch (true/false outcome) of each decision point is executed at least once. This is
stronger than statement coverage.
• Example: An IF statement has both a TRUE path and a FALSE path — both must be
tested.
• Formula: Branch Coverage = (Branches Executed / Total Branches) × 100%

C. Path Coverage
Every possible execution path through the code is tested. This is the most comprehensive (and
most expensive) form of white box testing.
• Even small programs can have thousands of paths, making 100% path coverage
impractical.

D. Condition Coverage
Each condition in a decision statement is evaluated to both true and false at least once.

E. Loop Testing
Focuses specifically on the validity of loop constructs. Tests are designed for:
• Simple Loops: Test with 0, 1, 2, typical, and maximum iterations.
• Nested Loops: Work from the innermost loop outward.
• Concatenated Loops: Test each loop independently if they are independent.

5.3 Basis Path Testing

Proposed by Tom McCabe, this technique establishes a logical complexity measure (cyclomatic
complexity) of a procedural design and uses it as a guide for defining a basis set of execution
paths.

• Cyclomatic Complexity (V(G)) = E - N + 2P

• Where: E = Edges, N = Nodes, P = Connected components (usually 1)
• Alternatively: V(G) = Number of binary decisions + 1
• The cyclomatic complexity gives the MINIMUM number of test cases needed.

Example
If a program has 3 IF statements, V(G) = 3 + 1 = 4. This means a minimum of 4 test cases
are needed to achieve full branch coverage.

Page 4 | Prepared for BCA Students

BCA-404: Software Engineering | Unit 5: Software Testing Dept. of C.S., DDUGU GKP

5.4 Advantages and Disadvantages of White Box Testing

Advantages Disadvantages
Thorough testing of internal logic. Requires detailed knowledge of the code.
Helps optimize code and remove dead code. Cannot detect missing functionality (functions
not yet written).
Enables coverage measurement. Very time-consuming and expensive for large
systems.
Detects hidden errors in code paths. Tests may become outdated when code
changes.

6. Black Box Testing

Black Box Testing (also called Functional Testing, Behavioral Testing, or Specification-Based
Testing) is a software testing method where the tester evaluates the functionality of the software
without any knowledge of its internal design, code structure, or implementation.

📌 KEY POINT: Black Box Testing = Testing WITHOUT knowledge of internal code. The
tester treats the system as a 'black box' — only inputs and outputs matter.

6.1 Objectives of Black Box Testing

• To verify that the software functions as per the specified requirements.
• To identify incorrect or missing functions.
• To find errors in interface, data structures, and performance.
• To detect initialization and termination errors.

6.2 Black Box Testing Techniques

A. Equivalence Partitioning
The input domain is divided into classes of data from which test cases are derived. The
assumption is that all values in the same class produce the same behavior, so only one value
needs to be tested from each class.
• Valid Equivalence Classes: Inputs that the system should accept.
• Invalid Equivalence Classes: Inputs that the system should reject.
• Example: For age input (1-100), classes are: below 1 (invalid), 1-100 (valid), above 100
(invalid).

Page 5 | Prepared for BCA Students

BCA-404: Software Engineering | Unit 5: Software Testing Dept. of C.S., DDUGU GKP

B. Boundary Value Analysis (BVA)

Errors tend to cluster near the boundary of input domain. BVA selects test cases from the edges
(boundaries) of equivalence classes rather than the center.
• For a range [min, max], test at: min-1, min, min+1, max-1, max, max+1.
• Example: If valid input is 1-100, test with: 0, 1, 2, 99, 100, 101.

Why BVA?
Programmers often make 'off-by-one' errors (e.g., using < instead of <=). BVA is specifically
designed to catch these common boundary mistakes.

C. Decision Table Testing

Used when the system behavior depends on combinations of conditions. A decision table lists all
conditions and their corresponding actions.
• Rows = Conditions and Actions.
• Columns = Rules (specific combinations of condition values).
• Effective for testing complex business logic.

D. State Transition Testing

Used for systems that can be in different states and transition between states based on events.
The system is represented as a state diagram, and test cases are designed to cover transitions.

E. Use Case Testing

Test cases are derived from use cases that describe user interactions with the system. Effective
for testing end-to-end functional flows.

6.3 Advantages and Disadvantages of Black Box Testing

Advantages Disadvantages
No programming knowledge required for Cannot test internal paths and logic.
testers.
Tests from the user's perspective. Limited coverage — many code paths may
remain untested.
Effective for large systems. Test cases may be redundant or difficult to
design.
Independent of implementation details. Cannot identify the root cause of failures
easily.

6.4 Comparison: White Box vs. Black Box Testing

Page 6 | Prepared for BCA Students

BCA-404: Software Engineering | Unit 5: Software Testing Dept. of C.S., DDUGU GKP

White Box Testing Black Box Testing

Tester knows internal code structure. Tester has NO knowledge of internal code.
Also called Glass Box / Structural Testing. Also called Functional / Behavioral Testing.
Based on code logic and paths. Based on requirements and specifications.
Done by developers. Done by testers / QA engineers.
Finds code-level bugs (logic errors). Finds functional bugs (missing features,
wrong output).
Cannot find missing functionality. Cannot test internal paths.
Requires programming expertise. Can be done without programming
knowledge.

7. Levels of Software Testing

Software testing is performed at multiple levels throughout the development process. Each level
has distinct objectives and focus areas.

7.1 Unit Testing

Unit Testing is the first level of testing where individual units or components of the software are
tested in isolation. A 'unit' is the smallest testable part of software — typically a single function,
method, or class.

Definition
Unit Testing focuses on verifying that each individual unit of source code works as intended.
It is usually performed by the developer who writes the code.

Key Characteristics
• Smallest level of testing (tests individual functions/methods).
• Performed by developers during or immediately after coding.
• Uses stubs (dummy modules that replace called functions) and drivers (dummy modules
that call the unit being tested).
• Typically automated using testing frameworks (e.g., JUnit for Java, NUnit for .NET).

What is Tested in Unit Testing?

• Module interface: Are data flowing in/out correctly?
• Local data structures: Are data stored properly?
• Boundary conditions: Do edge cases work?

Page 7 | Prepared for BCA Students

BCA-404: Software Engineering | Unit 5: Software Testing Dept. of C.S., DDUGU GKP

• Independent paths: Are all logical paths exercised?

• Error handling paths: Are exceptions handled properly?

Stubs and Drivers

Driver: A program that calls the unit being tested and passes test data to it. Used when the unit
to be tested requires input from a higher-level module that doesn't yet exist.
Stub: A replacement for a module that the unit being tested calls. It simulates the behavior of
the called module with simplified (dummy) logic.

7.2 Integration Testing

Integration Testing is the second level of testing where individual units are combined and tested
as a group. The purpose is to expose faults in the interaction between integrated units. Even if
each unit works correctly individually, errors can occur at the interfaces between modules.

📌 KEY POINT: Integration Testing addresses the question: 'Do the pieces work together
correctly?' It focuses on interfaces and communication between modules.

Types of Integration Testing Approaches

A. Big Bang Integration

All components are integrated simultaneously and tested together at once.
• Advantage: Simple; requires little planning.
• Disadvantage: Very difficult to isolate and locate defects. Not recommended for large
systems.

B. Top-Down Integration
Testing begins from the topmost module (main module) and progressively incorporates lower-
level modules. Stubs are used to simulate lower-level modules not yet integrated.
• Advantage: Major design flaws are found early. The high-level logic is tested first.
• Disadvantage: Requires many stubs. Lower-level modules (which often contain key
logic) are tested late.

C. Bottom-Up Integration
Testing begins from the lowest-level modules (leaves of the module hierarchy) and progressively
integrates higher-level modules. Drivers are used to simulate higher-level modules.
• Advantage: No stubs needed. Real modules are tested from the start.
• Disadvantage: The high-level program structure is tested last. Requires many drivers.

Page 8 | Prepared for BCA Students

BCA-404: Software Engineering | Unit 5: Software Testing Dept. of C.S., DDUGU GKP

D. Sandwich / Hybrid Integration

A combination of top-down and bottom-up approaches. The system is simultaneously tested from
both ends toward the middle layers.
• Advantage: Combines benefits of both approaches.
• Disadvantage: Complex to manage; requires both stubs and drivers.

Approach Direction & Tools

Big Bang All at once. No stubs/drivers needed initially.
Top-Down Top → Bottom. Uses STUBS for lower
modules.
Bottom-Up Bottom → Top. Uses DRIVERS for upper
modules.
Sandwich Both directions simultaneously. Uses both
stubs and drivers.

8. Testing Strategies
A testing strategy is a high-level description of the testing levels, types, and methods to be applied.
It defines the approach to testing throughout the software development lifecycle.

8.1 Verification and Validation (V&V)

Verification Validation
Are we building the product RIGHT? Are we building the RIGHT product?
Checks if the software conforms to Checks if the software meets the user's
specifications. actual needs.
Process-oriented (focuses on development Product-oriented (focuses on the end
process). product).
Performed without executing the code. Performed by executing the code (dynamic).
Examples: Reviews, inspections, Examples: System testing, acceptance
walkthroughs. testing.
Done internally by the development team. May involve the end user or client.

📌 KEY POINT: Memory tip: Verification = 'Are we doing it right?' (process check). Validation
= 'Is it the right thing?' (product check).

Page 9 | Prepared for BCA Students

BCA-404: Software Engineering | Unit 5: Software Testing Dept. of C.S., DDUGU GKP

8.2 Validation Testing

Validation Testing confirms that the final software product meets all the requirements specified in
the Software Requirements Specification (SRS). It is done from the end-user's perspective and
typically occurs near the end of the testing process.

Alpha Testing
Alpha testing is performed by the development team (internal users) at the developer's site, before
releasing the software to external users. The software is used in a simulated or actual
environment.
• Done by: Developers and QA team (internal).
• Purpose: To find bugs before beta release.
• Environment: Controlled, at developer's site.

Beta Testing
Beta testing is performed by a limited number of real end-users (external users) in their own
environment. Users use the software normally and report any bugs or issues they encounter.
• Done by: Real users (external).
• Purpose: To get real-world feedback before full release.
• Environment: Real user environment (uncontrolled).

Alpha Testing Beta Testing

Done by development/QA team. Done by real end-users.
At developer's site. At customer's site.
Controlled environment. Uncontrolled (real) environment.
Before beta release. After alpha testing, before final release.
Developer can observe and record errors. Users report errors to the developer.

8.3 System Testing

System Testing is a high-level testing phase where the complete, fully integrated software product
is tested as a whole. It verifies that the system meets all specified functional and non-functional
requirements. It is performed by an independent testing team before the product is released to
end users.

Scope of System Testing

System Testing treats the software as a black box and tests end-to-end behavior of the
entire application including all integrated components, databases, hardware, networks, and
external interfaces.

Page 10 | Prepared for BCA Students

BCA-404: Software Engineering | Unit 5: Software Testing Dept. of C.S., DDUGU GKP

Types of System Testing

Functional Testing: Verifies that each function of the software works as per the requirements
document. It is black-box testing — only inputs and outputs are considered.
Performance Testing: Tests the speed, responsiveness, stability, and resource usage of the
software under a given workload.
Load Testing: Evaluates system behavior under expected normal and peak load conditions.
Determines the maximum operating capacity.
Stress Testing: Tests the system under extreme workload conditions beyond its normal
operating limits to find its breaking point.
Security Testing: Identifies vulnerabilities, threats, and risks in the software and ensures that
data and resources are protected from unauthorized access.
Usability Testing: Evaluates how easily and efficiently users can use the software. Focuses on
user interface and user experience.
Compatibility Testing: Verifies that the software works correctly across different environments,
hardware, operating systems, browsers, and network configurations.
Recovery Testing: Tests how well the system can recover from crashes, hardware failures, or
other errors.
Regression Testing: Re-testing the software after modifications to ensure that existing
functionality has not been broken by recent changes.

9. The Complete Testing Flow (V-Model)

The V-Model (Verification and Validation Model) represents the relationship between each testing
phase and the corresponding development phase. Testing activities are planned in parallel with
development activities.

Development Phase Testing Phase

Requirements Analysis Acceptance Testing (User)
System Design System Testing
High-Level Design Integration Testing
Low-Level Design / Coding Unit Testing

10. Important Terms and Definitions

Bug / Defect / Fault: An imperfection or flaw in the software that causes it to produce incorrect
or unexpected results.
Error: A human mistake (made by a programmer) that leads to a fault in the program.

Page 11 | Prepared for BCA Students

BCA-404: Software Engineering | Unit 5: Software Testing Dept. of C.S., DDUGU GKP

Failure: The observable incorrect behavior of a program when it is executed — the

manifestation of a defect.
Test Plan: A document describing the scope, approach, resources, and schedule of testing
activities.
Test Suite: A collection of test cases intended to test a program to show that it has some set of
behaviors.
Regression Testing: Re-testing software after changes or bug fixes to confirm no new defects
were introduced.
Smoke Testing: A preliminary test that checks whether the most critical functions of a program
work. Done before detailed testing.
Sanity Testing: A quick test to confirm that a specific function or bug fix works after a minor
change.
Acceptance Testing: Formal testing to determine if a system satisfies acceptance criteria and
enables the customer to decide if it should be accepted.
Test Coverage: A measure of how much of the software (code, requirements, or functionality)
is covered by test cases.

EXAM PREPARATION TIPS

1. Always differentiate White Box vs. Black Box testing with a clear comparison table.
2. Remember: V&V — Verification = 'Building it right', Validation = 'Building the right
thing'.
3. Know the integration testing approaches (Big Bang, Top-Down, Bottom-Up) and their
stubs/drivers.
4. Cyclomatic Complexity formula: V(G) = E - N + 2P (must memorize for White Box
section).
5. Know the 7 Principles of Software Testing — frequently asked in theory exams.
6. Alpha testing = internal (developer site); Beta testing = external (user site).
7. System Testing is BLACK BOX testing of the fully integrated system.

— End of Unit 5 Notes —

Page 12 | Prepared for BCA Students