ISTQB

Black-box Testing

No knowledge of internal structure/working of the software

Equivalence Partitioning

Equivalence Partitioning or equivalence class partitioning (ECP) is a software testing technique that
divides the input data of a software unit into partitions of equivalent data from which test cases can be
derived
Used when range of input values needs to be tested
It divides the input data of software into different equivalence data classes

e.g. Password of 4 to 10 characters need to entered

Age of 5 to 45 can be entered

Partition 1 Partition 2 Partition 3

Invalid Valid Invalid

4 10

We pick only one value from each partition for testing

Assumption : If one value in a partition passes, all others will also pass. Likewise, if one value in a partition fails,
all others in that partition will fail.
Boundary Value Analysis
In BVA, we test boundaries between equivalence partitions

Partition 1 Partition 2 Partition 3

Invalid Valid Invalid

3 4 5 9 10 11
Decision Table Testing
What is Decision Table Testing? Decision table testing is a software testing technique used to test system
behavior for different input combinations.

This is a systematic approach where the different input combinations and their corresponding system behavior
(Output) are captured in a tabular form

e.g. Testing the login page

Field Value
UserName T T F F
Password T F T F
Expected Successful Incorrect Incorrect Incorrect
Result Login Password Username Username
and
Password
State Transition Testing
State Transition Testing is a black box testing technique in which changes made in input conditions
cause state changes or output changes in the Application under Test(AUT).

e.g. ATM Machine , Vending machine

Use Case Testing
White Box Test Techniques
• Statement Coverage
• Decision Coverage
• Path Coverage
• MC/DC
Statement Coverage
Statement coverage is a white box testing technique, which involves the execution of all the statements at
least once in the source code.

It is a metric, which is used to calculate and measure the number of statements in the source code which have
been executed

Using this technique we can check what the source code is expected to do and what it should not.

Statement coverage = No of statements Executed/Total no of statements in the source code * 100

Example:
Read A
Read B
If A> B
Print “ A is greater than B”
Else
Print “ B is greater than A”
EndIf
No of statements Executed: 5
Set1 :If A =5, B =2 Total no of statements in the source code: 7
Statement coverage =5/7*100 = 71.00 %

No of statements Executed: 6
Set2 :If A =2, B =5 Total no of statements in the source code: 7
Statement coverage =6/7*100 = 85.20 %
Decision Coverage

Decision coverage or Branch coverage is a testing method, which aims to ensure that each one of the
possible branch from each decision point is executed at least once and thereby ensuring that all reachable
code is executed

TC1 : Age=>60 - Yes

TC2 : Age <60 - No
Path Coverage

In this the test case is executed in such a way that every

path is executed at least once.

All possible paths are-

1A-2B-E-4F
1A-2B-E-4G-5H
1A-2C-3D-E-4G-5H
1A-2C-3D-E-4F
 Modified Condition/Decision Coverage(MC/DC)
if( kettle &&cup && coffee )

Used when modified conditions are to be tested

Imagine making a cup of coffee. To make a warm and tasty cup of coffee, we'd need ALL of the following: a kettle, a cup
and coffee. If any of the components were missing, we wouldn't be able to make our coffee.

If (Kettle && Cup && Coffee) then

Print “ Cup of coffee can be done”
Else
Print “ No Coffee can be done”
endIf

Tests 4 & 8 demonstrate that ‘kettle’ can independently affect the outcome.
Tests 6 & 8 demonstrate that ‘mug’ can independently affect the outcome.
Tests 7 & 8 demonstrate that ‘coffee’ can independently affect the outcome.