Black Box Testing

Boundary value analysis:

Boundary testing is the process of testing between extreme ends or boundaries
between partitions of the input values.

So these extreme ends like Start- End, Lower- Upper, Maximum-Minimum, Just Inside-
Just Outside values are called boundary values and the testing is called "boundary
testing".

Example 1

USER ID, accepts valid User Name and Password field accepts minimum 6 characters
and maximum 12 characters. Valid range 6-12, Invalid range 5 or less than 5 and
Invalid range 13 or more than 13.

Write Test Cases for Valid partition value, Invalid partition value and exact boundary
value.

Test Cases 1: Consider password length less than 6.

Test Cases 2: Consider password of length exactly 6.

Test Cases 3: Consider password of length between 7 and 11.

Test Cases 4: Consider password of length exactly 12.

Test Cases 5: Consider password of length more than 12.

Example 2

Test cases for the any input box accepts numbers between 1-1000.Valid range 1-1000,
Invalid range 0 and Invalid range 1001 or more.

Write Test Cases for Valid partition value, Invalid partition value and exact boundary
value.

Test Cases 1: Consider test data exactly as the input boundaries of input domain i.e.
values 1 and 1000.

Test Cases 2: Consider test data with values just below the extreme edges of input
domains i.e. values 0 and 999.
Test Cases 3: Consider test data with values just above the extreme edges of input
domain i.e. values 2 and 1001.

Equivalence Class Partitioning:

Equivalence Partitioning = Equivalence Class Partitioning = ECP

Equivalence partitioning is a testing technique where input values set into classes for
testing.

Valid Input Class = Keeps all valid inputs.

Invalid Input Class = Keeps all Invalid inputs.

Example 1

(Telephone Number / Pin)

-A text field permits only numeric characters

-Length must be 6-10 characters long

Partition according to the requirement should be like this:

That means results for values in partitions 0-5, 6-10, 11-14 should be equivalent

Test Scenario # Test Scenario Description Expected Outcome

1 Enter 0 to 5 characters in Telephone Field System should not accept

2 Enter 6 to 10 characters in Telephone Field System should accept

3 Enter 11 to 14 character in Telephone Field System should not accept

Decision Table Testing:

This test technique is appropriate for functionalities which has logical relationships
between inputs (if-else logic). In Decision table technique, we deal with combinations of
inputs. To identify the test cases with decision table, we consider conditions and
actions. We take conditions as inputs and actions as outputs.
Example 1: an example of transferring money online to an account which is already
added and approved.

Conditions (inputs) to transfer money:

1- ACCOUNT ALREADY APPROVED

2- OTP (One Time Password) MATCHED

3- SUFFICIENT MONEY IN THE ACCOUNT

And Actions (output) performed:

1-TRANSFER MONEY

2- SHOW A MESSAGE AS INSUFFICIENT AMOUNT

3- BLOCK THE TRANSACTION INCASE OF SUSPICIOUS TRANSACTION

In the first column I took all the conditions and actions related to the requirement. All the
other columns represent Test Cases.

T = True, F = False, X = Not possible

From the case 3 and case 4, we could identify that if condition 2 failed then system will
execute Action 3. So we could take either of case 3 or case 4
So finally concluding with the below tabular column.

We write 4 test cases for this requirement.

Example 2: login page validation. Allow user to login only when both the ‘User ID’ and
‘Password’ are entered correct.

Conditions (inputs) to allow user to login:

1- ENTER VALID USER ID

2- ENTER VALID PASSWORD

And Actions (output) performed:

1- Displaying home page

2- Displaying an error message that User ID or Password is wrong

From the case 2 and case 3, we could identify that if one of the condition failed then the
system will display an error message as Invalid User Credentials.

So I am eliminating one of the test case from case 2 and case 3 and concluding with the
below tabular column.
State Transition Testing:
It is a black box testing technique in which the tester analyzes the behavior of an
application under test for different input conditions in a sequence. In this technique,
tester provides both positive and negative input test values and record the system
behavior.

-This can be used when a tester is testing the application for a finite set of input values.

-When the tester is trying to test sequence of events that occur in the application under
test. I.e., this will allow the tester to test the application behavior for a sequence of input
values.

-When the system under test has a dependency on the events/values in the past.

Example 1: In the Bank login screen, consider you have to enter correct User ID and
password to access the Banking application.

It gives you the access to the application with correct password and login name, but
what if you entered the wrong password.

The application allows three attempts, and if users enter the wrong password at 4th
attempt, the system closes the application automatically.

The State Graphs helps you determine valid transitions to be tested. In this case, testing
with the correct password and with an incorrect password is compulsory. For the test
scenarios, log-in on 2nd, 3rd and 4th attempt anyone could be tested.

You can use State Table to determine invalid system transitions.

In a State Table, all the valid states are listed on the left side of the table, and the
events that cause them on the top.

Each cell represents the state system will move to when the corresponding event
occurs.

For example, while in S1 state you enter a correct password you are taken to state S6
(Access Granted). Suppose if you have entered the wrong password at first attempt you
will be taken to state S3 or 2nd Try.

Likewise, you can determine all other states.

Two invalid states are highlighted using this method. Suppose you are in state S6 that is
you are already logged into the application, and you open another instance of Bank and
enter valid or invalid passwords for the same User. System response for such a
scenario needs to be tested.

Use Case Testing:

Use case plays a significant role in the distinct phases of Software Development Life
Cycle. Use Case depends on ‘User Actions’ and ‘Response of System’ to the User
Actions.

In Use Case, we will describe ‘How a System will respond to a given Scenario?’. It is
‘user-oriented’ not ‘system oriented’.

It is ‘user-oriented’: We will specify ‘what are the Actions done by the user?’ and ‘What
the Actors see in a system?.

It is not ‘system oriented’: We will not specify ‘What are the input given to the system?’
and ‘What are the output produced by the system?’.

Example 1:

The Use case for ‘Login’ to a ‘Banking Application’

Use Case Name Login

Use case Description A user login to System to access the functionality of the system.

Actors Manager, Customers

Pre-Condition System must be connected to the network.

Post -Condition After a successful login a notification mail is sent to the User mail id

Main Scenarios Serial No Steps

Actors/Users 1 Enter User ID

Enter Password

2 Validate User ID and Password

3 Allow access to System

Extensions 1a Invalid User ID

System shows an error message

2b Invalid Password
System shows an error message

3c Invalid Password for 4 times

Application closed
 White Box Testing
Decision (Branch) Coverage Testing:
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.

Decision coverage reports the true or false outcomes of each Boolean expression.

Example1:

Read A

Read B

IF A+B > 10 THEN

Print "A+B is Large"

ENDIF

If A > 5 THEN

Print "A Large"

ENDIF
The above logic can be represented by a flowchart as:

Result:

To calculate Branch Coverage, one has to find out the minimum number of paths which
will ensure that all the edges are covered. In this case there is no single path which will
ensure coverage of all the edges at once. The aim is to cover all possible true/false
decisions.

(1) 1A-2C-3D-E-4G-5H

(2) 1A-2B-E-4F

Hence Decision or Branch Coverage is 2.

Example2:

Demo(int a) {

If (a> 5)

a=a*3

Print (a)

Scenario 1:

Value of a is 2

The code highlighted in yellow will be executed.

Here the "No" outcome of the decision If (a>5) is checked.

Decision Coverage = 50%

Scenario 2:

Value of a is 6

The code highlighted in yellow will be executed.

Here the "Yes" outcome of the decision If (a>5) is checked.

Decision Coverage = 50%

Test Case Value of A Output Decision Coverage

1 2 2 50%

2 6 18 50%

Statement Coverage Testing:

It is test design technique which involves execution of all the executable statements in
the source code at least once. It is used to calculate and measure the number of
statements in the source code which can be executed given the requirements.

Statement coverage is used to derive scenario based upon the structure of the code
under test.
Example1:

Read A
Read B
if A>B
Print “A is greater than B”
else
Print "B is greater than A"
endif

Set1:

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

Set2:

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

Example2:

Prints (int a, int b) {

int result = a+ b;

If (result> 0)

Print ("Positive", result)

Else

Print ("Negative", result)

}
Set1:

If A = 3, B = 9

Number of executed statements = 5

Total number of statements = 7

Statement Coverage: 5/7 = 71%

Set2:

If A = -3, B = -9

Number of executed statements = 6

Total number of statements = 7

Statement Coverage: 6/7 = 85%