SOFTWARE TESTING

BCA 204T
END TERM EXAMINATION NOTES
All 4 Units | Complete Syllabus Coverage

Total Marks 60 Marks

Units Covered Unit 1 to Unit 4
Faculty Dr. Latika Kharb
UNIT 1: INTRODUCTION TO SOFTWARE TESTING
This unit covers the fundamental concepts of software testing including what testing is, why it
matters, the key principles, error taxonomy, test cases, the Software Testing Life Cycle (STLC),
verification and validation, static and dynamic testing, and review techniques.

1.1 What is Software Testing?

Software testing is the systematic process of executing and evaluating software with the intention of
finding defects and verifying that the software satisfies its functional and non-functional
requirements. It is a quality assurance activity that ensures the developed software behaves
correctly according to user needs and design specifications before it is deployed to production.

Why is Software Testing Hard?

Software testing is considered difficult due to the following reasons:
● It is practically impossible to test all possible input combinations and execution paths (called
exhaustive testing).
● Modern applications run on multiple platforms, devices, networks, and environments,
increasing complexity.
● Requirements frequently change during development, forcing testers to continuously update
test cases.
● Human factors such as misunderstanding requirements lead to ineffective test cases.
● Time and budget constraints reduce the depth and coverage of testing.

EXAM TIP: 'Why is testing hard?' is a common 2-mark or 5-mark question. Always mention: exhaustive
testing is impossible, changing requirements, platform diversity, and human factors.

1.2 Goals of Software Testing

● Detect defects as early as possible in the development lifecycle.
● Verify that the software meets all specified requirements.
● Validate that the software meets user expectations and needs.
● Reduce the cost of fixing errors by identifying them before deployment.
● Improve reliability, security, and performance of the software.
● Build confidence among stakeholders that the system is ready for release.

1.3 Principles of Software Testing

The seven principles of software testing are universally accepted guidelines that improve the
effectiveness of testing:

# Principle Explanation
1 Testing shows presence Testing can reveal that defects exist but cannot prove that the
of defects software is completely defect-free.
2 Exhaustive testing is Testing every possible input, path, and scenario is not feasible;
 # Principle Explanation
impossible testers must use risk-based prioritization.
3 Early testing Testing activities should begin as early as possible in the SDLC to
reduce cost of fixing defects.
4 Defect clustering A small number of modules typically contain the majority of defects
(80-20 rule / Pareto principle).
5 Pesticide paradox Repeating the same test cases reduces their effectiveness; test
cases must be regularly reviewed and updated.
6 Testing is context- Different types of applications (banking, gaming, e-commerce)
dependent require different testing strategies.
7 Absence-of-errors fallacy Even a defect-free software can fail if it does not meet user needs or
business requirements.

EXAM TIP: All 7 principles are important. In 10-mark questions, explain each principle with an example.
The 'pesticide paradox' and 'absence-of-errors fallacy' are favorites.

1.4 Error, Fault, Failure, and Incident Taxonomy

Understanding the difference between these terms is critical for defect analysis:

Term Definition Example

Error A human mistake made during design Developer writes wrong logic for a
or coding. calculation.
Fault / Defect / Bug The result of an error introduced in the The wrong code line present in the
software artifact (code, doc, design). program.
Failure When the faulty code executes and User gets wrong output when
produces incorrect output or behavior. performing the calculation.
Incident An observable event or user-reported User raises a complaint that the result
symptom that reveals the failure. is wrong.

NOTE: Flow: Error (human mistake) → Fault (defect in code) → Failure (wrong output) → Incident (user
complaint).

1.5 Test Cases

A test case is a documented set of inputs, execution conditions, and expected outcomes designed
to verify whether a specific feature or function of the software works correctly. Test cases are the
foundation of systematic, repeatable, and traceable testing.

Components of a Test Case:

Component Description
Test Case ID A unique identifier for the test case (e.g., TC_001).
Description Brief statement of what is being tested.
Pre-conditions Conditions that must be met before test execution.
 Component Description
Input Data The specific values or actions used during the test.
Expected Result The correct output or behavior the system should produce.
Actual Result The output observed during execution.
Test Status Pass or Fail based on comparison of expected and actual results.

Importance of Test Cases:

● Provide traceability between requirements and testing activities.
● Ensure consistent and repeatable test execution.
● Support regression testing when software changes are made.
● Improve testing efficiency and reduce ambiguity.

1.6 Software Testing Life Cycle (STLC)

The Software Testing Life Cycle (STLC) is a structured sequence of activities performed during
testing. Each phase has specific entry and exit criteria, deliverables, and objectives.

Phase Activity Deliverable

1. Requirement Study requirements; identify testable Requirement Traceability
Analysis conditions; understand scope. Matrix (RTM)
2. Test Planning Define strategy, resources, schedule, tools, Test Plan Document
risks, and scope.
3. Test Case Design Write detailed test cases, test scripts, and Test Cases & Test Data
prepare test data.
4. Test Environment Set up hardware, software, network, and Test Environment Ready
Setup test tools.
5. Test Execution Execute test cases; log defects; retest fixed Defect Reports, Test Logs
bugs.
6. Test Closure Evaluate exit criteria; prepare summary; Test Summary Report
document lessons learned.

EXAM TIP: STLC phases are asked as 5-mark and 10-mark questions. Write all 6 phases in sequence
with deliverables for full marks.

1.7 Verification and Validation

Verification and validation (V&V) are two complementary quality assurance processes. They are
often confused but have distinct meanings.

Aspect Verification Validation

Definition Checking that software is built Checking that the right software is
correctly according to specifications. being built for user needs.
Question Answered Are we building the product right? Are we building the right product?
 Aspect Verification Validation
Nature Static (no execution required) Dynamic (software is executed)
Activities Reviews, Inspections, Walkthroughs, Unit Testing, System Testing, UAT
Audits
When Performed During development phases After development, before/after
release
Who Performs Developers and QA team QA team, customers, end users

V-Testing Life Cycle (V-Model):

The V-model (Verification and Validation model) represents the relationship between development
phases and testing phases in a V-shape. Each development phase on the left side of the V has a
corresponding testing phase on the right side. This model emphasizes early test planning and
ensures that tests are designed in parallel with development.

Development Phase (Left of V) Testing Phase (Right of V)

Requirements Analysis Acceptance Testing
System Design System Testing
High-Level Design Integration Testing
Low-Level Design Unit Testing
Coding (Center of V - Implementation)

Limitations of Software Testing:

● Testing cannot guarantee that software is 100% defect-free.
● Exhaustive testing of all input combinations is not feasible.
● Testing effectiveness depends heavily on tester skill and test case quality.
● Time, budget, and resource constraints limit testing coverage.
● Not all defects can be reproduced consistently during testing.

1.8 Static and Dynamic Testing

Aspect Static Testing Dynamic Testing

Definition Testing without executing the Testing by executing the software.
software.
When Used Early in development lifecycle. After code is developed.
Objective Find defects in documents, design, Validate actual behavior and runtime
and code. errors.
Techniques Reviews, Inspections, Walkthroughs Unit, Integration, System, Acceptance
Testing
Who Performs Developer, Reviewer, QA QA Team, Developers
Cost to Fix Very low (early detection) Higher (later detection)
1.9 Inspection, Walkthrough, and Technical Review
These are three types of static testing review techniques used to examine software artifacts early in
the lifecycle.

Inspection:
Inspection is the most formal review technique. A structured team review process where software
artifacts are systematically examined using predefined checklists and entry/exit criteria.
● Purpose: Detect defects early, ensure compliance with standards, improve quality.
● Team: Moderator, Author, Reader, Inspector, Scribe.
● Process: Planning → Overview → Preparation → Inspection Meeting → Rework → Follow-
up.
● Formality: Highest among all review techniques.

Walkthrough:
A walkthrough is an informal review process where the author presents and explains a software
document or code to peers for feedback and defect identification.
● Purpose: Share knowledge, gather feedback, find obvious defects.
● Led by: The author of the artifact.
● Formality: Informal; no strict rules or checklists.
● Output: Issues list, suggestions, improved understanding.

Technical Review:
A technical review is a formal peer review of a technical artifact conducted by qualified technical
experts to verify correctness, design quality, and adherence to standards.
● Purpose: Ensure technical correctness, identify design issues, verify compliance.
● Led by: A trained moderator (not the author).
● Formality: More formal than walkthrough but less than inspection.

Feature Inspection Walkthrough Technical Review

Formality Highest Lowest Medium
Led by Moderator Author Moderator
Checklists Used Yes No Sometimes
Primary Goal Defect detection Knowledge sharing Technical correctness
Documentation Formal reports Informal notes Review reports

EXAM TIP: Comparison of Inspection vs Walkthrough vs Technical Review is a very common 10-mark
question. Use the table format in your answer.
UNIT 2: FUNCTIONAL AND STRUCTURAL TESTING
This unit covers two major categories of testing: Functional Testing (Black Box) and Structural
Testing (White Box), along with specific techniques under each.

2.1 Functional Testing (Black Box Testing)

Functional testing is a type of software testing that validates the software's functional requirements
by checking whether the system behaves as expected for given inputs and produces correct
outputs, without any knowledge of the internal code or structure. It is performed from the user's
perspective.

Key Characteristics of Black Box Testing:

● Tester has NO knowledge of internal code, design, or structure.
● Test cases are designed based on requirements and specifications.
● Used for System Testing and Acceptance Testing.
● Validates software from the end-user's perspective.
● Finds missing functions, interface errors, incorrect behavior, and performance issues.

2.2 Boundary Value Analysis (BVA)

Boundary Value Analysis is a black box testing technique based on the observation that errors are
most likely to occur at the boundaries of input ranges rather than in the middle. Test cases are
designed to target these boundary values.

How BVA Works:

For a given input range [min, max], the test values selected are:
Value Type Description Example (Range: 1 to 100)
Minimum Lowest valid value 1
Just below minimum Invalid value just below range 0
Just above minimum Valid value just above minimum 2
Maximum Highest valid value 100
Just below maximum Valid value just below maximum 99
Just above maximum Invalid value just above range 101

● Advantage: Reduces test cases while maximizing defect detection at boundaries.

● Use case: Numeric ranges, date fields, string lengths, age fields.

EXAM TIP: In BVA questions, always list all 6 boundary values for a given range. For range 1-100, write:
0, 1, 2, 99, 100, 101.
2.3 Equivalence Class Testing (ECT)
Equivalence Class Testing (also called Equivalence Partitioning) is a black box testing technique
that divides the input domain into groups (equivalence classes) where all values in a group are
expected to behave the same way. Testing one representative value from each class is sufficient.

Types of Equivalence Classes:

● Valid Classes: Input values that are accepted by the system and produce expected results.
● Invalid Classes: Input values that the system should reject or handle with error messages.

Example:
For a field that accepts age between 18 and 60:
Class Range Test Value Expected Result
Valid Class 18 to 60 35 Accepted
Invalid Class 1 Less than 18 10 Error / Rejected
Invalid Class 2 Greater than 60 70 Error / Rejected

● Advantage: Significantly reduces the number of test cases without sacrificing coverage.
EXAM TIP: Often combined with BVA in exam questions. ECT identifies the classes; BVA then tests the
boundaries of those classes.

2.4 Decision Table Based Testing

Decision Table Based Testing is a functional testing technique used when the system's behavior
depends on multiple input conditions and their combinations. A decision table captures all possible
combinations of conditions (True/False) and their corresponding actions/outputs.

Structure of a Decision Table:

Section Description
Conditions Input variables or business rules (rows at the top). Each column is a rule.
Actions Output or system behavior corresponding to each rule (rows at the
bottom).
Rules Each column represents a unique combination of condition values.

Example - Login System:

Conditions: Valid Username (Y/N) and Valid Password (Y/N)
Condition / Action Rule 1 Rule 2 Rule 3 Rule 4
Valid Username Y Y N N
Valid Password Y N Y N
Action: Grant Access Yes No No No
Action: Show Error No Yes Yes Yes
 ● Advantage: Ensures all condition combinations are tested; prevents missed test cases.
● Used in: Banking, insurance, e-commerce, any system with complex business rules.

EXAM TIP: For 2 conditions, there are 4 rules (2^2). For 3 conditions, there are 8 rules (2^3). In a 10-
mark question, draw the full table.

2.5 Structural Testing (White Box Testing)

Structural testing (also called White Box Testing or Glass Box Testing) is a testing approach that
focuses on the internal logic, code structure, and execution paths of the software. The tester must
have complete knowledge of the source code.

Key Characteristics:
● Tester has FULL knowledge of internal code, design, and logic.
● Tests are designed based on source code analysis.
● Commonly performed during Unit Testing and Integration Testing.
● Verifies statements, branches, conditions, loops, and execution paths.
● Helps find logical errors, dead code, security vulnerabilities, and incorrect conditions.

Feature Black Box Testing White Box Testing

Knowledge of Code Not required Required
Based on Requirements / Specifications Internal Logic / Source Code
Performed by Testers Developers / Senior Testers
Focus Functional correctness Code coverage & logic
Also Known As Functional / Closed Box Testing Structural / Glass Box / Clear Box
Techniques BVA, ECT, Decision Table Path Testing, Cyclomatic
Complexity

2.6 Path Testing

Path testing is a white box testing technique where test cases are designed to cover all possible
execution paths through the program. An execution path is a unique sequence of statements from
the start to the end of a program.

● Objective: Ensure every independent path in the program is executed at least once.
● Basis: Program's Control Flow Graph (CFG).
● Limitation: Complete path testing is impractical for large programs due to exponential path
growth.

Control Flow Graph (CFG) Concepts:

● Node: Represents a statement or group of sequential statements.
● Edge: Represents the flow of control between two nodes.
● Decision node: A node with more than one outgoing edge (if, while, switch).
 ● Junction node: A node with more than one incoming edge.

2.7 DD Paths (Decision-to-Decision Paths)

A Decision-to-Decision (DD) path is an execution path in a program that starts from one decision
point and ends at the next decision point, containing no intermediate decision points. DD paths
represent the basic executable units between decisions.

● Purpose: Simplify complex programs by breaking them into segments between decision
points.
● Use: Forms the basis for constructing the DD graph, which is used for path-based test case
design.
NOTE: DD paths help testers identify all unique execution segments and ensure each segment is tested
at least once.

2.8 Cyclomatic Complexity

Cyclomatic Complexity is a software metric used to measure the logical complexity of a program. It
determines the minimum number of test cases required to cover all independent paths in the
program. It was proposed by Thomas J. McCabe.

Formula:
V(G) = E - N + 2P
Symbol Meaning
V(G) Cyclomatic Complexity of graph G
E Number of edges in the Control Flow Graph
N Number of nodes in the Control Flow Graph
P Number of connected components (usually P = 1 for a single program)

Alternative Formulas:
● V(G) = Number of decision nodes + 1: (Count all if, while, for, case statements and add 1)
● V(G) = Number of regions in the planar graph: (Count all closed regions + 1 for the outer
region)

Complexity Interpretation:
Cyclomatic Complexity Risk Level Meaning
1 to 10 Low risk Simple, well-structured, easy to test
11 to 20 Moderate risk Moderate complexity; needs careful testing
21 to 50 High risk Complex code; difficult to test thoroughly
Above 50 Very high risk Untestable; must be refactored
 EXAM TIP: Cyclomatic Complexity is a guaranteed question. V(G) = E - N + 2 is the key formula. Also
remember: V(G) = number of decision points + 1.

2.9 Graph Metrics

Graph metrics are quantitative measures derived from the Control Flow Graph (CFG) that provide
insight into the testability and complexity of a program. Key graph metrics include:

● Number of nodes (N): Total statement nodes in the CFG; higher N means more statements
to cover.
● Number of edges (E): Total control flow paths; directly used in cyclomatic complexity
calculation.
● Number of paths: Total unique execution paths through the program; determines testing
effort.
● Cyclomatic Complexity V(G): Measures logical complexity and minimum number of
independent paths.
● Graph density: Ratio of edges to nodes; high density implies higher complexity.

2.10 Data Flow Testing

Data Flow Testing is a white box testing technique that focuses on the definition and use of
variables in the program. It tracks where variables are defined (assigned values) and where they
are used in the program to detect data-related errors.

Key Terms:
● Definition (def): A point in code where a variable is assigned a value (e.g., x = 5).
● Use (use): A point where the variable's value is accessed or referenced.
● P-use (Predicate use): Variable used in a condition or predicate (e.g., if x > 0).
● C-use (Computation use): Variable used in a computation or output (e.g., y = x + 1).
● Def-use pair: A pair (d, u) where a variable is defined at d and used at u without being
redefined in between.

Types of Data Flow Anomalies (Errors):

● Defined but never used (du): A variable is assigned a value but never referenced —
wasted code.
● Used before defined (ud): A variable is referenced before it has been assigned a value —
runtime error risk.
● Defined twice without use (dd): A variable is defined again before its first definition is ever
used.

● Advantage of Data Flow Testing: Detects data-related bugs that structural path testing
may miss; improves code reliability.

EXAM TIP: Data flow testing definitions (def, p-use, c-use, def-use pair, anomalies) are commonly asked
as short-answer or explanation questions.
UNIT 3: LEVELS OF TESTING
Software testing is performed at different levels of the development process. Each level focuses on
testing a specific aspect of the software. The four main levels are Unit Testing, Integration Testing,
System Testing, and Acceptance Testing.

3.1 Property Issues in Software Testing

Property issues refer to the fundamental quality attributes that software must satisfy beyond just
functional correctness. Testing must verify these properties to ensure overall software quality.

Property Description
Correctness The software produces correct output for all valid inputs as per
requirements.
Reliability The software performs its functions consistently without failure over time.
Efficiency The software uses hardware resources (CPU, memory) optimally.
Usability The software is easy to learn, use, and understand by end users.
Security The software protects data and functionality from unauthorized access.
Maintainability The software can be easily modified, corrected, and enhanced.
Portability The software can run on different platforms and environments.

NOTE: A system may be functionally correct but still fail property testing. For example, it might be correct
but too slow (efficiency issue) or too difficult to use (usability issue).

3.2 Unit Testing

Unit testing is the first and lowest level of software testing, where individual components or units of
a program are tested in complete isolation from the rest of the system. A unit is typically a single
function, method, class, or module.

Key Characteristics:
● Performed by developers during or immediately after the coding phase.
● Uses white box testing techniques (knowledge of internal code required).
● Each unit is tested independently — other units are replaced by stubs or drivers.
● Automated using frameworks like JUnit (Java), NUnit (.NET), PyTest (Python).

Key Concepts in Unit Testing:

● Stub: A dummy replacement for a called module that returns predefined values. Used in top-
down testing.
● Driver: A dummy replacement for the calling module that invokes the unit under test. Used
in bottom-up testing.
● Test harness: A collection of stubs and drivers used to support unit testing in isolation.
Benefits of Unit Testing:
● Identifies logical errors and incorrect calculations early at low cost.
● Simplifies debugging because defects are found close to their source.
● Provides a safety net for refactoring — ensures existing functionality is not broken.
● Serves as documentation of expected behavior for each unit.
● Forms a strong foundation for higher-level testing.

EXAM TIP: The difference between Stub and Driver is a very common question. Stub = called module
replacement; Driver = calling module replacement.

3.3 Integration Testing

Integration testing is the level of testing where individual units are combined together and tested as
a group. The objective is to verify that the integrated modules communicate and interact correctly
with each other. Even when individual units work perfectly, defects can arise in their interactions.

Common Integration Defects:

● Interface mismatches — data types, formats, or parameters don't match between modules.
● Incorrect data flow — wrong data is passed between modules.
● Improper assumptions about other modules' behavior.
● Timing and synchronization issues between components.

Approaches to Integration Testing:

Approach Description Advantage
Top-Down Integration Testing starts from the topmost Early validation of high-level
module; lower modules are replaced control logic.
by stubs.
Bottom-Up Integration Testing starts from the lowest-level Tests fundamental modules
modules; upper modules are replaced first.
by drivers.
Sandwich / Hybrid Combines top-down and bottom-up; Reduces time; balances
testing occurs simultaneously from advantages of both.
both ends.
Big Bang Integration All modules are integrated and tested Simple to set up but hard to
at once. isolate defects.

EXAM TIP: Top-Down vs Bottom-Up integration is a classic comparison question. Remember: Top-Down
uses Stubs; Bottom-Up uses Drivers.

3.4 System Testing

System testing is the level of testing where the complete, integrated software system is tested as a
whole. It verifies that the entire system meets all specified functional and non-functional
requirements. System testing is performed by an independent QA team in an environment that
closely resembles the production environment.
Key Features:
● Tests end-to-end behavior of the complete application.
● Performed after integration testing and before acceptance testing.
● Validates both functional and non-functional requirements.
● Performed by independent testing team (not developers).

Categories of System Testing:

Category Description Focus Area
Functional System Testing Verifies all system functions work Business logic, feature
correctly as per requirements. correctness
Performance Testing Evaluates responsiveness, speed, Speed, throughput, response
scalability, and stability under load. time
Load Testing Tests system behavior under expected System stability under high
and peak load conditions. users
Stress Testing Tests system beyond normal capacity System limits and recovery
to find breaking points.
Security Testing Checks for vulnerabilities, Authentication, authorization,
unauthorized access, data breaches. encryption
Usability Testing Evaluates how user-friendly and User experience, navigation,
intuitive the system is. UI clarity
Compatibility Testing Checks software works across Cross-platform, cross-
different browsers, OS, devices. browser behavior
Regression Testing Re-testing after changes to ensure Impact of new changes on
existing functionality is not broken. old features
Recovery Testing Tests system's ability to recover from Fault tolerance, backup,
crashes, hardware failures. restore

EXAM TIP: Categories of System Testing is a very common 10-mark question. Write at least 6-7
categories with descriptions. Use the table format.

3.5 Acceptance Testing

Acceptance testing is the final level of software testing, performed to determine whether the
software is ready for delivery and acceptable to the end users or customers. The primary goal is to
validate that the software meets business requirements and user expectations in real-world
conditions.

Key Features:
● Performed by customers, end users, or stakeholders (not developers).
● Focuses on real-world usage scenarios and workflows.
● A successful acceptance test authorizes product release/deployment.
● Checks that the software delivers actual business value.

Types of Acceptance Testing:

 Type Who Performs Where Performed Purpose
User Acceptance End users / At customer's or Verify software meets user
Testing (UAT) customers user's site needs and workflows.
Alpha Testing Internal test team At developer's site Find defects before external
or select users (controlled release; done by
environment) developer's organization.
Beta Testing Selected external Real user Gather user feedback; find
users environments issues missed internally.
Operational Acceptance Operations / IT Production-like Verify system readiness for
Testing (OAT) team environment deployment (backup,
recovery, maintenance).
Contract Acceptance Client and QA team As per contract Verify all contractual
Testing requirements are met.
Regulation Acceptance Regulatory body / Independent audit Ensure compliance with
Testing auditors environment legal and regulatory
standards.

EXAM TIP: Alpha vs Beta Testing is a very commonly asked comparison. Alpha = at developer's site,
controlled; Beta = real user environment, external users.

Feature Alpha Testing Beta Testing

Who Internal team / selected users External users / customers
Where Developer's site (controlled) User's real environment
(uncontrolled)
When Before beta release After alpha, before final release
Goal Find remaining defects; improve Gather user feedback; find field-
quality specific issues
Control High Low

Overall Comparison of Testing Levels:

Level Focus Performed By Techniques
Unit Testing Individual Developers White Box
modules/functions Testing
Integration Testing Module interaction and Developers / QA Top-Down,
interfaces Bottom-Up, Big
Bang
System Testing Complete system vs Independent QA Team Functional,
requirements Performance,
Security Testing
Acceptance Testing Business needs & user Customers / End Users UAT, Alpha, Beta
satisfaction Testing
UNIT 4: TEST PLANNING AND TEST MANAGEMENT
This unit covers the complete process of planning, organizing, and managing software testing
activities. It includes preparing a test plan, scope management, setting criteria, staffing, resource
planning, and advanced test management activities like traceability and test reporting.

4.1 Test Planning

A test plan is a formal, comprehensive document that describes the scope, objectives, approach,
resources, schedule, risks, and responsibilities of all testing activities in a project. It acts as a
roadmap for the entire testing effort and is the single most important testing document.

Objectives of a Test Plan:

● Communicate the testing strategy to all stakeholders.
● Define what will be tested and what will not be tested.
● Identify required resources, tools, environments, and timelines.
● Provide a reference for monitoring and controlling testing progress.

Components of a Test Plan (IEEE 829 Standard):

# Component Description
1 Test Plan Identifier Unique ID for document control.
2 Introduction & Objectives Purpose and goals of the test plan.
3 Test Scope Features to be tested and not tested.
4 Test Approach / Strategy Testing types, levels, and techniques to be used.
5 Test Items Software modules and features to be tested.
6 Entry & Exit Criteria Conditions for starting and completing testing.
7 Test Deliverables Documents to be produced during testing.
8 Testing Tasks Specific activities with assigned owners.
9 Resource Requirements People, tools, environments, hardware needed.
1 Responsibilities Roles and accountability assignments.
0
1 Schedule Timeline with milestones and deadlines.
1
1 Risks and Contingencies Identified risks and mitigation plans.
2

4.2 Scope Management

Scope management in testing defines the boundaries of the testing effort — what will be tested and
what will not be tested. This prevents scope creep (unplanned additions to the testing workload) and
ensures focused, efficient testing.
 ● In-scope: Features and functionalities that ARE included in testing.
● Out-of-scope: Features that are excluded from testing (e.g., third-party modules, legacy
systems).
● Assumptions: Conditions assumed to be true for testing to proceed.
● Constraints: Limitations such as time, budget, environment, or tool restrictions.

NOTE: Poor scope management is one of the leading causes of project delays and budget overruns in
testing. Clear scope reduces conflict and ensures quality within agreed boundaries.

4.3 Deciding Test Approach

The test approach (also called test strategy) defines the overall methodology, techniques, and tools
used during testing. It is a high-level document that guides all testing decisions throughout the
project.

Key Decisions in Test Approach:

● Types of testing to be performed (functional, performance, security, etc.).
● Levels of testing (unit, integration, system, acceptance).
● Testing techniques (BVA, ECT, decision tables, path testing).
● Automation strategy — which tests to automate and which to execute manually.
● Tools to be used (Selenium, JIRA, TestRail, JMeter, etc.).
● Risk-based testing considerations — prioritizing high-risk areas.

Types of Test Strategy:

● Analytical Strategy: Based on risk analysis and requirements.
● Model-based Strategy: Based on formal models of the system.
● Methodical Strategy: Uses a predefined set of conditions like checklists or quality
standards.
● Process-compliant Strategy: Follows industry standards such as IEEE, ISTQB.
● Reactive Strategy: Test cases are designed reactively based on findings during testing.

4.4 Setting Up Criteria for Testing

Testing criteria define the conditions under which testing activities start, stop, or are temporarily
suspended. Clear criteria ensure objective, measurable decision-making.

Criterion Type Definition Example

Entry Criteria Conditions that must be met Build is stable, requirements are
before testing can begin. approved, test environment is ready.
Exit Criteria Conditions that must be met 95% of test cases executed, no open
before testing is considered critical defects, defect density below
complete. threshold.
Suspension Criteria Conditions under which testing is Too many critical bugs make further
temporarily stopped. testing impossible.
Resumption Criteria Conditions under which Critical bugs are fixed and a stable
 Criterion Type Definition Example
suspended testing can be build is provided.
restarted.

EXAM TIP: Entry criteria vs Exit criteria is a common exam question. Always give examples with your
definitions. Entry = prerequisites to START; Exit = conditions to STOP.

4.5 Identifying Responsibilities

Clearly identifying testing roles and responsibilities ensures accountability, avoids confusion, and
enables smooth execution of testing activities.

Role Responsibilities
Test Manager / Test Lead Prepares test plan, manages resources, monitors progress,
communicates with stakeholders.
Test Analyst Designs test cases, prepares test data, executes tests, logs defects.
Senior Tester Reviews test cases, leads complex testing, mentors junior testers.
Automation Engineer Designs and maintains automated test scripts and frameworks.
Developer Performs unit testing, fixes defects, supports testers with technical
information.
Business Analyst Clarifies requirements, supports UAT, validates business scenarios.

4.6 Staffing and Training Needs

Staffing:
Staffing in testing involves determining the number and type of testing personnel required for the
project, based on project size, complexity, timeline, and skill requirements.
● Select testers with appropriate technical skills, domain expertise, and experience.
● Ensure balanced workload distribution across the testing team.
● Inadequate staffing leads to poor coverage; overstaffing increases cost unnecessarily.

Training Needs:
Training ensures that the testing team has the required skills and knowledge for the project.
● New tools training — when new automation tools or testing frameworks are introduced.
● Domain training — when testing in specialized domains like healthcare or finance.
● Process training — when adopting new methodologies like Agile or DevOps testing.
● Regular training improves defect detection capability and adoption of best practices.

4.7 Resource Requirements

Proper identification and allocation of resources ensures uninterrupted testing activities. Resources
include:
 Resource Type Examples
Hardware Servers, computers, mobile devices, printers for testing
Software Application under test, operating systems, browsers
Tools Test management tools (TestRail), defect tracking (JIRA), automation
(Selenium)
Test Environments Development, staging, production-like environments for different test
levels
Test Data Sample datasets, realistic data, edge-case data for test execution
Human Resources Testers, QA leads, automation engineers, business analysts

4.8 Test Deliverables

Test deliverables are the tangible outputs and documents produced during the testing process.
They provide evidence of testing activities and help stakeholders assess software quality.

Phase Deliverable
Test Planning Test Plan Document
Test Design Test Case Specifications, Test Data
Test Execution Test Execution Logs, Defect Reports
Test Closure Test Summary Report, Defect Metrics, Lessons Learned
Throughout Requirement Traceability Matrix (RTM)

4.9 Testing Tasks

Testing tasks represent the actual work performed during the testing process. They must be clearly
defined, scheduled, and tracked.
● Requirement analysis and review.
● Test case design and documentation.
● Test environment setup and configuration.
● Test execution and defect logging.
● Retesting (confirming defect fixes) and regression testing.
● Test reporting and metrics collection.
● Test closure and knowledge documentation.

4.10 Test Infrastructure Management

Test infrastructure management involves planning, setting up, maintaining, and controlling all
environments, tools, and resources needed for testing.

Key Activities:
● Setting up and maintaining test environments (hardware, OS, databases, network).
● Managing test automation tools and ensuring they are up to date.
 ● Managing test data — creating, maintaining, and refreshing realistic test data.
● Environment configuration management — ensuring consistency across environments.
● Monitoring environment availability and resolving environment-related issues.

NOTE: Environment issues (server down, wrong configuration) are a major cause of false test failures.
Reliable test infrastructure is critical for accurate results.

4.11 Test People Management

Test people management focuses on building, leading, motivating, and developing the testing team
to achieve quality goals.

● Performance management — evaluating tester performance and providing constructive

feedback.
● Skill development — identifying skill gaps and providing training opportunities.
● Conflict resolution — addressing team disputes or interpersonal issues constructively.
● Team coordination — ensuring smooth communication between testers, developers, and
managers.
● Motivation — recognizing achievements and maintaining a quality-focused team culture.

4.12 Integrating Testing with Product Release

Integrating testing activities with the product release process ensures that only tested, quality-
approved builds are deployed to production.

● Collaborate with release management to define quality gates before each release.
● Evaluate test results against exit criteria before recommending a release.
● Provide a go / no-go recommendation based on defect status and test coverage.
● Support CI/CD (Continuous Integration / Continuous Deployment) pipelines by running
automated tests on each build.
● Ensure release notes include known defects and their workarounds.

4.13 Test Process Baseline

A test process baseline defines the standard, agreed-upon testing practices, templates, and
reference documents used consistently across all projects in an organization.

Key Baseline Artifacts:

● Test Plan Template: Standard structure for test plans used organization-wide.
● Test Case Specification: Template for documenting test cases uniformly.
● Defect Report Template: Standard format for logging defects.
● Test Summary Report Template: Standard format for communicating test results.

● Purpose of Baseline: Ensures consistency, repeatability, and compliance with quality

standards across projects. Enables process improvement by providing a reference for
measurement.
4.14 Updating Traceability
Traceability is the ability to trace a relationship between requirements, test cases, defects, and test
results. A Requirement Traceability Matrix (RTM) maps each requirement to its corresponding test
cases and test results.

Structure of an RTM:
Requirement ID Requirement Description Test Case ID(s) Test Status Defect ID
REQ-001 User login with valid TC-001, TC-002 Pass -
credentials
REQ-002 User login with invalid TC-003 Fail BUG-101
password
REQ-003 Password reset via email TC-004, TC-005 Pass -

Benefits of Traceability:
● Ensures complete requirement coverage — no requirement is left untested.
● Supports impact analysis — shows which tests are affected when a requirement changes.
● Improves transparency and accountability in the testing process.
● Helps identify gaps in testing coverage early.

EXAM TIP: RTM structure and purpose are frequently asked. Know the 5 columns: Requirement ID,
Description, Test Case ID, Status, Defect ID.

4.15 Test Reporting and Recommending Product Release

Test reporting involves communicating the progress, quality status, defect data, and readiness of
the software to all stakeholders through formal reports.

Key Contents of a Test Report:

Section Description
Test Summary Overview of testing activities performed during the cycle.
Test Execution Status Total test cases: planned, executed, passed, failed, blocked.
Defect Summary Total defects found, fixed, open, critical, high, medium, low severity.
Coverage Metrics Percentage of requirements covered by test cases.
Risk Assessment Identified risks, their likelihood, and mitigation status.
Recommendation Go / No-Go recommendation for product release based on exit criteria.

Product Release Recommendation:

Based on test results and exit criteria evaluation, the testing team provides one of three
recommendations:
● Go (Release Approved): All exit criteria are met, no critical open defects, test coverage is
acceptable.
● Conditional Go: Minor issues remain but they are documented with workarounds;
stakeholders accept the risk.
● No-Go (Release Rejected): Critical defects remain open; exit criteria not met; further testing
required.
QUICK REVISION: KEY CONCEPTS AT A GLANCE

Must-Know Definitions
Term One-Line Definition
Software Testing Systematic process of evaluating software to find defects and verify
requirements.
Error Human mistake made during development (root cause of defects).
Fault / Bug / Defect Error introduced into software artifacts; the defect in the code.
Failure Incorrect behavior observed when faulty code executes.
Incident Observable event reported by a user that exposes a failure.
Test Case Set of inputs, conditions, and expected outputs to verify a function.
STLC Structured phases of testing: Requirement → Planning → Design →
Setup → Execution → Closure.
Verification Checking software is built correctly per specifications (Are we
building it right?).
Validation Checking software meets user needs (Are we building the right
thing?).
V-Model Development model showing corresponding testing phase for each
development phase.
Static Testing Testing without code execution (reviews, inspections, walkthroughs).
Dynamic Testing Testing by executing the software to observe behavior.
Black Box Testing Functional testing with no knowledge of internal code.
White Box Testing Structural testing based on internal code and logic.
BVA Test cases at input range boundaries to catch boundary-related
errors.
ECT / Partitioning Divide inputs into valid/invalid classes; test one value per class.
Decision Table Testing Test all combinations of multiple input conditions and their actions.
Cyclomatic Complexity V(G) = E - N + 2. Measures logical complexity; minimum
independent paths.
DD Paths Execution path between two decision points with no intermediate
decisions.
Data Flow Testing Tests definition and use of variables to detect data-related
anomalies.
Unit Testing Testing individual functions/modules in isolation; uses stubs and
drivers.
Integration Testing Testing combined modules for correct interaction and data flow.
System Testing Testing the complete integrated system against all requirements.
Acceptance Testing Final testing by users/customers to validate business requirements.
Alpha Testing Internal acceptance testing at developer's site before release.
Term One-Line Definition
Beta Testing External acceptance testing by real users before final release.
Test Plan Document defining scope, approach, resources, schedule, and risks
for testing.
Scope Management Defining what is and is not included in the testing effort.
Entry Criteria Prerequisites that must be met before testing can start.
Exit Criteria Conditions that must be met before testing can be declared
complete.
Traceability Matrix (RTM) Document mapping requirements to test cases and results.
Test Deliverable Document or output produced during testing (test plan, defect report,
etc.).
Stub Dummy replacement for a called module (used in top-down
integration testing).
Driver Dummy replacement for a calling module (used in bottom-up
integration testing).

Important Formulas
Formula Meaning
V(G) = E - N + 2P Cyclomatic Complexity using edges (E), nodes (N),
and components (P=1 usually).
V(G) = Number of decision nodes + 1 Alternative formula for Cyclomatic Complexity.
Number of Decision Table Rules = 2^n Where n = number of conditions. (2 conditions = 4
rules, 3 conditions = 8 rules)
BVA values = min-1, min, min+1, max-1, max, Six boundary values for a range [min, max].
max+1

Common 10-Mark Question Topics

● Explain the 7 principles of software testing with examples.
● What is the V-model? Draw and explain with development and testing phases.
● Compare Verification and Validation with examples.
● Compare Black Box and White Box Testing on 6-8 parameters.
● Explain Cyclomatic Complexity with formula, example, and interpretation table.
● Explain all levels of testing (Unit, Integration, System, Acceptance) with examples.
● Explain categories of System Testing with examples.
● Compare Alpha and Beta Testing.
● Explain test planning and components of a test plan.
● What is a Requirement Traceability Matrix? Explain with example.
● Compare Inspection, Walkthrough, and Technical Review.
● Explain Integration Testing approaches (Top-Down, Bottom-Up, Big Bang, Sandwich).
● What is Data Flow Testing? Explain def, use, p-use, c-use, and data anomalies.
● Explain STLC phases with entry criteria, activities, and deliverables.
 Best of luck for your exam!
Study smart. Focus on definitions, comparisons, and formulas.