BLACK BOX TESTING

Objective : Doing Black Box Testing taking an example

A simple login screen of software or a web application will be tested for seamless user login. The
login screen has two fields, username and password as an input and the output will be to enable
access to the system.

A black box testing will not consider the specifications of the code, and it will test the valid
username and password to login to the right account.

This form of testing technique will check the input and output.
● A user logged in when inputs a present username and correct password
● A user receives an error message when enters username and incorrect password

The black box testing is also known as an opaque, closed box, function-centric testing. It
emphasizes on the behavior of the software. Black box testing checks scenarios where the system
can break.

For example, a user might enter the password in the wrong format, and a user might not receive
an error message on entering an incorrect password.

EXAMPLE : EQUIVALENCE AND BOUNDARY VALUE ANALYSIS

● Let's consider the behavior of Order Pizza Text Box.

● Pizza values 1 to 10 is considered valid. A success message is shown.
● While value 11 to 99 are considered invalid for order and an error message will
appear, "Only 10 Pizza can be ordered"

Here is the test condition

1. Any Number greater than 10 entered the Order Pizza field(let say 11) is considered
invalid.
2. Any Number less than 1 that is 0 or below, then it is considered invalid.
3. Numbers 1 to 10 are considered valid
4. Any 3 Digit Number say -100 is invalid.

We cannot test all the possible values because if done, the number of test cases will be more than
100. To address this problem, we use equivalence partitioning hypothesis where we divide the
possible values of tickets into groups or sets as shown below where the system behavior can be
considered the same.

The divided sets are called Equivalence Partitions or Equivalence Classes. Then we pick only
one value from each partition for testing. The hypothesis behind this technique is that if one
condition/value in a partition passes all others will also pass. Likewise, if one condition in a
partition fails, all other conditions in that partition will fail.
Boundary Value Analysis- in Boundary Value Analysis, you test boundaries between
equivalence partitions

In our earlier example instead of checking, one value for each partition you will check the values
at the partitions like 0, 1, 10, 11 and so on. As you may observe, you test values at both valid
and invalid boundaries. Boundary Value Analysis is also called range checking.

Equivalence partitioning and boundary value analysis(BVA) are closely related and can be used
together at all levels of testing.

● DECISION TABLE TESTING

For example, A food delivery application will check various payment modes as input to place the
order — decision making based on the table.
✔ Case1: If the end-user has a card, then the system will not check for cash or coupon and
will take action to place the order.
✔ Case2: If the end-user has a coupon will not be checked for a card or cash and action will
be taken.
✔ Case3: if the end-user has cash, the action will be taken.
✔ Case4: If the end-user doesn’t have anything, then action will not be taken.
Title: WHITE BOX TESTING
Objective : Doing White Box Testing taking an example

A customer needs to transfer money to a friend who lives abroad. They’re going to use the
mobile banking service provided by their bank to do this.
● Step 1: Identify the feature, component, program to be tested
Zero in on what you want to test.
When it comes to white box testing, the smaller your target system component, the better it
is. Given what we’re trying to achieve – test all possible scenarios and cases for a given
feature – individually testing individual features helps you focus on a small enough area of
the code.

A narrower focus also implies the ability to be more thorough. Remember, in a lot of the
cases, you’re doing white box testing mainly because that specific system, feature,
component is critical and needs to be tested through and through to guarantee it works as
expected.

“A narrower focus also implies the ability to be more thorough.”

So, you should try and identify the smallest logical module or component for the system
being tested, and work on this first. When you’re finished testing this module, you can move
on to the next one.

Taking on a larger scope

Yes – it is possible that you’d take on white box testing for entire systems. Where the system
involved is critical, draping it in white box testing will give you a high degree of confidence
about code quality and resilience.
However, you need to weigh the effort involved versus the benefits derived. white box
Testing is often labour intensive and will consume considerable resource. So it is important
to balance effort with need.
“White box Testing is often labour intensive and will consume considerable resource. So it is
important to balance effort with need.”
● Step 2: Plot all possible paths in a flowgraph
This step covers a big portion of your preparation to plan and execute white box Testing
successfully.
As with any effort – be it development or testing – understanding ‘Scope’ is paramount.
And, we already know that Path Coverage provides a comprehensive solution to Test
coverage.
Here, we’re trying to understand all the possible paths that can be tested for a given feature,
component, module. Identifying all possible paths helps in writing test cases to cover each
one of them. And the best way to do this, is to draw a flowgraph that brings out these paths.
Consider the example below:

Obviously, transferring funds from your bank account isn’t this simple. Sure, for some of
us it can feel like it, but that’s because we don’t normally face the exceptions that quite a
few others encounter when attempting to move money.
Having said that, this Simple flowgraph will do nicely to demonstrate white box Testing.
To complete the flowgraph, you may need to refer to the following:
o User journeys, use cases
o Program specifications
o Technical specifications, pseudocode
● Step 3: Identify all possible paths from the flowgraph
Now, as we can see there are two possible paths for this journey:
1. 1, 2, 3, 5, 6, 7 and
 2. 1, 2, 3, 4, 6, 7
Being a simple example, only two paths exist to this journey. Nevertheless, you get the
idea. Identify every permutation and combination for how the journey could flow from
start to end. Identify any midway drop off points. And you’re all set.
● Step 4: Write Test Cases to cover every single path on the flowgraph
When we have all available paths plotted on the flowgraph, then go ahead and write test
cases to test each of these paths.
When we have a bunch of test cases that we are confident will cover every single path, we
are ready to go to the execution phase.
● Step 5: Execute, rinse, repeat
We are now ready to execute white box Testing for the identified system, component or
module. And we have the flowgraph and Test Cases necessary to complete Testing.
That, in simple terms, is how we plan and execute white box Testing.

EXAMPLE

Consider this pseudo code:

INPUT A & B

C=A+B

IF C>100

PRINT “ITS DONE”

END IF

IF A>50

PRINT “ITS PENDING”

END IF

Now to ensure maximum coverage, we would require 4 test cases.

How? Simply – there are 2 decision statements, so for each decision statement, we would need
two branches to test. One for true and the other for the false condition. So for 2 decision
statements, we would require 2 test cases to test the true side and 2 test cases to test the false
side, which makes a total of 4 test cases.

To simplify these let's consider below flowchart of the pseudo code we have:

In order to have the full coverage, we would need following test cases:
TestCase_01: A=50, B=60
TestCase_02: A=55, B=40
TestCase_03: A=40, B=65
TestCase_04: A=30, B=30
So the path covered will be:
Red Line – TestCase_01 = (A=50, B=60)

Blue Line = TestCase_02 = (A=55, B=40)

Orange Line = TestCase_03 = (A=40, B=65)

Green Line = TestCase_04 = (A=30, B=30)