SOFTWARE TESTING

IIT Kharagpur — Sampurna Detailed Notes (Hinglish)

Prof. Rajib Mall • Dept. of Computer Science • IIT Kharagpur

20 Lectures • 4 Weeks • Poora Syllabus

Hafte Lectures Topics

Week 1 L1–L5 Introduction, Error/Fault/Failure, Testing Levels, Basic Concepts, Unit Testing

Week 2 L6–L10 Black Box: EC Partitioning, BVT, Special Value, Decision Table, Pairwise, White
Box Intro

Week 3 L11–L15 MC/DC Testing, Path Testing, Cyclomatic Complexity, Dataflow, Mutation Testing

Week 4 L16–L20 Integration Testing, System Testing, Regression Testing, OOP Testing

Yeh notes sirf padh ke exam doge — professor ki zaroorat nahi! ■

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 1

 LECTURE 1 — Introduction to Software Testing

Sabse pehle samjhte hain ki software testing kyun zaroori hai. Jab bhi koi programmer code likhta hai,
galtiyan hoti hain — ye inevitable hai. Chahe naya programmer ho ya 20 saal ka experienced developer,
mistakes hoti hain. In mistakes ki wajah se program galat kaam karta hai. Testing ka kaam hai — in mistakes
ko release se pehle dhundh kar theek karna.

Real life example: Ariane 5 Rocket (2000) — launch ke sirf 37 seconds baad self-destruct ho gaya. Ek bug
ki wajah se. 64-bit processor pe overflow hua jo 32-bit machine ke purane code se aaya tha. Exception
handler disable tha. Total loss: $1 Billion se zyada!

■ DHYAN DO: Testing agar na ki jaaye toh companies ko crores-arabao ka nuksan ho sakta hai. Iska ek
real proof Ariane 5 hai.

1.1 Error, Fault aur Failure — Sabse Fundamental Concept

IEEE Standard 1044 (1993) mein yeh teeno synonyms the. Lekin 2010 revision mein inhe alag-alag define
kiya gaya — kyunki ek word se sab kuch express karna proper nahi tha:

PARIBHASHA — Error ya Mistake: Programmer ki galti — yeh human action hai. Jab programmer code
likhta hai aur kuch galat likhta hai, use error kehte hain. Example: 'result = i * j' likhna tha, galti se 'result = i
* 2' likh diya.

PARIBHASHA — Fault ya Bug ya Defect: Code mein actual problem — error ki wajah se code mein jo
galati aati hai. Yeh PRODUCT mein hoti hai, programmer ke dimaag mein nahi. Example: Code mein 'i * 2'
hai jo wrong answer deta hai jab j != 2 ho.

PARIBHASHA — Failure: Program ka runtime pe expected behavior se alag behavior dikhana. Jab fault
execute hota hai aur wrong output ya crash aata hai. Example: Program galat result print karta hai.

Chain yaad karo:

• Programmer galti karta hai → Error hoti hai

• Error ki wajah se code mein problem aati hai → Fault ban jaata hai
• Fault execute hota hai → Failure dikhti hai

■ NOTE: Yeh chain ZAROOR nahi hai! Har error fault nahi banati. Har fault failure nahi dikhata.

Important Example (Exact from Book):

Programmer ka irada tha: result = i * j

Galti se likha: result = i * 2 ← ERROR hua

Case 1: Agar j = 2 tha pehle se assigned

→ i * 2 = i * j (same answer!)
→ FAULT NAHI BANA — program sahi kaam karta hai

Case 2: Agar j = 5 tha

→ i * 2 ≠ i * 5 (galat answer!)
→ FAULT BAN GAYI → program run pe FAILURE dikhegi

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 2

 Term Synonyms Kahan Hoti Hai Example

Error Mistake Programmer ke mind mein, i*2 likhna jab i*j chahiye tha
during coding

Fault Bug, Defect Code mein (product mein) Code mein i*2 hai jo kabhi wrong dega

Failure Crash, Wrong Runtime pe visible hoti hai Program galat answer print karta hai
output

■ EXAM QUESTION: Error aur Fault mein kya fark hai? Kya har error se fault banti hai? Example
do.
■ ANSWER: Error = programmer ki galti (human action). Fault = code mein resulting defect (product
defect). Nahi — har error fault nahi banati. Example: Programmer 'i*j' ki jagah 'i*2' likhta hai (error).
Lekin agar j=2 tha already, toh program sahi hi kaam karta hai — fault nahi bana. Agar j=5 hota toh fault
ban jaata.

■ EXAM QUESTION: Failure kab hoti hai? Kya har fault se failure zaroor hoti hai?
■ ANSWER: Failure tab hoti hai jab fault wala code execute hota hai aur wrong behavior dikhta hai.
Nahi — har fault failure nahi dikhata. Agar test case woh faulty code path kabhi execute hi na kare,
failure kabhi nahi dikhegi. Ya fault itna minor ho ki output phir bhi acceptable lag raha ho.

1.2 Testing ke Facts — Important Numbers

Fact Detail

Experienced programmers mein bugs Average 50 bugs per 1000 lines of code — research se proven

After extensive testing Phir bhi ~1 bug per 1000 lines release time pe bachi rehti hai

Bug sources 60% from Specification + Design, 40% from Code

Testing effort Companies apna 50%+ effort sirf testing mein lagate hain

Testing time Effort 50% lekin time sirf 10% development cycle ka — high parallelism

Ariane 5 Loss $1 Billion+ — sirf ek bug ki wajah se

■ EXAM TIP: 50 bugs per 1000 LOC — yeh number exam mein aa sakta hai. Experienced programmers
bhi galtiyan karte hain — isliye testing hamesha zaroori hai.

1.3 Bug Remove Karne ke 4 Primary Techniques

Companies bugs remove karne ke liye 4 primary techniques use karti hain:

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 3

 Technique Kya Hota Hai Static ya Dynamic Stage

1. Review / Code, design ya specification Static (code execute Har stage — requirement, design,
Inspection manually read karke bugs dhundna. nahi hota) code
Team meeting mein hota hai.

2. Static Analysis Automated tools code run kiye bina Static Coding phase
analyse karte hain. Compiler
warnings bhi isi category mein hain.

3. Simulation Real hardware unavailable ho toh Dynamic (execute When real environment not
simulate karke test karte hain. hota hai) available

4. Testing Program actual mein chalate hain, Dynamic All phases

input dete hain, output check karte
hain.

■ NOTE: Sirf ek technique kaafi nahi — alag techniques alag types ke bugs pakdti hain. Isliye Pesticide Effect
samajhna zaroori hai (Lecture 3 mein).

1.4 Verification vs Validation — Dono Ka Fark

Yeh dono IIT mein bahut important hain. Simple tarike se yaad karo:

VERIFICATION — Building it RIGHT? VALIDATION — Building RIGHT THING?

Sawaal: Kya hum sahi tarike se bana rahe hain? Sawaal: Kya hum sahi cheez bana rahe hain?

Check karta hai: Code vs Design, Design vs Check karta hai: Final product vs SRS requirements
Specification
Kaun karta hai: Testers
Kaun karta hai: Developers
Kab: End mein — System Testing phase
Kab: Development lifecycle ke dauraan, har stage mein
Type: Only Dynamic (execute karke)
Type: Static + Dynamic dono
Example: System testing, acceptance testing
Example: Code review, unit testing, integration testing

■ EXAM TIP: TRICK: Verification = 'V for Validate process' (sahi process?). Validation = 'V for Value
delivery' (sahi product?). Unit Testing = VERIFICATION. System Testing = VALIDATION.

■ EXAM QUESTION: Verification aur Validation mein kya fark hai? Unit testing kaunsa hai?
■ ANSWER: Verification: 'Sahi bana rahe hain?' — code ko design ke against check karna. Developers
karte hain. Static+Dynamic. Validation: 'Sahi cheez banai?' — final product ko SRS requirements ke
against check karna. Testers karte hain. Only Dynamic. Unit Testing = VERIFICATION (code vs
detailed design check karna).

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 4

 LECTURE 2 — Levels of Testing

Testing sirf ek baar nahi hoti — software development ke alag-alag stages pe alag-alag levels ki testing hoti
hai. Yeh levels ek sequence mein follow hoti hain.

2.1 Testing ke 4 Levels — Sequence Mein

Level Kya Test Karte Hain Against What Kaun Karta V ya V?

Document Hai

1. Unit Testing Ek individual function ya Detailed Design Developer VERIFICATION

module akele — baaki sab Document
se independent

2. Integration Testing Multiple units ko combine High-Level Design Developer / VERIFICATION

karke — interface errors Tester
dhundna

3. System Testing Complete integrated system SRS Document Dedicated VALIDATION

— puri functionality + Tester
performance

4. Acceptance Complete system — Customer Customer VALIDATION

Testing customer ki actual Requirements Himself
requirements se match

■ DHYAN DO: Sequence ZAROOR follow karo: Unit → Integration → System → Acceptance. Yeh order
exam mein poochha jaata hai!

Kyun yeh sequence?

• Pehle chhote pieces test karo (units) — bugs early mein pakad lo
• Phir saath mein kaam karne wale pieces test karo (integration)
• Phir poora system test karo against requirements
• Finally customer check karta hai

Kyun Integration Testing separately zaroori hai?

Sochte hain: agar har unit individually sahi kaam kar raha hai, toh saath mein kyun nahi karenge? Kyunki
interface mein problems ho sakti hain:

• Function A integer expect karta tha, Function B ne float bheja → type mismatch
• Parameters galat order mein bheje gaye → (name, age) ki jagah (age, name)
• Shared global variable ek module ne change ki, doosre ko pata nahi → data inconsistency

2.2 System Testing ke 3 Types

Type Kahan Hota Hai Kaun Test Karta Hai Purpose

Alpha Testing Developer ki office/lab mein Developer team ke log Internal testing before release

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 5

 Type Kahan Hota Hai Kaun Test Karta Hai Purpose

Beta Testing Selected friendly customers Trusted external users Real-world testing with actual users
ke paas

Acceptance Testing Customer ki site pe Customer khud Final approval before

payment/deployment

■ EXAM TIP: Alpha = Developer site. Beta = Selected customers. Acceptance = Customer khud. Yeh
yaad karo sequence mein.

2.3 Testing in Software Development Life Cycle (SDLC)

■ Waterfall Model mein Testing

• Testing ek dedicated phase hai — coding ke baad
• Unit testing: Coding phase ke dauraan hoti hai
• Integration + System testing: Dedicated test phase mein
• Problem: Testers kya karte hain jab specification/design/coding ho rahi hai?
• Bugs late discover hote hain → expensive to fix

■ Iterative / Agile Model mein Testing

• Har iteration mein: Spec → Design → Code → TEST — sab kuch hota hai
• Testing poori development lifecycle mein continuously hoti hai
• Bugs jaldi pakde jaate hain — cheap to fix
• Regression testing automatically important ho jaati hai

2.4 Regression Testing — Ek Extra Level

PARIBHASHA — Regression Testing: Software change ya bug fix ke baad, previously working
functionality phir se test karna — ensure karna ki change ne koi existing feature break nahi kiya.

• Maintenance phase mein hoti hai — jab software release ho chuka ho

• Bug fix, enhancement ya requirement change ke baad
• Example: Feature A sahi thi. Bug fix kiya Feature B mein. Kya Feature A abhi bhi sahi hai?
• Regression bugs: Jo pehle work karta tha, change ke baad toot jaata hai

■ EXAM QUESTION: Testing ke 4 levels list karo. Integration testing unit testing se alag kyun karte
hain?
■ ANSWER: 4 levels: Unit Testing → Integration Testing → System Testing → Acceptance Testing.
Integration testing alag isliye: Units individually sahi ho sakti hain lekin interface errors tab bhi ho sakti
hain — wrong parameter types, wrong order, shared data issues. Unit testing sirf individual behavior
check karta hai, interface nahi.

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 6

 LECTURE 3 — Basic Concepts of Testing

3.1 Pesticide Effect — Bahut Important Concept

PARIBHASHA — Pesticide Effect: Ek hi testing technique baar baar use karne se surviving bugs uss
technique se immune ho jaate hain — aur naye bugs detect nahi hote. Analogy: Farmer ek hi pesticide
use karta rahe toh insects resistant ho jaate hain.

Analogy detail mein:

• Farmer = Software Company

• Insects/Bugs = Software Bugs
• Pesticide = Testing Technique
• Surviving insects = Bugs jo technique se nahi pakde
• Resistance = Woh bugs baar baar us technique se nahi pakde jaayenge

Capers Jones (IEEE Computer Magazine, 1996) ne kaha:

• Each bug removal step (review/testing) sirf ~30% bugs detect karta hai
• Matlab: 70% bugs escape karte hain har ek filter se!

Calculation (Exact from Book):

• Assume: 1000 bugs initially

• 4 different techniques use kari, har ek 70% effective (30% bugs survive)
Remaining Bugs = 1000 x (0.3)^4 = 1000 x 0.0081 = 81 bugs survive

■ NOTE: Agar har technique sirf 30% effective (Capers Jones ke anusaar) hoti: 1000 x (0.7)^4 = 1000 x 0.24 =
240 bugs survive hote. Isliye multiple diverse techniques use karna zaroori hai!

Solution kya hai Pesticide Effect ka?

• Different types of testing techniques use karo — variety maintain karo

• Black box, white box, review, simulation — sab alag-alag bugs pakdte hain
• Time ke saath test suite update karo

■ EXAM QUESTION: Pesticide Effect kya hai? Calculate karo: 500 bugs hain, 4 techniques use ki,
har ek 60% effective. Kitne bugs bachenge?
■ ANSWER: Pesticide Effect: Ek hi technique baar baar use karne se bugs us technique se resistant
ho jaate hain. Capers Jones: har step ~30% bugs pakdta hai. Calculation: 500 x (1-0.60)^4 = 500 x
(0.40)^4 = 500 x 0.0256 = 12.8 ≈ 13 bugs survive.

3.2 Coverage-Based vs Fault-Based Testing

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 7

 Coverage-Based Testing Fault-Based Testing
Kya karte hain: Program ke specific elements cover karo Kya karte hain: Specific types of bugs detect karne ki
koshish karo
Elements: Statements, conditions, branches, paths
Elements: Artificially inject faults, check if detected
Goal: Ensure ki program ka har part execute hua
Goal: Test suite quality measure karna
Metric: X% statement coverage, Y% branch coverage
Metric: Mutation score (% mutants killed)
Example techniques: Statement coverage, Branch
coverage, Path coverage, MC/DC Example techniques: Mutation Testing, Error Seeding

3.3 Test Case, Test Data, aur Test Suite

PARIBHASHA — Test Data: Sirf input values — jo program mein diya jaata hai. Example: x=5, y=10.

PARIBHASHA — Test Case: Ek triplet: (I, S, O) — Input data + System state at input + Expected output.
Sirf input nahi, poori context.

PARIBHASHA — Test Suite: Saare test cases ka collection — complete set of tests.

Test Case ka formal definition:

Test Case = (I, S, O) where:

I = Input / Test Data (kya denge program ko)

S = System State (program kis state mein hai jab input dete hain)

O = Expected Output (kya aana chahiye)

Real Example — Library Software, 'Return Book' test case:

State (S): Book 'CS101' member ID M123 ko issued hai

Member record exist karta hai
Input (I): Book ID = 'CS101', Member ID = 'M123'
Expected Output (O): 'Book returned successfully'
Issue record deleted
Book status = 'Available'

Positive Test Cases Negative Test Cases

Valid inputs dete hain Invalid/unexpected inputs dete hain

Check: Correct behavior for valid input Check: Graceful handling of bad input

Example: Valid book ID return karna Example: Already returned book ko return karna

Purpose: Happy path verify karna Purpose: Error handling verify karna

■ EXAM QUESTION: Test Case aur Test Data mein kya fark hai? Library software ke liye ek test
case likho.
■ ANSWER: Test Data = sirf input values. Test Case = triplet (I, S, O): input + state + expected output.
Library example — Issue Book: State=book available hai aur member valid hai, Input=book_id='CS101',
Expected Output='Book issued successfully', issue record created, book status='Issued'.

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 8

 LECTURE 4 — Basic Concepts of Testing (Continued)

4.1 Black Box, White Box, Grey Box Testing

Type Matlab Kya Hai Code Basis Kab Use Karte Hain
Dekhna?

Black Box Testing Sirf input-output behavior Nahi Specification / Functional testing, user
test karo — code ki koi Requirements perspective
knowledge nahi

White Box Testing Code structure examine Haan Source Code Code coverage, developer
karke test karo — internal testing
paths cover karo

Grey Box Testing Design dekhte hain (internal Partial Design Documents Integration testing, API testing
structure partially known)

Kyun dono (Black + White) zaroori hain?

• Black Box alone ki problem: Programmer ne kuch extra code likha jo specification mein nahi tha —
black box se woh code kabhi execute nahi hoga (unreachable code). Aur woh code malicious bhi ho
sakta hai!
• White Box alone ki problem: Specification mein kuch mention tha jo code mein implement hi nahi hua
— white box se yeh detect nahi hoga kyunki woh feature hi nahi hai code mein.
• Conclusion: DONO complementary hain — ek doosre ke gaps fill karte hain.

■ DHYAN DO: Exam trap: 'Kya white box testing ho toh black box ki zaroorat nahi?' — GALAT! Dono
zaroori hain aur alag-alag types ke bugs pakdte hain.

4.2 Error Seeding Technique

PARIBHASHA — Error Seeding: Ek technique jisme testing se pehle manager jaan-bujhkar code mein
known bugs (seeds) inject karta hai. Testing ke baad detected seeds ka ratio use karke estimated
remaining bugs calculate karte hain.

Step-by-step Process:

• Step 1: Testing shuru hone se pehle (usually system testing se pehle)

• Step 2: Manager S number of bugs seed karta hai code mein
• Step 3: Testers ko pata nahi kaunse bugs seeded hain — unbiased testing
• Step 4: Testing hoti hai — bugs detect hote jaate hain
• Step 5: s = seeded bugs detected, n = original bugs detected
• Step 6: Formula se N (total original bugs) estimate karo

Formula derive karna:

Assumption: Detection rate same hai for seeded aur original bugs

Iska matlab: s/S = n/N (ratio same hoga)

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 9

 n / N = s / S => N = (n x S) / s

Example:

• S = 100 bugs seeded

• s = 60 seeded bugs detected during testing
• n = 45 original bugs detected
N = (45 x 100) / 60 = 75 estimated original bugs

• Matlab: Testing ke baad bhi ~75 - 45 = 30 original bugs abhi bhi code mein hain

■ DHYAN DO: ASSUMPTION: Seeded bugs ka difficulty level SAME hona chahiye original bugs jaisa.
Too easy seeds → overestimate. Too hard seeds → underestimate. Yeh assumption exam mein poochhi
jaati hai!

■ EXAM QUESTION: Error seeding formula explain karo. 200 bugs seeded, 150 detect hue. 90
original bugs mili. Remaining bugs estimate karo.
■ ANSWER: Formula: N = (n x S) / s. n=90 original bugs found, S=200 seeded, s=150 seeded
detected. N = (90 x 200) / 150 = 120 estimated total original bugs. Remaining = 120 - 90 = 30 bugs still
in code.

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 10

 LECTURE 5 — Unit Testing

5.1 Unit Testing Kya Hai?

PARIBHASHA — Unit Testing: Ek individual software unit (function, module, class) ko poori tarah se
AKELE test karna — baaki units se independent. Objective: Har unit apne specification ke according kaam
kare.

Unit ki definition:

• Ek function ya method
• Ek module ya class
• Ek procedure
• Basically: sabse chhoti independently testable piece of software

Challenge kya hai akele test karne mein?

Ek unit doosri units ke saath interact karti hai — woh call karta hai aur woh bhi call hota hai doosron se. Agar
saari dependencies real hain toh isolated test nahi kar sakte. Solution: Driver aur Stub!

5.2 Driver aur Stub — Bilkul Clear Samjho

PARIBHASHA — Driver: Woh software jo TEST hone wali unit ko CALL karta hai aur use test data
supply karta hai. Actual caller ka simulator. Unit ke upar hota hai logically.

PARIBHASHA — Stub: Woh software jo un functions ko SIMULATE karta hai jo test unit CALL karti hai
lekin abhi ready/available nahi hain. Unit ke neeche hota hai logically.

Diagram (Text Format):

DRIVER
(Caller simulate karta hai)
|
| call karta hai
v
+--------------------+
| UNIT UNDER TEST | <-- yeh test ho raha hai
+--------------------+
|
| call karta hai
v
STUB
(Called function simulate karta hai)

Kab kya chahiye?

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 11

 Unit ki Position Driver Stub Chahiye? Reason
Chahiye?

Top-level unit (koi caller nahi) Haan — Driver Nahi Koi upar nahi jo ise call kare
banao

Bottom-level unit (koi called Haan — Driver Nahi Khud kisi ko call nahi karta
function nahi) banao

Middle-level unit Haan — Driver Haan — Stub Dono taraf se interact karta hai
banao banao

Completely isolated (pure Optional Nahi No external dependencies

function)

Detailed Example (Book se):

Test karna hai: calculate_fine(book_id, return_date) function

Function calculate_fine(book_id, return_date):
issue_date = get_issue_date(book_id) <-- yeh call karta hai
fine = compute_days(issue_date, return_date) * rate
return fine

get_issue_date() abhi ready nahi hai → STUB banao:

Stub: if book_id='CS101' return '2024-01-01'
if book_id='CS202' return '2024-02-15'

main() abhi ready nahi hai → DRIVER banao:

Driver: call calculate_fine('CS101', '2024-01-15')
check ki result = 140 (14 days * 10 per day)

■ EXAM TIP: Driver = Caller simulate karna (Unit ke UPAR se call karta hai). Stub = Called function
simulate karna (Unit ke NEECHE wala function). Bottom-Up testing mein Drivers chahiye. Top-Down
mein Stubs.

■ EXAM QUESTION: Driver aur Stub mein kya fark hai? Ek middle-level function ke liye kya
chahiye?
■ ANSWER: Driver = caller unit ka simulator — unit ko call karta hai aur test data deta hai. Stub =
called function ka simulator — canned responses return karta hai. Middle-level function ke liye DONO
chahiye: driver (upar se call karne ke liye) aur stub (neeche ke functions simulate karne ke liye).

5.3 Unit Testing Activity kya hai?

• Unit Testing = VERIFICATION activity (not validation)
• Code ko Detailed Design ke against check karta hai
• Kya code design ke anusaar likha gaya hai?
• NOT checking against SRS — woh system testing mein hoga

Unit Test Case Design Approaches:

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 12

 Approach Basis Kya Karte Hain

Black Box Specification / detailed Input-output behavior ke anusaar test cases design karo
design

White Box Source code Code paths, branches, conditions cover karo

Grey Box Design documents (partial Design se test cases, code dekhe bina
internal knowledge)

■ EXAM QUESTION: Unit testing verification hai ya validation? Kyun?

■ ANSWER: Verification — kyunki unit testing mein code ko DETAILED DESIGN ke against check
karte hain ('are we building it right?'). Validation mein final product ko SRS ke against check karte hain.
System testing validation hai. Unit testing design conformance check hai.

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 13

 LECTURE 6 — Equivalence Class Partitioning & Boundary Value Testing

Black Box testing mein input domain ko systematically partition karte hain. Do most important techniques:
Equivalence Class Partitioning (ECP) aur Boundary Value Testing (BVT).

6.1 Equivalence Class Partitioning (ECP)

PARIBHASHA — Equivalence Class: Input domain ka ek partition/group jisme saare values similarly
behave karein — same output type milega. Ek class ka ek value test karna = poori class test karna. Isse
test cases drastically kam ho jaate hain.

Motivation — Kyun ECP?

• Ek function 1 se 1000 tak integers accept karta hai — kya 1000 test cases likhein?
• Nahi! Sab values ek jaisa behave karti hain → sirf EK test case kaafi hai
• Similarly invalid values (0, -1, 1001) bhi ek jaisi fail hongi → EK invalid test case

RULES — Equivalence Classes Kaise Identify Karein:

Input Condition Type Valid Equivalence Invalid Equivalence Example

Classes Classes

Range a to b 1 valid: a <= x <= b 2 invalid: x < a aur x > Age range 1-100: valid={50}, invalid={-5,
b 150}

Specific single value 1 valid: x = that value 1 invalid: x != value Pin='1234': valid={'1234'}, invalid={'9999'}

Member of set {a,b,c} 1 valid: x ∈ {a,b,c} 1 invalid: x ∉ {a,b,c} Day ∈ {Mon,Tue}: valid={Mon}, invalid={Xyz}

Boolean condition 1 valid: condition true 1 invalid: condition hasPassword: valid={yes}, invalid={no}
false

Enumerated type 1 valid per valid value 1 invalid Status ∈ {A,B,C}: valid ECs for A,B,C
separately

Types of ECP Testing:

Type Rule Test Cases Kitne Kab Use

Weak EC Testing Ek test case mein har EC se ek max(valid ECs, Quick basic testing
value lo (min combinations) invalid ECs)

Strong EC Testing Saare ECs ka Cartesian product — Product of all EC Thorough testing with
har combination counts interactions

Weak Robust Testing Weak + invalid ECs bhi include karo Moderate count When error handling important

Strong Robust Testing Strong + saare invalid ECs ka Maximum — most Safety-critical systems
combination exhaustive

■ Detailed Example 1 — Simple Range Function

Function: check_even_odd(x) — x should be between 1 and 5000

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 14

 • Valid EC1: 1 <= x <= 5000, even number → test value: 2500
• Valid EC2: 1 <= x <= 5000, odd number → test value: 2501
• Invalid EC1: x < 1 → test value: 0
• Invalid EC2: x > 5000 → test value: 5001
• Weak EC test cases: {2500, 0} or {2501, 5001} — max(2 valid, 2 invalid) = 2 test cases
• Strong EC test cases: 2 x 2 = 4 test cases (all combinations)

■ Detailed Example 2 — Issue Book Function

Function: issue_book(book_id) — Library mein book issue karna

Scenarios identify karne ke liye OUTPUT dekho — different outputs = different ECs:

• Valid EC1: Single-volume book jo issued ho sakti hai

• Valid EC2: Multi-volume book jo issued ho sakti hai
• Invalid EC: Reference book — issue nahi ho sakti
• Test cases: Ek single-volume book ID, ek multi-volume book ID, ek reference book ID

■ EXAM TIP: ECs identify karne ka shortcut: Different OUTPUT scenarios dekho — jo alag output deta
hai woh alag EC hai! Input domain se zyada output behavior pe focus karo.

■ Detailed Example 3 — Multiple Parameters

Function: register_student(age, education_level)

Age ECs: EC1 = 5 to 30, EC2 = above 30, EC_inv = below 5

Education ECs: EC_school = School, EC_ug = UG, EC_pg = PG, EC_inv = None

• Weak EC: max(2 age ECs, 3 edu ECs) = 3 test cases: (15,School), (35,UG), (25,PG)
• Strong EC: 2 x 3 = 6 test cases — all combinations: (15,School), (15,UG), (15,PG), (35,School),
(35,UG), (35,PG)

■ EXAM QUESTION: Function ek phone number accept karta hai: area code (200-999) aur 7-digit
number. Equivalence Classes design karo.
■ ANSWER: Area code ECs: Valid={200-999}, Invalid1={<200}, Invalid2={>999},
Invalid3={non-numeric}. Number ECs: Valid={7-digit number}, Invalid1={<7 digits}, Invalid2={>7 digits},
Invalid3={non-numeric}. Weak EC test cases: valid combo (e.g., 555-1234567), each invalid type = ~6
test cases total.

6.2 Boundary Value Testing (BVT)

PARIBHASHA — Boundary Value Testing: Equivalence class boundaries pe specifically test karna.
Research: Programmers sabse zyada mistakes boundaries pe karte hain (off-by-one errors, wrong
relational operators). Isliye boundaries special attention deserve karte hain.

Kyun programmers boundaries pe galtiyan karte hain?

• Programmer likhna chahta tha: if (age <= 18) — galti se likha: if (age < 18)

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 15

 • Value 18 pe: pehle = valid, doosre mein = invalid → boundary bug!
• Yeh off-by-one error bahut common hai — < vs <= confusion

Standard BVT Test Values for range [a, b]:

Test Values: a-1, a, a+1, (a+b)/2, b-1, b, b+1

• a-1: Just below lower boundary (should be INVALID)
• a: Lower boundary (should be VALID)
• a+1: Just above lower (should be VALID)
• (a+b)/2: Nominal/middle value (should be VALID)
• b-1: Just below upper (should be VALID)
• b: Upper boundary (should be VALID)
• b+1: Just above upper (should be INVALID)

Example — Age range [1, 100]:

Test Value Expected Result Purpose

0 Invalid / Error Just below lower boundary — boundary bug check

1 Valid Lower boundary — exactly on limit

2 Valid Just above lower — normal valid

50 Valid Nominal/typical value

99 Valid Just below upper

100 Valid Upper boundary — exactly on limit

101 Invalid / Error Just above upper boundary

■ DHYAN DO: TOTAL 7 TEST VALUES for any range! Exam mein agar range di ho, directly yeh 7 values
likho: min-1, min, min+1, mid, max-1, max, max+1.

■ EXAM QUESTION: Function accepts salary in range [10000, 100000]. BVT test values list karo.
■ ANSWER: 7 values: 9999 (just below min-invalid), 10000 (lower boundary-valid), 10001 (just above
min-valid), 55000 (nominal-valid), 99999 (just below max-valid), 100000 (upper boundary-valid),
100001 (just above max-invalid).

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 16

 LECTURE 7 — Special Value Testing

PARIBHASHA — Special Value Testing: Experienced tester ki intuition aur knowledge se specific values
choose karna jo bugs reveal karne ke zyada chances rakhti hain. Yeh subjective technique hai — no
systematic rules.

Boundary Values — General Special Values (sab programs ke liye applicable):

• Ye values kisi bhi program mein bugs reveal kar sakti hain
• Boundary values (BVT se same) — <=, <, >=, > confusion ke liye

Domain-Specific Special Values:

Value Type Kab Use Karein Example

Zero (0) Division ya multiplication Division by zero, 0*x=0 always

operations mein

Null / Empty String ya collection inputs mein Empty string, null pointer

Negative values Jab positive expected ho Age = -5, length = -1

Maximum value Integer overflow check INT_MAX + 1 = overflow

Default values Uninitialized variables Default=0 ya garbage

Leap year dates Date calculation programs mein Feb 29 — leap year handling

Special characters String processing mein !, @, #, <, > in names

Example — Calendar Function:

• Function: get_day(date) — date se weekday batao

• Special value: February 29 — kyunki leap year handling common bug hai
• Special value: December 31 / January 1 — year boundary
• Special value: Last day of month — 28,29,30,31 days wale months

■ EXAM TIP: Special value testing ko boundary value testing ke saath combine karo — dono
complementary hain. BVT systematic hai, Special value testing intuitive hai.

■ EXAM QUESTION: Special Value Testing kya hai? Date function ke liye kaunse special values
use karoge?
■ ANSWER: Special value testing: Tester ke experience se specific values choose karna jo bugs
expose karein. Date function ke liye: Feb 29 (leap year), Dec 31 (year boundary), Feb 28 (non-leap
year last day), Jan 1, 12 noon vs midnight, timezone boundaries. Yeh values common date bugs
expose karti hain.

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 17

 LECTURE 8 — Combinatorial Testing — Decision Table & Cause-Effect Graphing

Jab ek unit ke multiple parameters hain aur unke combinations pe behavior depend karta hai, tab
Combinatorial Testing use karte hain.

8.1 Decision Table Based Testing

PARIBHASHA — Decision Table: Complex business logic ko conditions aur actions ke tabular form mein
represent karna. Har column ek rule/test case hai. Systematic aur complete coverage ensure karta hai.

Structure of Decision Table:

• TOP HALF: Conditions — input conditions (True/False ya multiple values)

• BOTTOM HALF: Actions — kya karna chahiye us condition combination ke liye
• COLUMN: Rule — ek specific combination of conditions → ek set of actions
• n boolean conditions → 2^n rules/columns

Detailed Example — Library Book Issue:

Conditions: C1=Book Available, C2=Member Valid, C3=Borrowing Limit Not Exceeded

Conditions / Actions R1 R2 R3 R4 R5 R6 R7 R8

C1: Book Available? T T T T F F F F

C2: Member Valid? T T F F T T F F

C3: Limit Not Exceeded? T F T F T F T F

A1: Issue Book Y N N N N N N N

A2: Show Error N Y Y Y Y Y Y Y

• R1: Sab T → Issue karo (only case where book issues)

• R2: Available T, Valid T, Limit F → Error (limit exceed ho gayi)
• R3 se R8: Kisi bhi condition false → Error

Test Cases directly milte hain:

• TC1: Available=T, Valid=T, Limit=T → Expected: Issue book

• TC2: Available=T, Valid=T, Limit=F → Expected: Error
• TC3: Available=T, Valid=F → Expected: Error (member invalid)
• ... etc.

Table Simplification — Don't Care (-)

Agar ek condition ka value kuch bhi ho aur action same ho, toh '-' (Don't Care) likh sakte hain:

• R5 se R8 mein: C1=F → Book available nahi, baaki conditions matter hi nahi

• Simplify: R5-R8 ko ek rule banao: C1=F → Always Error

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 18

 ■ EXAM QUESTION: 3 boolean conditions ke liye maximum kitne rules hote hain decision table
mein? Table simplification kab hoti hai?
■ ANSWER: 3 boolean conditions → 2^3 = 8 rules maximum. Simplification: Agar kisi rule mein ek
condition ka value matter nahi karta (output same rehta hai regardless of that condition's value), tab
Don't Care (-) use karte hain aur rules merge kar sakte hain.

8.2 Cause-Effect Graphing

PARIBHASHA — Cause-Effect Graph: Inputs (causes) aur outputs (effects) ke beech logical
relationships ka graphical representation. Is graph se decision table automatically generate ki ja sakti hai.

Components:

• Causes = Input conditions (graph ke left side)

• Effects = Output actions (graph ke right side)
• Relations: AND (∧), OR (∨), NOT (¬), NAND, NOR

Constraints:

Constraint Symbol Matlab

Exclusive (E) E between At most one can be true at a time

causes

Inclusive (I) I between causes At least one must be true

One and Only One (O) O between Exactly one must be true
causes

Requires (R) R between If cause1 true then cause2 must be true

cause1 and
cause2

Masks (M) M between If effect1 true then effect2 is undefined

effect1 and
effect2

Steps to use Cause-Effect Graphing:

• Step 1: Specification se causes (inputs) identify karo

• Step 2: Effects (outputs/actions) identify karo
• Step 3: Graph draw karo — causes ko effects se connect karo logical operators se
• Step 4: Constraints add karo
• Step 5: Graph se decision table generate karo
• Step 6: Har rule ek test case banta hai

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 19

 LECTURE 9 — Pairwise / All-Pairs Testing

9.1 Motivation — Problem Kya Hai?

Jab parameters zyada hote hain, all combinations test karna impractical ho jaata hai:

Font Settings Example (MS Word style):

- Strike-through: ON/OFF (2 values)
- Superscript: ON/OFF (2 values)
- Subscript: ON/OFF (2 values)
- Bold: ON/OFF (2 values)
- Italic: ON/OFF (2 values)
- Font type: 10 choices
- Font size: 30 choices
- Color: 16 choices

Total combinations = 2^5 x 10 x 30 x 16 = 32 x 4800 = 153,600 test cases!

Practically IMPOSSIBLE to test all!

Key Research Finding:

• Studies show: 67-90% of all software bugs are caused by interaction of just 1 or 2 parameters
• Only a small % of bugs need 3+ parameter interaction to trigger
• Conclusion: If we cover all 2-parameter combinations, we catch most bugs!

9.2 Pairwise Testing — What is it?

PARIBHASHA — Pairwise / All-Pairs Testing: Ek combinatorial testing technique jisme ensure karte
hain ki har 2 parameters ki har possible value combination kam se kam ek test case mein cover ho. 1-2
parameter interactions se hone wale maximum bugs cover karta hai.

Pairwise Goal: Every pair of parameters (Pi, Pj) ke liye every

combination (Vi, Vj) cover karo

Example — 3 Parameters:

P1: Browser = {Chrome(C), Firefox(F), IE(I)} — 3 values

P2: OS = {Windows(W), Mac(M), Linux(L)} — 3 values
P3: Language = {English(E), Hindi(H)} — 2 values

All combinations: 3 x 3 x 2 = 18 test cases

Pairwise requires covering all pairs:

P1-P2 pairs: (C,W),(C,M),(C,L),(F,W),(F,M),(F,L),(I,W),(I,M),(I,L) = 9
P1-P3 pairs: (C,E),(C,H),(F,E),(F,H),(I,E),(I,H) = 6
P2-P3 pairs: (W,E),(W,H),(M,E),(M,H),(L,E),(L,H) = 6

Pairwise Solution (6 test cases cover all pairs!):

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 20

 TC Browser OS Language Pairs Covered

1 Chrome Windows English C-W, C-E, W-E

2 Chrome Mac Hindi C-M, C-H, M-H

3 Firefox Windows Hindi F-W, F-H, W-H

4 Firefox Linux English F-L, F-E, L-E

5 IE Mac English I-M, I-E, M-E

6 IE Linux Hindi I-L, I-H, L-H

• 18 test cases ki jagah sirf 6 test cases se same coverage!

• 67% reduction in test cases

Tools:

• PICT (Pairwise Independent Combinatorial Testing) — Microsoft ka free tool

• AETG (Automatic Efficient Test Generator) — algorithm
• Input: Parameters aur unki values. Output: Optimal pairwise test set

T-Way Testing — Generalization:

• Pairwise = 2-way testing (t=2)

• 3-way: Har 3 parameters ka combination cover karo
• Higher t → more thorough → more test cases
• Practical choice: t=2 or t=3 for most systems

■ EXAM QUESTION: Pairwise testing kab use karte hain? All combinations se kaise different hai?
■ ANSWER: Pairwise testing jab parameters zyada hon (5+) aur all combinations impractical hon. All
combinations: product of all parameter values. Pairwise: cover all 2-parameter combinations only.
Research: 67-90% bugs 1-2 parameter interactions se — pairwise yahi cover karta hai. Typically
O(sqrt(all_combinations)) test cases kaafi hain.

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 21

 LECTURE 10 — White Box Testing — Statement & Branch Coverage

10.1 White Box Testing Overview

PARIBHASHA — White Box Testing: Code ka structure examine karke test cases design karna. Internal
implementation visible hai. Structural testing bhi kehte hain. Coverage-based ya fault-based ho sakta hai.

Black Box Testing White Box Testing

Code nahi dekhna Code examine karte hain

Specification based Structure/implementation based

User perspective Developer perspective

Missing features pakdta hai Dead code, unreachable paths pakdta hai

EC, BVT, Pairwise, Decision Table Statement, Branch, Path, MC/DC, Mutation

■ DHYAN DO: DONO ZAROOR HAIN! Black Box se dead code nahi pakdega. White Box se specification
mein missing feature nahi pakdega. Dono complementary hain.

White Box Testing Categories:

Category Types Goal

Coverage-Based Statement, Branch, Condition, Path Program elements (statements/branches/paths)

coverage execute karo

Fault-Based Mutation Testing, Error Seeding Specific types of bugs detect karna check karo

10.2 Statement Coverage — Sabse Basic

PARIBHASHA — Statement Coverage: Program ki har executable statement kam se kam ek baar
execute ho. Sabse weak coverage criterion. 100% statement coverage ka matlab nahi ki program bug-free
hai!

Statement Coverage = (No. of Executed Statements / Total Statements) x

100%

Example:

1: def calculate(x):
2: if x > 0:
3: y = 1 # Statement 3
4: else:
5: y = -1 # Statement 5
6: z = x + y # Statement 6
7: return z # Statement 7

Test Case 1: x = 5

• Executes: Statement 1, 2 (if), 3 (y=1), 6 (z=x+y), 7 (return)

• Misses: Statement 5 (else branch)

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 22

 • Statement coverage: 4/5 = 80%

For 100% Statement Coverage, need 2 test cases:

• TC1: x = 5 → executes if branch (statements 3, 6, 7)

• TC2: x = -3 → executes else branch (statements 5, 6, 7)

WEAKNESS of Statement Coverage:

• 100% statement coverage mil jaati hai lekin branches miss ho sakti hain
• Example: Boolean condition mein sirf TRUE case test ho, FALSE miss
• Bugs hidden in uncovered branches nahi pakdenge

10.3 Branch / Decision Coverage

PARIBHASHA — Branch Coverage (= Decision Coverage): Har decision expression (if, while, for,
switch) ke TRUE aur FALSE dono outcomes kam se kam ek baar execute hon. Statement coverage se
stronger.

Branch Coverage = (No. of Executed Branches / Total Branches) x 100%

Same example — Branch Coverage ke liye:

• if (x > 0) mein 2 branches: TRUE (x>0) aur FALSE (x<=0)

• TC1: x=5 → TRUE branch (y=1) ✓
• TC2: x=-3 → FALSE branch (y=-1) ✓
• Branch coverage = 4/4 = 100%

Subsumption Relationship:

• Branch coverage SUBSUMES statement coverage

• Agar 100% branch coverage achieve ho gayi → automatically 100% statement coverage bhi
• REVERSE true nahi: Statement coverage does NOT imply branch coverage

■ NOTE: Statement coverage karna ek 'weak' guarantee hai. Production code mein minimum branch/decision
coverage target karo.

■ EXAM QUESTION: Statement aur Branch coverage mein kya fark hai? Ek example do jahan
statement 100% ho lekin branch nahi.
■ ANSWER: Statement: har statement execute ho. Branch: har decision ka T aur F both execute ho.
Example: if(x>0): y=1; z=x+y; — x=5 se y=1 aur z=x+y execute hote hain — 100% statement coverage
(else nahi hai!). Lekin branch coverage incomplete — else ki koi default branch nahi hai... if else tha toh
FALSE branch miss. Statement 100% lekin branch less if only TRUE tested.

10.4 Condition Coverage — Multiple Types

Decision mein multiple atomic conditions ho sakti hain: if (A AND B AND C). Condition coverage inhe
individually test karta hai.

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 23

 All condition coverage types:

Type Requirement TC Count (n Subsumes

conditions)

Basic Condition Har atomic condition T aur F Minimum 2 KUCH NAHI (decision se bhi weak!)
Coverage dono values le

Decision Coverage Poora decision expression T Minimum 2 Statement Coverage

(=Branch) aur F ho

Basic Cond + Decision Basic condition aur decision Min 2-4 Statement + Branch
(BCD) dono achieve ho

Multiple Condition n conditions ki saari 2^n 2^n BC + Decision + BCD

Coverage (MCC) combinations test karo

MC/DC Har condition independently n+1 BC + Decision

decision ko affect kare

Path Coverage Saare linearly independent V(G) paths Sab ke upar — strongest
paths execute hon

■ DHYAN DO: TRAP QUESTION: Basic Condition Coverage does NOT subsume Decision Coverage!
Yeh exam mein baar baar poochha jaata hai. Basic condition coverage WEAKER hai decision coverage
se!

Proof — Basic Condition DOESN'T subsume Decision:

Decision: if (A AND B)

Test Case 1: A=True, B=False → Decision = False

Test Case 2: A=False, B=True → Decision = False

Basic Condition achieved? YES!

A takes True (TC1) and False (TC2) ✓
B takes False (TC1) and True (TC2) ✓

Decision Coverage achieved? NO!

Decision = False in BOTH test cases!
True branch of decision never executed ✗

■ EXAM QUESTION: Basic Condition Coverage aur Decision Coverage mein kya fark hai? Kyun
basic condition decision ko subsume nahi karta?
■ ANSWER: Decision Coverage: whole expression T aur F both ho. Basic Condition: har individual
condition T aur F ho. Basic condition doesn't subsume decision: Counter-example: if(A AND B) with
TC1=(T,F) and TC2=(F,T) — basic condition satisfied (both A,B take T and F) but decision ALWAYS
FALSE in both cases — decision coverage not achieved. This is why basic condition is actually weaker
than decision coverage!

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 24

 LECTURE 11-12 — MC/DC Testing (Modified Condition/Decision Coverage)

11.1 Kyun MC/DC? — Problem Statement

Hum dekh chuke hain ki:

• Multiple Condition Coverage (MCC) = 2^n test cases → n=10 ke liye 1024! Impractical
• Basic Condition Coverage = Too weak — decision coverage guarantee nahi
• Kya ek aise criterion hai jo thorough bhi ho aur practical bhi?

Answer: MC/DC!

• MC/DC = n+1 test cases (n = number of atomic conditions)

• Much more thorough than basic condition coverage
• Much more practical than multiple condition coverage
• Required by FAA (Federal Aviation Administration) for avionics software

■ DHYAN DO: MC/DC ka FAA mandate exam mein zaroor poochha jaata hai! Aviation safety-critical
software ke liye mandatory hai (DO-178B standard).

11.2 MC/DC ke 4 Requirements — Ek-Ek Samjho

Requirement 1: Entry/Exit Coverage

• Har function ka entry point aur exit point invoke ho

• Basically: function zaroor call ho

Requirement 2: Condition Coverage

• Har atomic condition (individual boolean sub-expression) T aur F dono values le

• Same as basic condition coverage

Requirement 3: Decision Coverage

• Har decision (whole compound expression) T aur F dono ho

• Same as branch/decision coverage

Requirement 4: Independence Condition ← THE KEY!

PARIBHASHA — Independence Condition: Condition C is INDEPENDENT if there exist 2 test cases

where: (1) ONLY C's value changes (all other conditions same), AND (2) the DECISION OUTCOME also
changes. Yeh pair 'C ka independence pair' kehlaata hai.

■ EXAM TIP: Yaad karo: 'Only one condition changes, and the decision also flips.' Yeh demonstration
karta hai ki woh condition ACTUALLY matter karti hai.

11.3 MC/DC Test Case Design — Step by Step

■ Example 1: Decision = A AND B

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 25

 n = 2 conditions → n+1 = 3 test cases needed

TC A B A AND B (Decision) Purpose / Note

TC1 T T T Base case — decision is TRUE

TC2 F T F A's independence: ONLY A changed (T→F), decision changed (T→F).

TC1+TC2 = A's independence pair ✓

TC3 T F F B's independence: ONLY B changed (T→F), decision changed (T→F).

TC1+TC3 = B's independence pair ✓

• A's independence: TC1(T,T)=T vs TC2(F,T)=F → Only A changed, decision changed ✓

• B's independence: TC1(T,T)=T vs TC3(T,F)=F → Only B changed, decision changed ✓
• Decision coverage: TC1=T, TC2=F (or TC3=F) ✓
• Basic condition: A=T(TC1),F(TC2); B=T(TC1),F(TC3) ✓

■ Example 2: Decision = A OR B
n = 2 conditions → n+1 = 3 test cases

TC A B A OR B Purpose

TC1 F F F Base case — decision FALSE

TC2 T F T A independent: only A changed (F→T), decision flipped (F→T). TC1+TC2 = A's pair
✓

TC3 F T T B independent: only B changed (F→T), decision flipped (F→T). TC1+TC3 = B's pair
✓

■ Example 3: Decision = A OR (B AND C) — 3 Conditions

n = 3 conditions → n+1 = 4 test cases

TC A B C B AND C A OR (B AND C) Independence Pairs

1 T F F F T A's pair base (A=T, decision=T)

2 F F F F F A's pair: TC1 vs TC2 — only A changed, decision

changed ✓

3 F T T T T B's pair base (B=T, C=T, decision=T)

4 F F T F F B's pair: TC3 vs TC4 — only B changed, decision

changed ✓

■ NOTE: C ki independence: TC3(F,T,T)=T vs TC5(F,T,F)=F — only C changes. Toh 5th test case add karna
hoga ya existing TCs mein se C ka pair mile toh theek hai. Complete MC/DC sometimes n+1 se thoda zyada ho
sakta hai depending on expression.

11.4 Short-Circuit Evaluation — Important Nuance

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 26

 PARIBHASHA — Short-Circuit Evaluation: Compiler/runtime A AND B evaluate karte waqt agar
A=False ho toh B evaluate hi nahi karta (already False). A OR B mein agar A=True ho toh B skip. Yeh
MC/DC test case design ko affect karta hai.

Example with short-circuit:

if (ptr != NULL AND [Link] > 0):

Short circuit: agar ptr == NULL toh [Link] check hi nahi hota
(Warna NullPointerException aata!)

MC/DC ke liye: [Link] > 0 ki independence test tab karo

jab ptr != NULL ho (otherwise [Link] evaluated hi nahi hoga)

■ EXAM TIP: Short-circuit evaluation ke saath MC/DC: Sirf un cases mein condition test karo jab woh
actually evaluated hoti ho. Isse test cases reduce bhi ho sakte hain.

■ EXAM QUESTION: MC/DC kya hai? A AND (B OR C) ke liye MC/DC test cases design karo.
■ ANSWER: MC/DC: har condition independently decision affect kare. n+1 test cases for n conditions.
A AND (B OR C): n=3, need 4 test cases. TC1=(T,T,F)→T [base], TC2=(F,T,F)→F [A independent: only
A changes, decision changes], TC3=(T,F,F)→F [B independent: only B changes, decision changes],
TC4=(T,T,T)→T [C independent with TC3: only C changes T→F gives TC3, F→T gives TC4... verify:
TC4(T,T,T)=T vs hypothetical where only C changes to F: (T,T,F)=T — hmm, same. Need another pair
for C... (T,F,T)→T vs (T,F,F)→F — C changes, decision changes. So that's C's pair].

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 27

 LECTURE 13 — Path Testing aur Cyclomatic Complexity

13.1 Control Flow Graph (CFG) Kya Hai?

PARIBHASHA — Control Flow Graph (CFG): Program ka directed graph representation. Nodes = basic
blocks (ek ya zyada sequential statements). Edges = possible control transfer. CFG se execution paths
visible hote hain.

CFG Drawing Rules — Statement-Type wise:

Statement Type CFG Pattern Special Notes

Sequence (a=1; b=2; Node1 → Node2 → Node3 (Linear No branching, straight arrow
c=3;) chain)

if-else (if(x>0) y=1; else Condition node → 2 paths → merge 2 outgoing edges: TRUE and FALSE
y=-1;) node

if (no else) (if(x>0) y=1;) Condition node → body → next OR FALSE path skips body
skip body directly

while loop (while(cond) Cond node → body → back edge to Back edge creates cycle
body;) cond OR exit edge

do-while (do body Body → cond node → back to body Body executes at least once
while(cond);) OR exit

for loop Init → cond check → body → Same as while after unrolling
update → back to cond

switch (n cases) n outgoing edges from switch node One edge per case

Complete Example — Puri tarah se draw karo:

1: def calculate(x, y):

2: z = 0
3: if x > 0:
4: z = x + y
5: while z < 10:
6: z = z + 1
7: return z

CFG (text representation):

[1: Start / 2: z=0]

|
[3: if x>0?]
T / \ F
[4: z=x+y] |
\ /
+--------+
|
[5: while z<10?] <----+
T / \ F |
[6: z=z+1] | |

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 28

 | | |
+------------+--------+
|
[7: return z]

Analysis:

• Nodes (N): [1-2], [3], [4], [5], [6], [7] = 6 nodes

• Edges (E): 1→3, 3→4(T), 3→5(F), 4→5, 5→6(T), 5→7(F), 6→5(back) = 7 edges
• Decision nodes: [3: if x>0] aur [5: while z<10] = 2 decision nodes

13.2 Cyclomatic Complexity V(G) — Sabse Important Formula

PARIBHASHA — Cyclomatic Complexity V(G): Program mein linearly independent paths ki minimum
count. Program ki testing complexity ka quantitative measure. = Minimum test cases needed for path
coverage.

TEEN Equivalent Formulas — sab same answer dete hain:

Formula 1: V(G) = E - N + 2 (E=edges, N=nodes)

Formula 2: V(G) = Number of Decision Nodes + 1

Formula 3: V(G) = Number of enclosed Regions in planar CFG + 1

Kaunsa use karein?

• Formula 2 (Decision nodes + 1) → SABSE FAST — sirf count karo if/while/for/switch

• Formula 1 → agar CFG diagram diya ho with nodes/edges counted
• Formula 3 → agar diagram draw ki ho, regions count karo (including outer region)

Decision nodes kya hain?

• if statement (ek decision node)

• else-if (ek additional decision node)
• while loop (ek decision node)
• for loop (ek decision node)
• do-while (ek decision node)
• switch/case (ek decision node for the switch)
• Ternary operator ?: (ek decision node)

Above example ki V(G):

• Decision nodes: if(x>0) = 1, while(z<10) = 1, Total = 2

V(G) = 2 + 1 = 3
• Ya: E-N+2 = 7-6+2 = 3 ✓

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 29

 V(G) Value Complexity Testing Difficulty Risk Level

1 No branches — pure Very easy Minimal

sequential

2-5 Simple, few branches Easy Low

6-10 Moderate complexity Manageable Moderate

11-25 High complexity, many Difficult High — review recommended

paths

26+ Extremely complex Very difficult Very high — refactor!

13.3 Linearly Independent Paths — Kya Hain?

PARIBHASHA — Linearly Independent Path: Ek path jo kam se kam ek NAYI edge use karta hai jo
already-defined paths mein nahi thi. 'Basis path' bhi kehte hain. V(G) paths ka ek basis set hota hai.

Linearly independent paths identify karne ke steps:

• Step 1: Baseline path identify karo — usually longest path ya most common path
• Step 2: V(G) count karo — usi se paths needed count pata chalega
• Step 3: Baseline pe ek-ek decision node flip karo → naya independent path
• Step 4: Jab V(G) paths identify ho jaayein, ruko

Example (V(G)=3 program ke liye paths):

Path 1 (baseline): 1→2→3(F)→5(F)→7 [x<=0, z<10 false immediately → return 0]

Path 2: Flip if: 1→2→3(T)→4→5(F)→7 [x>0, z=x+y, z>=10 immediately → return]
Path 3: Flip while: 1→2→3(F)→5(T)→6→5(F)→7 [x<=0, z=0, loop once, then exit]

3 paths = V(G) = 3 ✓

Practical Note:

• Real programs mein infinite paths ho sakti hain (loop 0 times, 1 time, 2 times...)
• Isliye linearly independent paths use karte hain — manageable finite set
• Tools automatically paths aur test data generate kar sakte hain

■ EXAM QUESTION: Program mein 3 if, 2 while, 1 for statement hai. V(G) kya hoga? Min test
cases?
■ ANSWER: V(G) = Total decision nodes + 1 = (3 + 2 + 1) + 1 = 7. Minimum 7 linearly independent
paths hain, isliye minimum 7 test cases chahiye path coverage ke liye.

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 30

 LECTURE 14 — Dataflow Testing

14.1 Dataflow Testing Kya Hai?

PARIBHASHA — Dataflow Testing: Variables ki 'definition' (assign karna) aur 'use' (read karna) ke
beech ke paths ko systematically cover karna. Uninitialized variable use, incorrect computation, wrong
variable use detect karta hai.

Core Concepts:

Term Kya Matlab Hai Code Mein Example

def (definition) Variable ko value assign x = 5; ya read(x); ya x = f()

karna

use (use) Variable ki value read/utilize y = x + 3; ya print(x); ya if(x>0)

karna

c-use (computational Variable z = x * 2; ya result = x + y

use) arithmetic/assignment
expression mein use hona

p-use (predicate use) Variable condition/predicate if(x > 0); ya while(x != 0)

mein use hona

Def-Use (DU) Pair Variable ki ek def se ek use (x defined at line 3) → (x used at line 7)
tak ka connection

DU Path Def se use tak ka path jisme Koi intermediate re-assignment nahi
woh variable redefine na ho
(def-clear)

14.2 Dataflow Coverage Criteria — 3 Levels

Criterion Requirement Strength Test Cases

All-Defs Har variable ki har definition se kam se Weakest Minimum

kam 1 use cover ho (c-use ya p-use)

All-Uses Har variable ki har (def, use) pair ke liye Medium More tests
kam se kam ek def-clear path cover ho

All-DU-Paths Har variable ki har (def, use) pair ke Strongest Maximum

beech ke SAARE def-clear paths cover
hon

Complete Example:

Line 1: x = read() # def x at line 1

Line 2: y = x + 1 # def y at line 2; c-use x at line 2
Line 3: if (x > 0): # p-use x at line 3
Line 4: x = 10 # def x at line 4
Line 5: else:

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 31

 Line 6: x = -10 # def x at line 6
Line 7: z = x + y # c-use x at line 7; c-use y at line 7
Line 8: return z # c-use z at line 8

DU Pairs for x:

• (def@1, c-use@2) — path: 1→2 ✓ simple

• (def@1, p-use@3) — path: 1→2→3 ✓
• (def@1, c-use@7) via line 4 — path: 1→2→3→4→7 (if x>0 branch)
• (def@1, c-use@7) via line 6 — path: 1→2→3→6→7 (else branch)
• (def@4, c-use@7) — path: 4→7
• (def@6, c-use@7) — path: 6→7

All-Defs for x: Har definition se ek use cover karo

• def@1: cover path to @2 ya @3 ya @7 → TC: x=5 covers def@1→use@2 ✓

• def@4: cover path to @7 → TC: x=5 (enters if branch, def@4 then use@7) ✓
• def@6: cover path to @7 → TC: x=-5 (enters else, def@6 then use@7) ✓

■ EXAM TIP: Dataflow testing WHITE BOX technique hai — code dekhna padta hai. Coverage-based
white box testing ki ek advanced form.

■ EXAM QUESTION: def, use, p-use, c-use kya hain? Example code ke liye DU pairs identify karo.
■ ANSWER: def = variable ko value assign karna. use = variable ki value read karna. c-use =
computational expression mein use (z = x+2). p-use = predicate/condition mein use (if x>0). Example:
a=5 (def a), b=a+3 (c-use a), if(a>0) (p-use a). DU pairs for a: (def:line1, c-use:line2), (def:line1,
p-use:line3).

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 32

 LECTURE 15 — Mutation Testing

15.1 Mutation Testing Kya Hai?

PARIBHASHA — Mutation Testing: Fault-based white box testing technique. Test suite ki quality check
karna — kya hamare test cases real bugs pakad sakte hain? Code mein artificially bugs inject karte hain
aur dekhte hain ki test suite detect kar paata hai ya nahi.

Real-World Analogy:

• Sochto tum ek security guard (test suite) ka test kar rahe ho

• Tum khud chor ki dress mein enter karne ki koshish karte ho (mutant = injected bug)
• Agar guard pakad leta hai → Security system strong hai (mutant killed)
• Agar guard nahi pakda → System weak hai (mutant alive → fix the system/test suite)

15.2 Mutation Testing Process — Complete Steps

Ste Kya Karte Hain Detail

p

1 Original Program P ready Woh program jo test karna hai

karo

2 Test Suite T design karo Normal testing se test cases banao

3 T run karo P pe Saare test cases pass hone chahiye (agar fail ho toh design mein bug hai)

4 Mutation operators apply Small changes karke mutant programs P1, P2, ... Pn banao
karo

5 T run karo har mutant Pi pe Same test suite, different (mutant) program

6 Compare outputs P aur Pi ka output alag hai? → Mutant KILLED. Same? → Mutant ALIVE

7 Alive mutants handle karo Agar alive: new test cases add karo to kill it. Agar equivalent: manually identify
karke exclude karo

8 Mutation Score calculate Score = Killed / (Total - Equivalent) x 100%

karo

15.3 Common Mutation Operators — Detail mein

Mutation Operator Kya Change Karta Hai Before After

Statement Deletion Ek poori statement hata do x = y + z; (deleted)

Arithmetic Operator + ko -, * ko / se replace a = x + y; a = x - y;

Relational Operator > ko >= ya < se change if(x > 0) if(x >= 0)

Logical Operator AND ko OR, OR ko AND if(a && b) if(a || b)

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 33

 Mutation Operator Kya Change Karta Hai Before After

Constant Replacement Constant ki value change limit = 100 limit = 101

Variable Substitution Ek variable doosre se z=a+b z=c+b

replace

Data Type Change int ko float etc. int count = 0 float count = 0

Abs Insertion abs() function lagao/hatao x = val x = abs(val)

Return Statement Return value change karo return x return 0

Change

Statement Order Swap 2 consecutive statements a=1; b=2; b=2; a=1;

swap

15.4 Killed vs Alive vs Equivalent Mutants

Mutant Type Definition Matlab Action

Killed Mutant Test suite ka koi test case detect Test suite STRONG hai — Good! Count in numerator
karta hai (P aur Pi ka output alag yeh bug pakad sakta hai of mutation score
ata hai)

Live / Alive Mutant Koi test case detect nahi kar saka Test suite WEAK hai — yeh New test cases add karo
(P aur Pi same output) bug nahi pakda to kill it

Equivalent Mutant Mutant logically SAME hai original Program ki semantics Manually identify karo,
program ke — koi test kabhi kill nahi change nahi hui exclude from score
kar sakta

Equivalent Mutant Example:

Original: for (i = 0; i < n; i++)

Mutant: for (i = 0; i <= n-1; i++)

Dono exactly same number of times loop karte hain!

Koi bhi test case inhe differentiate nahi kar sakta.
= EQUIVALENT MUTANT — mutation score se exclude karo.

■ DHYAN DO: Equivalent mutants identify karna NP-hard problem hai! Manually karna padta hai. Isse hi
mutation testing expensive hoti hai.

15.5 Mutation Score Formula

Mutation Score = (Killed Mutants / (Total Mutants - Equivalent

Mutants)) x 100%

Example:

• Total mutants generated: 200

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 34

 • Equivalent mutants (manually identified): 20
• Non-equivalent mutants: 200 - 20 = 180
• Mutants killed by test suite: 162
Mutation Score = 162 / 180 x 100 = 90%

• Interpretation: Test suite 90% bugs pakad sakta hai — good!

• Remaining 10% (18 alive mutants) → improve test suite

15.6 Two Foundational Hypotheses (DeMillo, 1978)

PARIBHASHA — Competent Programmer Hypothesis: Programmers ALMOST CORRECT programs
likhte hain — minor errors karte hain, wholesale junk nahi. Isliye simple mutation operators (small
changes) real-world bugs accurately simulate karte hain.

PARIBHASHA — Coupling Effect Hypothesis: Ek complex bug = set of simple bugs ka coupling. Agar
test suite simple mutants kill kar le, complex/coupled bugs bhi detect ho jaate hain. Simple error detectors
complex error bhi pakad lete hain.

• Dono hypotheses proposed by DeMillo, Lipton, Sayward in 1978

• Yeh hi explain karte hain ki mutation testing kyun effective hai

■ EXAM QUESTION: Mutation testing mein 'alive mutant' ka kya matlab hai? Kya karna chahiye?
Equivalent mutant kya hai?
■ ANSWER: Alive mutant = test suite ne injected bug detect nahi kiya — saare tests pass ho gaye
mutant pe bhi. Matlab test suite weak hai. Action: Naye test cases add karo specifically to expose the
difference between original and mutant. Equivalent mutant: logically original jaisa hi hai — koi test kabhi
kill nahi kar sakta (same semantics). Inhe manually identify karke mutation score ke denominator se
exclude karo.

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 35

 LECTURE 16 — Integration Testing

16.1 Integration Testing Kya Hai?

PARIBHASHA — Integration Testing: Multiple units/modules ko combine karke test karna. Objective:
INTERFACE ERRORS detect karna — jo errors tab aate hain jab units interact karte hain, chahe
individually woh sahi kaam karte hon.

Interface Errors — Kya Hote Hain?

Error Type Kya Hota Hai Example

Wrong Parameter Type Caller alag type bhejta hai, callee Caller sends int, callee expects float
alag expect karta hai

Wrong Parameter Count Arguments ka count match nahi Caller sends 3 args, callee expects 2
karta

Wrong Parameter Order Order galat hai Caller sends (name, age), callee expects (age,
name)

Shared Data Bug Global variable ek module update Module A global counter change karta hai, Module
karta hai, doosra stale data use B purana value use karta
karta hai

Timing Issue Async calls mein race condition Function A ka result ready hone se pehle Function
B use karta hai

16.2 Types of Integration Testing — Comparison

■ Type 1: Big Bang Integration Testing

• Approach: Sab modules ek hi baar mein integrate karo → phir test karo
• Extra software: Kuch nahi — driver/stub nahi chahiye
• Advantage: Simple to set up, quick
• Disadvantage: Bug ISOLATION bahut mushkil — agar failure aaye toh kaunse module mein hai?
• Disadvantage: Fix karna expensive — pata nahi kahan se fix karein
• Real world usage: Sirf trivial/small programs ke liye

■ Type 2: Bottom-Up Integration Testing

• Approach: Sabse neeche ke modules se shuru karo → ek ek karke upar jaao
• Extra software needed: DRIVERS (kyunki upper modules abhi ready nahi, unhe simulate karo)

Bottom-Up ka Visual Flow:

Module Hierarchy:
[M1] ← Top level
/ \
[M2] [M3] ← Middle level
/ \ |

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 36

 [M4] [M5] [M6] ← Bottom level

Bottom-Up Steps:
Step 1: Test M4 alone (write Driver_for_M4)
Step 2: Test M5 alone (write Driver_for_M5)
Step 3: Test M6 alone (write Driver_for_M6)
Step 4: Integrate M2+M4+M5 (write Driver_for_M2)
Step 5: Integrate M3+M6 (write Driver_for_M3)
Step 6: Integrate M1+M2+M3 (no driver needed now!)

Bottom-Up ka Analysis:

• Advantage: Parallel testing possible — alag teams alag bottom modules test kar sakti hain
simultaneously
• Advantage: Actual data flow test ho sakta hai — low-level functions realistic test hote hain
• Disadvantage: Drivers likhne ka overhead
• Disadvantage: Top-level design aur architecture late validated hota hai
• Disadvantage: System-level test cases pehle run nahi ho sakte

■ Type 3: Top-Down Integration Testing

• Approach: Sabse upar ke module se shuru karo → ek ek karke neeche jaao
• Extra software needed: STUBS (kyunki lower modules abhi ready nahi, unhe simulate karo)

Top-Down ka Visual Flow:

Top-Down Steps (same hierarchy as above):

Step 1: Test M1 alone (write Stub_for_M2, Stub_for_M3)
Step 2: Integrate M1+M2 (Stub_for_M3, Stub_for_M4, Stub_for_M5 still needed)
Step 3: Integrate M1+M2+M4 (more stubs removed)
Step 4: Continue until all modules integrated

Top-Down ka Analysis:

• Advantage: High-level architecture aur design early validated ho jaata hai

• Advantage: System-level test cases pehle se run ho sakte hain
• Advantage: Drivers ki zaroorat nahi
• Disadvantage: Stubs likhne ka overhead
• Disadvantage: Low-level critical functions late tested hote hain
• Disadvantage: Stubs likhna mushkil ho sakta hai complex functions ke liye

■ Type 4: Sandwich / Mixed Integration Testing

• Approach: Top-Down + Bottom-Up DONO simultaneously
• Extra software: BOTH Drivers AND Stubs
• Middle layer se milte hain (sandwich shape mein)
• Advantage: Dono ke advantages combine hote hain
• Disadvantage: Middle layer ko twice test karna padta hai — ek baar top-down se, ek baar bottom-up se
• Real-world mein SABSE COMMON approach yahi hai!

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 37

 16.3 Comparison Table — Sab Types

Type Needs Start From Advantages Disadvantages

Big Bang Nothing All at once Simple, quick setup Isolation impossible, expensive
debugging

Bottom-Up DRIVERS Lowest modules Parallel testing, realistic data flow Late top-level testing, driver overhead

Top-Down STUBS Highest module Early design validation, no drivers Late low-level testing, stub overhead

Sandwich Both D+S Both ends Combines all advantages Middle layer double-tested, complex

■ EXAM TIP: SHORTCUT YAAD KARO: Bottom-Up → DRIVERS (B ka D → B ke liye D). Top-Down →
STUBS (T ka ST → Top ke liye STubs). Exam mein yeh distinction critical hai!

■ EXAM QUESTION: Top-Down aur Bottom-Up integration mein kya fark hai? Kab kaunsa use
karein?
■ ANSWER: Bottom-Up: lowest modules pehle test, DRIVERS likhte hain, parallel testing possible, top
design late validated. Top-Down: highest module pehle, STUBS likhte hain, design early validated,
low-level late. Use Bottom-Up: jab low-level utilities critical hon (database layer). Use Top-Down: jab
architecture aur high-level flow important ho. Real-world: Sandwich (both) sabse practical.

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 38

 LECTURE 17 — System Testing

17.1 System Testing Overview

PARIBHASHA — System Testing: Complete integrated system ko SRS (Software Requirements
Specification) document ke against test karna. VALIDATION activity. Dedicated testers karte hain —
developers nahi.

Aspect Unit/Integration Testing System Testing

V or V? VERIFICATION VALIDATION

Against what? Design document SRS Requirements

Who? Developers Dedicated Testers

What level? Individual units/groups Complete system

Perspective Developer perspective User/customer perspective

17.2 System Testing ke 2 Main Types

■ Type 1: Functional Testing

• SRS mein specified saari functionalities test karo
• Black box approach — specification based
• Saari EC, BVT, pairwise techniques applicable hain
• Happy paths + error paths dono test karo

■ Type 2: Non-Functional / Performance Testing

Non-functional requirements (NFRs) test karna — 'kaise behave karta hai' not 'kya karta hai':

Test Type Kya Test Karte Hain Kaise Karte Hain Metric

Load Testing Normal expected load pe Expected number of Response time, throughput under normal
behavior concurrent users simulate load
karo

Stress Testing SRS limits se BEYOND Normal se zyada users/data System ka breaking point, graceful
mein behavior do degradation

Volume Testing Large amount of data Max DB size, large file Performance with max data
handle karna processing

Usability Testing User friendliness, ease of Real users observe karo Task completion time, error rate,
use tasks perform karte hue satisfaction

Reliability Testing Kitna time bina fail ke Extended period MTBF (Mean Time Between Failures)
chalega continuously run karo

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 39

 Test Type Kya Test Karte Hain Kaise Karte Hain Metric

Security Testing Unauthorized access, Penetration testing, SQL Vulnerabilities found and patched
vulnerabilities injection, XSS

Portability Testing Different OS/platforms pe Windows, Mac, Linux, Pass/Fail on each platform
kaam karna different browsers test karo

Compatibility Different Different screen sizes, Compatible or not

Testing hardware/devices pe devices, configurations

Recovery Testing Crash ke baad recovery Forcefully crash karo, Recovery time, data loss
recovery time measure karo

Performance Response time under Load + stress combination Response time, CPU, memory usage
Testing conditions

■ DHYAN DO: DEFINITION YAAD KARO — Stress Testing: Input given BEYOND what SRS specifies.
Yeh definition exactly poochhi jaati hai exam mein. Load testing = WITHIN limits. Stress testing =
BEYOND limits.

■ EXAM QUESTION: Stress testing aur Load testing mein kya fark hai?
■ ANSWER: Load Testing: SRS mein specified normal/expected load pe system ka performance test
karna — e.g., 1000 concurrent users (as specified). Stress Testing: SRS limits se BEYOND input dena
— e.g., agar SRS mein 1000 users specified hain toh 5000 ya 10000 users dena, ya data volume 10x
karna. Stress testing system ka breaking point dhundhta hai. Load testing normal operation verify karta
hai.

17.3 Error Seeding Revisited — Bug Count Estimation

System testing phase mein manager estimate karna chahta hai: kitne bugs abhi bhi code mein hain?

PARIBHASHA — Error Seeding Formula: Manager S bugs seed karta hai. Testing ke baad s seeded
bugs detect hue, n original bugs detect hue. Estimate: N = (n x S) / s total original bugs.

N = (n x S) / s
• Assumption: Seeded aur original bugs ka detection rate SAME hona chahiye
• Agar seeded bugs too easy: overestimate hoga
• Agar seeded bugs too hard: underestimate hoga

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 40

 LECTURE 18 — Regression Testing

18.1 Regression Testing Kya Hai?

PARIBHASHA — Regression Testing: Software mein change ke baad, previously passing test cases
phir se run karna — ensure karne ke liye ki change ne koi existing functionality break nahi ki. Regression
bug = jo pehle kaam karta tha, change ke baad toot gaya.

Kyun Zaroor Hai? — Real Example:

• 50,000 line ka software hai. Ek bug fix kiya — sirf 10 lines change ki
• Un 10 lines mein ek variable ka value change hua
• Woh variable doosre 15 functions mein bhi use hoti hai
• Un 15 functions mein se 3 ab galat kaam karne lagein → Regression Bugs!
• Pehle kaam karte the, change ke baad toot gaye

■ NOTE: Regression testing unit, integration, aur system — TEENO levels pe applicable hai. Change ke baad
sab levels pe regression test karo.

18.2 Test Suite Partition — Change ke Baad

Category Definition Action Reason

Obsolete / Invalid Test Jo test cases wo feature test karte DISCARD — hata Feature ab exist nahi karta — test
Cases the jo delete ya completely change do invalid ho gayi
ho gayi

Redundant Test Cases Jo features test karti hain jo change SKIP — run mat Change se unaffected code — fail
se completely independent hain karo hone ka chance zero, time waste

Regression Test Cases Jo changed code ya usse MUST RUN — Yeh regression bugs detect
dependent code test karti hain zaroor chalao karenge

18.3 Regression Testing Process

• Step 1 — Change Analysis: Exactly kya change hua? Kaunsa code affected hua?
• Step 2 — Invalid TC removal: Obsolete test cases identify karke discard karo
• Step 3 — Regression Selection: Changed + dependent code ke test cases select karo
• Step 4 — Minimization: Duplicate/redundant test cases remove karo — same coverage, kam tests
• Step 5 — Prioritization: High-probability tests pehle run karo — jaldi bugs milein
• Step 6 — Execution: Regression tests run karo
• Step 7 — New Tests: New features ke liye naye test cases add karo

18.4 Regression Test Prioritization

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 41

 PARIBHASHA — Regression Test Prioritization: Regression test cases ko priority order mein arrange
karna — jo tests zyada probability ke saath bugs detect karein, unhe pehle run karo.

• Goal: Bugs jaldi detect karna → development team jaldi fix kar sake → faster delivery
• Priority factors: recently changed code, historical failure data, code coverage
• High priority: Saari tests jinke paths changed code ke through jaate hain
• Low priority: Tests jo completely independent code cover karti hain

■ EXAM TIP: CI/CD (Continuous Integration/Delivery) mein regression testing AUTOMATED hoti hai —
har commit pe automatically run hoti hai. Yeh modern software development mein standard practice
hai.

■ EXAM QUESTION: Regression testing kyun ki jaati hai? Test suite ko change ke baad kaise
classify karte hain?
■ ANSWER: Change ke baad variable propagation se unrelated functions break ho sakti hain
(regression bugs). Isliye previously passing tests rerun karte hain. Classification: (1) Obsolete —
feature deleted/changed, discard. (2) Redundant — completely independent of change, skip. (3)
Regression — dependent on change, MUST RUN. Then minimize (remove duplicates) and prioritize
(high-probability first).

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 42

 LECTURE 19-20 — Testing Object-Oriented Programs

19.1 OOP Testing Kyun Different Hai?

OOP se expect tha ki testing EASY ho jaayegi. Lekin actually OOP features ne NAYI testing challenges
create ki hain:

OOP Feature Testing Challenge Why Difficult

Inheritance Base class mein tested method New context — new variables, methods affect behavior
derived class mein fail ho sakta hai

Polymorphism Ek method call → runtime pe Compile time pe nahi pata kaunsi method call hogi
different implementations

Encapsulation Private state directly accessible Internal state verify karna mushkil
nahi

Dynamic Binding Method resolution runtime pe hota Sab possible bindings test karne padte hain
hai

Abstract Classes Directly instantiate nahi ho sakti Concrete subclasses ke through test karo

Multiple Inheritance Diamond problem, ambiguity Extra test cases for conflict resolution

Generics/Templates Type parameters kaafi Sab type combinations test karna impractical
combinations create karte hain

19.2 Inheritance Testing — Weyukar's Anticomposition Axiom

PARIBHASHA — Weyukar's Anticomposition Axiom: Base class mein ek method ka sahi kaam karna
derived class mein usi method ka sahi kaam karna GUARANTEE NAHI KARTA. Isliye inherited methods
ko derived class mein RETEST karna ZAROOR hai.

■ DHYAN DO: Inherited method retesting = RULE, not exception! Yeh baar baar exam mein poochha
jaata hai. 'Retesting is the rule rather than the exception.'

EXAMPLE 1 — New Variable Violates Invariant (Exact from Book):

class A:
x = 100 # class variable initialized to 100

def m(self):
# m() REQUIRES x >= 100 to work correctly
return x + 50 # works fine when x = 100

class B(A): # inherits m() from A

def m1(self):
x = 1 # NEW method in B — sets x to 1 !!

# Testing in class A:
# A.m() → x=100, returns 150 ✓ [PASSES]

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 43

 # Testing in class B:
# b = B()
# b.m1() → x is now 1
# b.m() → x=1, m() fails! (invariant x>=100 violated) ✗

# m() passed in A but FAILS in B!

# If we hadn't retested in B, this bug would escape!

EXAMPLE 2 — Dynamic Binding Changes Behavior (Exact from Book):

class A:
def m(self):
return self.m2() + 10 # calls m2()

def m2(self):
return 5 # returns 5

class B(A): # inherits m(), OVERRIDES m2()

def m2(self):
return -100 # completely different behavior!

# Testing in A:
# a = A(); a.m() → calls A.m2() → 5+10 = 15 ✓

# Testing in B:
# b = B(); b.m() → calls B.m2() (dynamic binding!)
# → -100 + 10 = -90 (VERY DIFFERENT!)

# m() was fine in A but gives wrong result in B

# because B overrode m2() which m() depends on!

WHY RETESTING IS NEEDED — Summary:

• New class variables in derived class → can violate invariants assumed by inherited methods
• New methods in derived class → can modify state that inherited methods depend on
• Dynamic binding → inherited method may call overridden version (different behavior)
• New class hierarchy → Weyukar's axiom: correctness at upper level doesn't guarantee lower level

19.3 Types of OOP Testing

Level What It Tests Analogous To Scope

Intraclass Testing Methods of ONE class, their Unit Testing in Single class, all its methods
interactions, valid/invalid method procedural
call sequences

Interclass Testing Multiple classes interacting, Integration Testing in Multiple related classes
cross-class method calls, procedural
inheritance chains

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 44

 19.4 Method Sequence Testing
PARIBHASHA — Method Sequence Testing: OOP mein ek object ek state machine ki tarah behave
karta hai — methods ka call order matter karta hai. Valid aur invalid method sequences test karo.

Stack class example:

class Stack:
push(item) # adds item
pop() # removes top item
peek() # sees top without removing
isEmpty() # checks if empty

VALID sequences:
push(1) → push(2) → pop() → peek() ✓
push(1) → isEmpty() ✓

INVALID sequences (should give error):

pop() before any push() → Underflow error!
peek() on empty stack → Error!

• Test both: valid sequences (correct behavior) + invalid sequences (proper error handling)
• State-based testing: Model object states as state machine → test transitions

■ EXAM QUESTION: Inheritance testing mein retesting kyun zaroori hai? Weyukar's Axiom kya
hai?
■ ANSWER: Weyukar's Anticomposition Axiom: base class mein sahi kaam karna derived class mein
guarantee nahi. Reasons: (1) new variables violate invariants, (2) new methods change state, (3)
dynamic binding overridden method call karta hai. Example: Class A mein x=100 hai, method m()
x>=100 assume karta hai. Class B mein m1() x=1 set karta hai. B mein m1() ke baad m() fail karta hai
— A mein kabhi nahi hua. Isliye RETEST RULE HAI.

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 45

 ■ QUICK REVISION — Exam se Pehle Zaroor Padho!

All Formulas — Ek Jagah

1. V(G) = E - N + 2 (E = edges, N = nodes in CFG)

2. V(G) = Decision Nodes + 1 (FASTEST to calculate)

3. MC/DC test cases = n + 1 (n = number of atomic conditions)

4. Multiple Condition Coverage = 2^n test cases

5. Mutation Score = Killed / (Total - Equivalent) x 100%

6. Error Seeding: N = (n x S) / s

7. Bug survival after k filters = Initial x (1 - efficiency)^k

8. BVT values for range [a,b]: a-1, a, a+1, mid, b-1, b, b+1

Coverage Subsumption — Sabse Important Chain

■ NOTE: A subsumes B = agar A achieve ho jaaye toh B automatically achieve ho jaata hai.

Coverage (Weak → Strong) Test Cases Subsumes What? Notes

Statement Coverage Minimum (1 Nothing (weakest) Every statement execute ho

path)

Branch/Decision Coverage Min 2 per Statement Coverage T aur F dono execute ho

decision

Basic Condition Coverage Min 2 ■ NOTHING — weaker than Individual atomic conditions T+F
Decision!

BC + Decision Coverage Min 2-4 Statement + Branch Both BC and Decision

MC/DC n+1 BC + Decision (all above) FAA-mandated, independence

Multiple Condition 2^n MC/DC + all above All combinations — impractical

Path Coverage V(G) Everything above All independent paths — strongest

■ DHYAN DO: EXAM TRAP: 'Basic Condition Coverage subsumes Decision Coverage' — YEH GALAT
HAI! Basic Condition is WEAKER than Decision Coverage. Never say basic condition subsumes
decision.

All Key Definitions — 2 Lines Mein

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 46

 Term Definition (2 lines)

Error/Mistake Programmer ki galti during development. Human action, not in code.

Fault/Bug/Defect Error ki wajah se code mein defect. In the product.

Failure Fault execute hone par runtime pe wrong behavior. Observable.

Verification 'Building it right?' Code ko previous artifact (design) ke against check karna.

Validation 'Building right thing?' Final product ko SRS requirements ke against check karna.

Driver Test unit ko CALL karne wala simulator software. Caller substitute.

Stub Test unit ke CALLED functions ka simulator. Callee substitute.

Test Case Triplet (I, S, O): Input + State + Expected Output.

Test Suite Complete collection of all test cases.

Cyclomatic Complexity V(G) Min linearly independent paths = min test cases for path coverage. V(G) = E-N+2.

MC/DC Each condition independently affects decision. n+1 test cases. FAA aviation
mandate.

Mutation Score % non-equivalent mutants killed by test suite.

Equivalent Mutant Logically identical to original — no test can kill it. Manually identify.

Pesticide Effect Same technique repeated use → surviving bugs become resistant/immune.

Regression Bug Previously working feature that breaks after a software change.

Error Seeding Inject known bugs → detection ratio → estimate remaining original bugs.

Pairwise Testing Cover all 2-parameter combinations. Catches 67-90% bugs with O(sqrt) test cases.

Weyukar's Axiom Base class method correctness does NOT guarantee derived class correctness.

Alpha Testing System testing at developer's site by development team.

Beta Testing System testing at selected friendly customers' site.

Acceptance Testing System testing done by customer at their site.

Big Bang Integration All modules integrated at once. Simple but bug isolation impossible.

Bottom-Up Integration Lowest modules first. Needs DRIVERS. Parallel testing possible.

Top-Down Integration Highest module first. Needs STUBS. Early design validation.

Competent Programmer Hypothesis Programmers write almost correct programs — only minor errors.

Coupling Effect Complex bugs = set of simple bugs. Kill simple mutants = kill complex bugs too.

20 Probable Exam Questions — Answer ke saath

■ EXAM QUESTION: Q1. Error, Fault aur Failure mein kya fark hai? Example ke saath explain karo.

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 47

 ■ ANSWER: Error = programmer ki galti (human). Fault = code mein defect (product). Failure = runtime
pe wrong behavior. Chain: Error → Fault → Failure, lekin ZAROOR NAHI. Example: 'i*j' ki jagah 'i*2'
likhna error. Agar j!=2 toh fault. Fault execute ho toh failure.

■ EXAM QUESTION: Q2. Pesticide Effect kya hai? Calculate: 800 bugs, 5 techniques, har ek 60%
effective.
■ ANSWER: Same technique baar baar use karne se bugs resistant ho jaate hain. Capers Jones:
~30% bugs detected per technique. Calculation: 800 x (0.4)^5 = 800 x 0.01024 = 8.2 ≈ 8 bugs survive.

■ EXAM QUESTION: Q3. Verification aur Validation mein difference kya hai?
■ ANSWER: Verification: 'Building it right?' code vs design. Developer karta hai. Static+Dynamic.
Unit/Integration testing. Validation: 'Building right thing?' product vs SRS. Tester karta hai. Only
Dynamic. System testing.

■ EXAM QUESTION: Q4. Draw CFG aur calculate V(G) for: if(x>0) { y=1; while(y<5) y++; } else y=-1;
■ ANSWER: Nodes: [if], [y=1], [while y<5], [y++], [y=-1], [end] = 6 nodes. Edges = 7. Decision nodes: if
+ while = 2. V(G) = 2+1 = 3. Or E-N+2 = 7-6+2 = 3.

■ EXAM QUESTION: Q5. MC/DC testing explain karo. Decision = A AND B ke liye test cases design
karo.
■ ANSWER: MC/DC: 4 requirements — entry/exit, condition coverage, decision coverage,
independence (each condition independently affects decision). n+1 test cases. A AND B: TC1=(T,T)=T,
TC2=(F,T)=F [A independent: TC1 vs TC2], TC3=(T,F)=F [B independent: TC1 vs TC3]. 3 test cases for
n=2.

■ EXAM QUESTION: Q6. Equivalence Class Partitioning explain karo. Age (18-65) ke liye ECs
design karo.
■ ANSWER: ECP: Input domain ko groups mein divide karo jahan sab values same behave karein. Ek
class se ek test value. Age (18-65): Valid EC={18-65, test=40}. Invalid EC1={<18, test=10}. Invalid
EC2={>65, test=70}. Weak EC: 3 test cases.

■ EXAM QUESTION: Q7. Boundary Value Testing explain karo. Salary range [10000, 100000] ke
values batao.
■ ANSWER: BVT: Programmers boundaries pe mistakes karte hain (off-by-one, < vs <=). 7 values:
9999 (invalid), 10000 (lower boundary), 10001 (just above), 55000 (nominal), 99999 (just below upper),
100000 (upper boundary), 100001 (invalid).

■ EXAM QUESTION: Q8. Bottom-Up aur Top-Down integration testing compare karo. Drivers aur
Stubs kya hain?
■ ANSWER: Bottom-Up: lowest modules first, DRIVERS likhte hain (caller simulate). Top-Down:
highest module first, STUBS likhte hain (called function simulate). Driver = test unit ko call karne wala.
Stub = test unit ke called function ka simulator. Bottom-Up: early low-level testing. Top-Down: early
design validation.

■ EXAM QUESTION: Q9. Mutation testing explain karo. Competent Programmer Hypothesis kya
hai?

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 48

 ■ ANSWER: Mutation testing: code mein bugs inject karo (mutants), test suite se detect karo —
mutation score = killed/(total-equivalent)x100%. Competent Programmer Hypothesis (DeMillo 1978):
Programmers almost correct programs likhte hain — minor errors. Isliye simple mutation operators real
bugs simulate karte hain. Coupling Effect: complex bugs = simple bugs combined.

■ EXAM QUESTION: Q10. Regression testing kyun ki jaati hai? Test suite classify karo.
■ ANSWER: Change ke baad variable propagation se unrelated features break ho sakti hain. Pehle
kaam karne wala code toot jaata hai. Classification: Obsolete (discard), Redundant (skip), Regression
(must run). Then minimize and prioritize.

■ EXAM QUESTION: Q11. Inherited methods ko derived class mein retest kyun karna padta hai?
■ ANSWER: Weyukar's Anticomposition Axiom: base class correctness derived class correctness
guarantee nahi karta. Reasons: new variables violate invariants, new methods change state, dynamic
binding overrides. Example: Class A mein x=100, m() works. Class B mein m1() sets x=1, then m() fails.

■ EXAM QUESTION: Q12. Pairwise testing kab use karte hain? 3 parameters, 2 values each ke liye
test set banao.
■ ANSWER: Jab parameters zyada hon aur all combinations impractical hon. Research: 67-90% bugs
2 params se. P1={A,B}, P2={C,D}, P3={E,F}: Pairs needed: P1-P2: AC,AD,BC,BD; P1-P3:
AE,AF,BE,BF; P2-P3: CE,CF,DE,DF. Test set: (A,C,E), (A,D,F), (B,C,F), (B,D,E) = 4 test cases cover
all pairs!

■ EXAM QUESTION: Q13. Error seeding formula explain karo. 300 seeded, 240 detected. 120
original found. N=?
■ ANSWER: Formula: N = (n x S) / s. n=120, S=300, s=240. N = (120 x 300) / 240 = 150. Total
estimated original bugs = 150. Still remaining = 150 - 120 = 30 bugs.

■ EXAM QUESTION: Q14. Basic Condition Coverage kyun Decision Coverage ko subsume nahi
karta?
■ ANSWER: Counterexample: if(A AND B). TC1=(T,F), TC2=(F,T). Basic Condition: A=T+F ✓, B=T+F
✓. Decision: BOTH cases = False! True branch NEVER executed ✗. So decision coverage NOT
achieved even though basic condition is. Basic condition is actually WEAKER than decision coverage.

■ EXAM QUESTION: Q15. Stress testing kya hai? Load testing se kaise alag hai?
■ ANSWER: Load testing: SRS mein specified NORMAL expected load pe performance verify karna.
Stress testing: SRS limits se BEYOND input dena — system ka breaking point find karna. Example:
SRS says 1000 users → Load: test with 1000. Stress: test with 5000, 10000 users to find breaking
point.

■ EXAM QUESTION: Q16. Decision table testing explain karo. 2 boolean conditions ke liye table
banao.
■ ANSWER: Decision table: conditions aur actions tabular form mein. n boolean conditions = 2^n rules.
Example: C1=User valid, C2=Password correct. R1=(T,T)→Login success. R2=(T,F)→Wrong
password error. R3=(F,T)→User not found. R4=(F,F)→User not found. Har rule ek test case.

■ EXAM QUESTION: Q17. Dataflow testing explain karo. def, p-use, c-use ke examples do.

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 49

 ■ ANSWER: Dataflow: variable ke def (assignment) aur use (read) ke beech paths cover karo. def: x=5
(assignment). c-use: z=x+3 (computational expression). p-use: if(x>0) (predicate/condition). DU pairs:
(def at L1, c-use at L3). All-Defs, All-Uses, All-DU-Paths — 3 criteria from weak to strong.

■ EXAM QUESTION: Q18. White Box testing kyun zaroor hai agar Black Box testing ho rahi hai?
■ ANSWER: Black Box alone ki problem: Code mein kuch extra/unreachable code ho sakta hai jo
specification mein nahi tha. Black box se woh kabhi execute nahi hoga — detect nahi hoga. White Box
se code coverage ensure hoti hai — dead code, unreachable paths, logic errors pakde jaate hain. Dono
complementary hain.

■ EXAM QUESTION: Q19. V(G) = 5 ka kya matlab hai? Program ka code kya hoga approximately?
■ ANSWER: V(G) = 5 matlab 5 linearly independent paths hain, minimum 5 test cases chahiye path
coverage ke liye. Moderate complexity. Code mein approximately 4 decision nodes (if/while/for) =
V(G)=5. Program with 3 if statements + 1 while loop would give V(G) = 4+1 = 5.

■ EXAM QUESTION: Q20. Unit testing verification hai ya validation? System testing?
■ ANSWER: Unit testing = VERIFICATION. Code ko Detailed Design ke against check karna — 'are
we building it right?' Developer karta hai. System testing = VALIDATION. Complete product ko SRS ke
against check karna — 'are we building the right thing?' Tester karta hai. Verification = process
conformance. Validation = requirements conformance.

All the best for your IIT exam! Mehnat ka phal zaroor milega. ■
Prof. Rajib Mall — IIT Kharagpur — Software Testing (20 Lectures)

Software Testing — IIT Kharagpur | Prof. Rajib Mall Page 50