ST

SOFTWARE TESTING

Software Testing
Complete Revision Notes
BCA 232 | Academic Session 2024-25
Units I · II · III · IV | 11 Hours Each

UNIT I UNIT II UNIT III UNIT IV

Detailed Notes • Diagrams • Examples • Quick Revision

 ■ Table of Contents

Uni Topics Covered Key Diagrams Hr

t s

I Intro to Testing, Goals, Principles, V-Model, STLC Flow 11

Error/Fault/Failure, Test Cases, STLC,
V-Model, Static vs Dynamic

II Black Box (BVA, ECT, Decision Table), White BVA Line, CFG, Black/White 11
Box (Path Testing, Cyclomatic Complexity, Box
DD-Paths, Data Flow)

III Unit Testing, Integration Testing (Big Pyramid, Integration 11

Bang/Top-Down/Bottom-Up), System Testing, approaches
Acceptance Testing

IV Test Planning, Scope, Criteria, Resources, Test Planning Process, Defect 11

Management, Infrastructure, People, Test Lifecycle
Process, RTM

BCA 232 – Software Testing Notes | Page 2

 UNIT – I
■ Introduction to Software Testing

■ 1. What is Software Testing & Why is it Hard?

Software Testing is the process of executing a program or system with the intent of finding errors. It is
a systematic activity to check whether the actual result matches the expected result and to ensure the
software is defect-free, reliable, and meets user requirements.

Why is Software Testing Hard?

Exhaustive testing is The number of input combinations is astronomically large. Even simple
impossible programs have infinite paths.

Dynamic behaviour Software may work fine in testing but fail in production due to different
environments.

Incomplete requirements Testers can only verify against documented requirements; undocumented
needs remain untested.

Time and budget Testing is cut short under project pressure, leaving potential bugs
constraints undetected.

Tester knowledge limits Testers may not know all edge cases or system interactions.

EXAMPLE ■ Why impossible?

A login form with a 10-character username and 10-character password field: if each character can be any of 95
printable ASCII characters, there are 95^20 ≈ 3.58 × 10^39 input combinations — testing all is impossible!

■ 2. Goals of Testing

Find Defects Discover bugs before the software reaches end users — the primary goal.

Gain Confidence Provide evidence that the software satisfies requirements under specified
conditions.

Prevent Defects Improve the development process so fewer bugs are introduced in future.

Risk Reduction Reduce the probability of software failure in production and its business
impact.

Decision Making Provide stakeholders with objective information to decide whether to

release.

■ 3. Seven Principles of Software Testing

BCA 232 – Software Testing Notes | Page 3

1. Testing shows defects Can prove bugs EXIST; cannot prove software is bug-free.
Even 100% tests passed doesn't mean zero bugs.

2. Exhaustive testing impossible All input combos can't be tested. Use risk analysis and
priorities to focus effort.

3. Early testing saves cost Finding a bug in requirements costs 1x; in design 3x; in
production 100x. Start testing early!

4. Defect clustering (80/20) 80% of defects are found in 20% of modules. Focus more on
these high-risk areas.

5. Pesticide paradox If same tests are run again and again, they stop finding new
bugs. Regularly review and update tests.

6. Context dependent A medical device needs different testing than a mobile game.
Testing strategy varies with context.

7. Absence-of-errors fallacy A system with zero bugs that doesn't meet user needs is still
a failure. Meet requirements first!

■■ 4. Error, Fault, Failure & Incident

These four terms are often confused. Here is the precise hierarchy:

Term Definition Who/What Causes It

Developer, designer, or analyst

Error (Mistake) A human action that produces an incorrect result.
makes a mistake.

Fault A flaw in the code or document introduced by the Incorrect code statement,
(Defect/Bug) error. wrong logic, typo.

Runtime deviation from expected behaviour — what The fault gets executed and
Failure
the user sees. produces wrong output.

User loses data, wrong bill

Incident Consequence or event arising because of a failure.
sent, system crash.

EXAMPLE ■ Error → Fault → Failure → Incident

A developer (ERROR) misreads the spec and writes 'tax = price * 0.18' instead of 'price * 0.08' (FAULT). When
user checks out, the receipt shows 18% tax instead of 8% (FAILURE). Customer is overcharged by ■200 and
complains (INCIDENT).

■ 5. Test Cases

A Test Case is a documented set of preconditions, inputs, execution steps, expected results and
postconditions developed for a particular test objective or condition. Every test must be traceable back to at
least one requirement.

BCA 232 – Software Testing Notes | Page 4

Field Description Example

Test Case ID Unique identifier TC_LOGIN_001

Test Title Brief name Login with valid credentials

Precondition Setup before test User account exists, app running

Input Data Values entered user='admin', pass='Admin@123'

Test Steps Step-by-step actions [Link] app [Link] creds [Link] Login

Expected Result What SHOULD happen Dashboard screen loads

Actual Result What DID happen Dashboard loaded successfully

Status Pass/Fail/Blocked PASS ✔

■ 6. Software Testing Life Cycle (STLC)

STLC is a sequence of specific activities conducted during the testing process to ensure software quality
goals are met. It is part of the SDLC but focuses exclusively on testing activities.

Software Testing Life Cycle (STLC)

1 2 3 4 5 6
Requirement Test Test Case Environment Test Test
Analysis Planning Design Setup Execution Closure

Fig 1: STLC – 6 phases of software testing

1. Requirement Analysis Study RTM, identify testable requirements, clarify doubts with
BA/developers.

2. Test Planning Define scope, approach, estimate effort, identify risks, assign
responsibilities.

3. Test Case Design Write detailed test cases, create test data, prepare test scripts.

4. Environment Setup Install and configure hardware/software/network needed for testing.

5. Test Execution Execute test cases, log results, report and track defects in defect tracking
tool.

6. Test Closure Evaluate exit criteria, produce test summary report, record lessons
learned.

BCA 232 – Software Testing Notes | Page 5

 ■ 7. V-Model (Verification & Validation)

The V-Model extends the waterfall model by placing corresponding testing phases opposite to each
development phase. The left side represents Verification (are we building the right product?) and the right
side represents Validation (are we building it right?).

V-Model: Development & Testing Phases

Module ↔ Unit
Design Testing
Architecture ↔ Integration
Design Testing
System ↔ System
Design Testing
Requirements ↔ Acceptance
Analysis Testing
CODING

Fig 2: V-Model – Development phases ↔ Testing phases

★ Key Rule: Each testing phase starts PLANNING during the corresponding dev phase. Actual execution happe

■ 8. Limitations of Testing

■ Testing can only show the presence of defects, not their absence.
■ Complete testing is practically impossible for real software.
■ Testing requires skilled, experienced professionals — not just anyone.
■ Testing cannot fix defects — it can only find them.
■ Testing effectiveness depends on quality of requirements.

■■ 9. Static vs Dynamic Testing

Feature Static Testing Dynamic Testing

Code execution? No – review documents Yes – code is run

When done? Early – requirements/design stage After code is written

Who does it? Reviewers, auditors, peers QA testers, developers

Techniques Inspection, Walkthrough, Review Black Box, White Box

BCA 232 – Software Testing Notes | Page 6

Finds Logic errors, missing requirements Runtime errors, crashes

Cost Lower – no env setup Higher – full env needed

Examples Code review, SRS review Functional test, Regression test

Static Testing Techniques in Detail:

Inspection Most formal. Defined roles: Moderator, Author, Reviewer, Scribe. Uses
checklists. Defects logged formally.

Walkthrough Author presents and explains the document to peers. Less formal. Aims to
educate and get feedback.

Technical Review Peer review to check technical correctness. More structured than
walkthrough, less than inspection.

Desk Checking Developer reviews their own code/document informally before formal
review.

BCA 232 – Software Testing Notes | Page 7

 UNIT – II
■ Functional & Structural Testing

Black Box vs White Box Testing

BLACK BOX WHITE BOX
Input → [???] → Output Input→[CODE VISIBLE]→Output
No code knowledge Full code knowledge
Tests: Functional Tests: Structural
Techniques: BVA, ECT Techniques: Path, CFG
Done by: Testers Done by: Developers

Fig 3: Black Box vs White Box Testing Overview

■ 1. Functional Testing – Black Box Testing

In Black Box Testing, the tester treats the software as a black box — knowing only the inputs and
expected outputs, with no knowledge of internal code. Tests are derived from specifications and
requirements.

A. Boundary Value Analysis (BVA)

Most software errors occur at the boundaries of input domains rather than at the centre. BVA generates
test cases from the extreme ends of input ranges.

Boundary Value Analysis (BVA) – Age 1 to 100

Min Normal Max

0 1 2 50 99 100 101

Invalid Min+1 VALID RANGE (1-100) Max-1 Invalid

Fig 4: BVA – Test points for age range 1 to 100

Rule For a valid range [min, max], test: min-1, min, min+1, any_middle, max-1,
max, max+1

Why effective Input validation code most often fails at boundaries — off-by-one errors
are very common.

Complement Often combined with Equivalence Class Testing for complete coverage.

BCA 232 – Software Testing Notes | Page 8

 EXAMPLE ■ BVA – Month Field (1 to 12)
Test values: 0 (invalid), 1 (min-valid), 2 (min+1), 6 (mid), 11 (max-1), 12 (max-valid), 13 (invalid). 7 test cases
cover all boundary risks!

B. Equivalence Class Testing (ECT)

ECT divides the input domain into classes (partitions) where all values in a class are expected to be
processed identically. Test one representative value from each class instead of all values.

Valid Class Inputs the software should accept and process correctly. E.g., for age
1-100: class = {1,2,...,100}

Invalid Class Inputs the software should reject with an appropriate error message. E.g.,
{<1} and {>100}

Principle If a test case in a class finds a bug, all values in that class likely reveal the
same bug.

Advantage Reduces number of test cases drastically while maintaining good

coverage.

EXAMPLE ■ ECT – Password Field (6 to 12 characters)

Valid: {6,7,...,12 chars} → test with 9 chars. Invalid class 1: {<6 chars} → test with 3 chars. Invalid class 2: {>12
chars} → test with 15 chars. Only 3 test cases needed instead of hundreds!

C. Decision Table Based Testing

A Decision Table captures complex business logic by mapping every combination of conditions to the
corresponding system actions. It ensures no combination is missed.

Rule 1 Rule 2 Rule 3 Rule 4

Condition: Valid Username? YES YES NO NO

Condition: Valid Password? YES NO YES NO

Action: Login Successful? ✔ YES ✘ NO ✘ NO ✘ NO

Action: Show Error? — Wrong Pass Wrong User Both Wrong

★ Advantage: Decision tables guarantee all condition combinations are tested. Good for systems with complex

■ 2. Structural Testing – White Box Testing

In White Box Testing, the tester has full knowledge of the internal code structure. Tests are designed to
exercise specific code paths, branches, loops and conditions.

BCA 232 – Software Testing Notes | Page 9

A. Path Testing
Path testing ensures that every possible execution path through the program is tested at least once. A path
is a sequence of statements from entry to exit of the program.

Statement Coverage Every executable statement executed at least once. Weakest criterion.

Branch Coverage Every decision outcome (True/False) executed. Stronger than statement.

Path Coverage Every unique path from start to end executed. Strongest but often
impractical.

Condition Coverage Each individual condition in a decision takes both True and False values.

B. Cyclomatic Complexity
Cyclomatic Complexity (V(G)) is a quantitative measure of the number of linearly independent paths
through source code. Higher complexity = higher risk = more tests needed.

Control Flow Graph & Cyclomatic Complexity

Start Cyclomatic Complexity

If x>0 V(G) = E - N + 2
True False = Edges - Nodes + 2
V(G) = Decisions + 1
A B =1+1=2
End Ranges:
1-4 : Low complexity
5-10 : Moderate
>10 : High (risky!)

Fig 5: Control Flow Graph and Cyclomatic Complexity formulas

Formula 1 (Graph) V(G) = E − N + 2P where E=edges, N=nodes, P=connected components

(usually 1)

Formula 2 (Decisions) V(G) = Number of decision points + 1 (simplest to calculate)

Formula 3 (Regions) V(G) = Number of enclosed regions in the flow graph + 1

Complexity scale 1–4: Low | 5–10: Moderate | 11–20: High | >20: Very High (refactor
recommended)

EXAMPLE ■ Cyclomatic Complexity Calculation

Code: if(a>0) { if(b>0) { result = a+b; } } else { result = 0; } Decision points: 2 (two 'if' statements). V(G) = 2 + 1
= 3. You need minimum 3 test cases to cover all paths.

BCA 232 – Software Testing Notes | Page 10

C. DD-Paths (Decision-to-Decision Paths)
A DD-Path is a chain of statements between two consecutive decision nodes in the Control Flow Graph. It is
a maximal linear sequence of code with no internal branching.

Case 1 Single node with in-degree = 0 (Entry node of program).

Case 2 Single node with out-degree = 0 (Exit node of program).

Case 3 Single node with in-degree ≥ 2 or out-degree ≥ 2 (Decision node).

Case 4 Single node with in-degree = 1 and out-degree = 1.

Case 5 Maximal chain of ≥ 2 nodes, each with in-degree = 1 and out-degree = 1.

D. Graph Metrics
Node (Statement) Coverage Every node in CFG is traversed. Basic requirement.

Edge (Branch) Coverage Every edge (branch YES/NO) is traversed.

Path Coverage Every path from entry to exit traversed. Infeasible for loops.

Multiple Condition All combinations of conditions in each decision tested.

Coverage

E. Data Flow Testing

Data Flow Testing focuses on the define-use (def-use) sequences of variables. It finds bugs related to
variable misuse — uninitialized variables, dead code, etc.

Definition (def) A variable is assigned a value. E.g., x = 5

Computation Use (c-use) Variable used in a computation. E.g., y = x * 2

Predicate Use (p-use) Variable used in a condition. E.g., if(x > 0)

Def-clear path A path where the variable is not redefined between its definition and use.

du-path A definition-clear path from a definition of x to a use of x.

Goal Cover all def-use pairs: every definition reaches every use through some
path.

EXAMPLE ■ Data Flow – Example

x = 5 (def of x) → if (x > 0) (p-use of x) → y = x + 1 (c-use of x). Data flow test ensures both the p-use and
c-use of x are covered by test cases.

BCA 232 – Software Testing Notes | Page 11

 UNIT – III
■■ Levels of Testing

Testing Levels Pyramid

Unit Testing User validation

Integration Testing Full system

Scope

System Testing Module interactions

Acceptance Testing Most tests, fastest, cheapest

Fig 6: Testing Levels Pyramid – Scope and Cost

■ 1. Unit Testing

Unit Testing is the lowest level of testing where individual components/functions/methods are tested in
isolation from the rest of the system. The goal is to validate that each unit of code performs as designed.

Scope Single function, method, class, or module.

Who performs? Usually the developer who wrote the code.

When? During or immediately after coding (in TDD, written before code).

Techniques White box testing, code coverage tools.

Tools JUnit (Java), PyTest (Python), NUnit (.NET), Jest (JavaScript).

Key advantage Bugs found early when they're cheapest to fix.

Key limitation Cannot catch integration bugs — modules work alone but fail together.

Unit Testing Approaches:

Test-Driven Development Write unit test FIRST → run (fails) → write code → run (passes) →
(TDD) refactor.

BCA 232 – Software Testing Notes | Page 12

Behaviour-Driven Tests written in plain English using Given/When/Then format.
Development (BDD)

Code Coverage Targets Typically aim for 70-80% line coverage as minimum threshold.

EXAMPLE ■ Unit Test – add() function

Function: def add(a, b): return a + b. Test 1: add(2, 3) == 5 (PASS). Test 2: add(-1, 1) == 0 (PASS). Test 3:
add(0, 0) == 0 (PASS). Test 4: add(1000000, 1000000) == 2000000 (PASS).

■ 2. Integration Testing

Integration Testing verifies that multiple units/modules work correctly when combined together. Even if
each unit works perfectly in isolation, interface defects can cause failures at the integration level.

Top-Down Integration Bottom-Up Integration

Module A Module A

Module B Module C Module B Module C

Stub Stub Unit 1 Unit 2

Stubs replace lower modules Drivers replace upper modules

Fig 7: Top-Down vs Bottom-Up Integration Testing

Integration Strategies:
Big Bang All modules integrated at once and tested together. Simple but very hard
to isolate bugs.

Top-Down Start with the top-level module; lower modules replaced by STUBS. Tests
high-level flow first.

Bottom-Up Start with lowest-level modules; higher modules replaced by DRIVERS.

Tests fundamental units first.

Sandwich/Hybrid Combines Top-Down and Bottom-Up simultaneously. Most practical for

large systems.

Stub A dummy module used in place of a LOWER module not yet developed.
Used in Top-Down approach.

BCA 232 – Software Testing Notes | Page 13

Driver A dummy module used in place of a HIGHER module not yet developed.
Used in Bottom-Up approach.

Strategy Integration Defect Special Best For

Order Isolation Components

Big Bang All at once Very Hard No stubs/drivers Small systems

needed

Top-Down Top to bottom Easy Needs stubs Requirements-driven

projects

Bottom-Up Bottom to top Medium Needs drivers Fundamental-first

projects

Sandwich Both ways Medium Both stubs & drivers Large complex systems

EXAMPLE ■ Integration Bug Example

Module A (Order) calls Module B (Payment). Both pass unit tests. But A sends amount as integer (e.g. 500)
while B expects a float (e.g. 500.00). Integration test reveals a type mismatch error that neither unit test could
catch.

■■ 3. System Testing

System Testing is the process of testing the complete, integrated system against the specified system
requirements. Performed by the QA/testing team — NOT the development team.

Categories of System Testing:

Functional Testing Verifies each function/feature works as per requirements. Uses black box
approach.

Performance Testing Evaluates system speed, responsiveness and stability under various
workloads.

Load Testing Tests system under expected peak load conditions. How many users can it
handle?

Stress Testing Tests system beyond its limits to see how it fails and recovers.

Usability Testing Evaluates how easy and intuitive the system is for end users.

Security Testing Finds vulnerabilities: SQL injection, XSS, unauthorised access.

Compatibility Testing Tests across different OS, browsers, screen sizes, and devices.

Recovery Testing Verifies system can recover from crashes, power failures, or hardware
errors.

Installation Testing Ensures software installs, updates and uninstalls cleanly.

BCA 232 – Software Testing Notes | Page 14

Regression Testing Re-tests previously working features after code changes to ensure nothing
broke.

Sanity Testing Quick check to ensure a specific bug fix or feature works before full
regression.

Smoke Testing High-level check to verify the build is stable enough for detailed testing.

EXAMPLE ■ System Testing – E-commerce App

Functional: Can user complete checkout? Performance: 10,000 users simultaneously browse without
slowdown? Security: SQL injection on search bar returns no data? Compatibility: Works on Chrome, Safari,
Firefox, Edge?

■ 4. Acceptance Testing

Acceptance Testing is the final phase where the client or end users verify the system meets their business
requirements before signing off and going live. Also known as User Acceptance Testing (UAT).

Types of Acceptance Testing:

User Acceptance Testing (UAT) End users test in a real-world scenario to verify business processes
work. Most common type.

Alpha Testing Done by internal employees (not the dev team) at the developer's
site before external release.

Beta Testing Done by selected real customers in their own environments.

Issues reported back to developer.

Contract Acceptance Testing Software tested against criteria defined in a contract between client
and developer.

Regulation Acceptance Testing Tests compliance with laws, regulations, industry standards (e.g.,
HIPAA for healthcare).

Operational Acceptance Testing Tests operational readiness: backup/restore, disaster recovery,

maintenance tasks.

EXAMPLE ■ Alpha vs Beta Testing

ALPHA: A company's own HR department tests new payroll software before giving it to clients. BETA: 500
selected customers worldwide use the new banking app for 2 weeks and submit bug reports before it's
released to all 10 million users.

Quick Comparison – All Testing Levels

Level Tests Done By When Technique Tools

BCA 232 – Software Testing Notes | Page 15

Unit Single Developer During White Box JUnit, PyTest
function/method coding

Integration Module interactions Dev/Tester After unit Black & Selenium,

tests White Postman

System Complete system QA Team After Black Box JMeter, QTP

integration

Acceptanc Business Client/Users Before Black Box Manual, UAT tools

e requirements go-live

BCA 232 – Software Testing Notes | Page 16

 UNIT – IV
■ Test Planning & Test Management

■ 1. Test Planning

A Test Plan is a formal document that describes the scope, approach, resources and schedule of
intended testing activities. It is the master blueprint for the entire testing effort.

Test Planning Process

Scope Risk Test Resource Schedule & Sign

Definition Analysis Approach Planning Milestones Off

1 2 3 4 5 6

Fig 8: Test Planning Process Flow

Key Components of a Test Plan (IEEE 829 Standard):

1. Scope Management What is IN SCOPE for testing (features to test) and OUT OF SCOPE
(not tested, with reasons).

2. Test Approach / Strategy Techniques to be used: manual/automated, black/white box, tools to

be used.

3. Entry Criteria Conditions that MUST be met before testing can BEGIN. E.g., code
complete, environment ready.

4. Exit Criteria Conditions that MUST be met to STOP testing. E.g., 95% pass rate,
zero P1/P2 open bugs.

5. Identifying Responsibilities Who is responsible for test plan, test cases, execution, sign-off, defect
tracking.

6. Staffing & Training Number of testers needed, skill sets required, training to be arranged.

7. Resource Requirements Hardware, software, licenses, test data, environments, networking

needs.

8. Test Deliverables Documents produced: test plan, test cases, test scripts, defect reports,
summary report.

9. Testing Tasks & Schedule List of all tasks with start/end dates, dependencies, milestones.

BCA 232 – Software Testing Notes | Page 17

10. Risk & Contingency Identified risks (resource unavailability, environment issues) with
mitigation plans.

EXAMPLE ■ Entry & Exit Criteria – Practical Example

ENTRY: Code review complete | Unit test pass rate ≥ 90% | Test env configured | Test data loaded. EXIT: All
planned test cases executed | Pass rate ≥ 95% | Zero open Critical/High bugs | Test summary report approved
by test manager.

■■ 2. Test Management

Test Management encompasses all activities needed to organise, monitor and control the testing
process. It ensures that testing is executed effectively and efficiently within constraints.

A. Test Infrastructure Management

Hardware Servers, PCs, mobile devices, tablets, networking equipment — must
mirror production.

Software Required OS versions, browsers, databases, application servers, testing

tools.

Test Environments DEV (developer testing), SIT (system integration), UAT (acceptance),
STAGING (pre-prod).

Test Data Management Creating, managing and securing test data. Ensure data masks sensitive
production data.

Configuration Management Track versions of software, environments and test assets — ensure
everyone uses correct version.

B. Test People Management

Role Responsibilities Skills Needed

Test Manager Plans, estimates, monitors, controls testing. Leadership, planning,

Reports to project management. communication

Test Lead Coordinates test execution. Reviews test cases. Technical + organisational
Tracks defects. skills

Senior Test Designs test cases, reviews junior work, writes Domain + testing expertise
Engineer test scripts.

Test Engineer Executes test cases, reports defects, retests Attention to detail, tools
fixes.

Automation Writes and maintains automated test scripts. Programming, framework

Engineer knowledge

BCA 232 – Software Testing Notes | Page 18

 ■ 3. Test Process – Step by Step

1 Step 1: Baseline the Test Plan Finalise, review and formally approve the test plan. Place it
under configuration management so changes are tracked.

2 Step 2: Integrate with Product Coordinate test activities with development release schedule.
Release Ensure testers know what code is in each build.

3 Step 3: Test Case Specification Write detailed test cases for each requirement. Review for
completeness. Peer review by another tester.

4 Step 4: Update Requirements Map every test case to the requirement it covers. Ensure 100%
Traceability Matrix (RTM) requirement coverage. RTM format: REQ-ID → Test Case ID →
Status.

5 Step 5: Execute Tests & Track Run tests per schedule. Log actual results. Raise defects in
Defects defect tracking tool (Jira, Bugzilla, etc.). Classify severity
(Critical/High/Medium/Low) and priority.

6 Step 6: Test Reporting Prepare daily/weekly test progress reports. Report: planned vs
executed tests, pass/fail counts, defect open/closed/pending,
test coverage percentage.

7 Step 7: Recommend Product Based on exit criteria and test results, the Test Manager gives
Release GO/NO-GO recommendation. Document rationale. Final
decision with stakeholders.

■ 4. Defect / Bug Life Cycle

A defect goes through a defined life cycle from when it is first discovered to when it is finally closed.
Understanding this process is essential for test management.

Defect / Bug Life Cycle

New
Closed Assigned
Rejected
Retest Open
Fixed

Fig 9: Defect Life Cycle – States and Transitions

BCA 232 – Software Testing Notes | Page 19

New Tester logs a new defect. Assigned a unique ID, description, severity, priority.

Assigned Test manager or lead assigns it to a developer for investigation.

Open Developer starts working on fixing the defect.

Fixed Developer fixes the bug and marks it as Fixed. Code changes documented.

Retest Tester verifies the fix by running the original failing test case again.

Closed Fix verified — defect is closed. QA sign-off given.

Rejected Developer finds defect is not valid, duplicate, or not reproducible.

Deferred Valid but not fixed in this release — moved to next release backlog.

Defect Severity vs Priority:

Severity Impact of the defect on the system functionality. Set by the TESTER.

Priority Order in which defect should be fixed. Set by the BUSINESS/MANAGER.

High Severity, Low Priority Rare feature crashes but rarely used. E.g., admin-only report crash.

Low Severity, High Priority Spelling mistake in company logo on homepage — low impact, must fix
ASAP.

EXAMPLE ■ Defect Report Example

ID: BUG-0047 | Title: Login button inactive on iOS Safari | Severity: High | Priority: Critical | Steps: [Link] app
on iPhone [Link] creds [Link] Login → Button does nothing. Expected: User logs in. Actual: No response.
Environment: iOS 17 / Safari 17.

■■ 5. Requirements Traceability Matrix (RTM)

RTM is a document that maps and traces user requirements to test cases. It ensures every requirement
has at least one test case and every test case maps to a requirement. A key deliverable for quality audits.

Covera
Req ID Requirement Test Case IDs Status
ge

REQ-001 User Login TC-001, TC-002, TC-003 All Passed 100%

REQ-002 Password Reset TC-004, TC-005 TC-005 Failed 50%

REQ-003 User Logout TC-006 Passed 100%

REQ-004 Account Settings TC-007, TC-008 Not Executed 0%

BCA 232 – Software Testing Notes | Page 20

 ■ Quick Revision – Key Formulas & Facts

Topic What to Remember

Cyclomatic Complexity V(G) = E − N + 2 OR V(G) = Decision Points + 1

BVA Values For range [a,b]: test a−1, a, a+1, mid, b−1, b, b+1 (7 values)

Error Chain Human Error → Code Fault/Bug → System Failure → User Incident

7 Principles Defects exist | Not exhaustive | Early testing | Clustering | Pesticide |

Context | Absence fallacy

V-Model Pairs Requirements↔Acceptance | System Design↔System |

Architecture↔Integration | Module↔Unit

Testing Order Unit → Integration → System → Acceptance Testing

Alpha vs Beta Alpha = Internal employees at developer site | Beta = External selected
users at their site

Stub vs Driver Stub = dummy LOWER module (Top-Down) | Driver = dummy UPPER
module (Bottom-Up)

Entry/Exit Criteria Entry = when to START testing | Exit = when to STOP testing

Severity vs Priority Severity = impact on system (by Tester) | Priority = fix order (by Business)

RTM Purpose Maps Requirements ↔ Test Cases. Ensures 100% requirement coverage.

Static Testing No code execution. Inspection > Technical Review > Walkthrough > Desk
Check (formality order)

DD-Path Decision-to-Decision Path: maximal chain of statements with no branching

in between.

Data Flow Test def = variable defined | c-use = computation use | p-use = predicate use.
Cover all def-use pairs.

★ All the very best for your exam! Focus on examples, diagrams and comparison tables. — BCA 232 Software T

BCA 232 – Software Testing Notes | Page 21