Black Box Testing

Black box testing focuses on the determining whether or not a program do what it is supposed to do based on its functional requirement. It  is sometimes also called functional or behavioral testing.

Basically Black box testing is a kind of testing technique where the tester is unaware of  the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions.

Aim : To determine whether the function appears to work according to specifications

Black box testing attempts to find errors in the external behavior of the code mostly in the following categories:

  • incorrect or missing functionality
  • interface errors
  • errors in data structures used by interfaces
  • behavior or performance errors
  • initialization and termination errors

It is advisable that the person doing black box testing should not be programmer of the software under test and doesn’t know anything about the structure of the code. Since the programmers of the code are innately biased and are more likely to test that program does what they programmed it to do, while the reality is program should be tested in-order to make sure that the program does what customer wants it to do.


The format of the test case design is very important while doing black box testing. Let me give you a simple example of the test case planning template :

Test ID Description Expected Results Actual Results
1 Player 1 rolls dice and
Player 1 moves on board.
2 Player 2 rolls dice and
Player 2 moves on board.
3 Precondition: Game is in test
mode, SimpleGameBoard is
loaded, and game begins.
Number of players: 2
Money for player 1: Rs 1200
Money for player 2: Rs 1200
Player 1 dice roll: 3
Player 1 is located at Blue 3.

clear descriptions

A bit of advice would be that the test case description should be very clear and specific so that
the test case execution is repeatable. Even if you will always be the person executing the
test cases, pretend you are passing the test planning document to someone else to perform
the tests 🙂

strategies of black box testing

Since writing and executing test are fairly expensive process so we need to make sure to write the tests for the kind of things that the customer will do most often or
even fairly often with the motto of finding as many defects as possible with few test cases.

1. test of customer requirements

Black box test cases are based on customer requirements. We basically want to make sure that every customer requirements should be tested at least once. Find the defect as early as possible before delivering the end product to the customer.

2. Equivalence partitioning

It is basically a strategy which can be used to reduce the number of test cases that need to be developed.It divides the input domain of a program into classes and for  each of these equivalence classes, the set of data should be treated the same by the module under test and should produce the same answer. Test cases should be designed so the inputs lie within these equivalence classes.

I am running out of time now. I will post more on examples of equivalence partitioning and other methods such as boundary value condition, decision table etc. So stay tuned and enjoy testing! Cheers 🙂 🙂

Welcome back !

Let’s take an example of an application X. The tester doesn’t have any internal knowledge of the system, all he knows is about the input data and the output it is going to produce. Say this application accepts all the values between 1 – 10 (including 1 and 10). Now, the work of the tester is to test this application X using the above given information. Since the input domain of the application contains all the number from -∞ to +∞ which is an infinite set. He can’t test for all the cases so in order to reduce the number of test data he will use the technique equivalence partitioning.

…… -3, -2, -1, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 ……

——P1———–|  |————P2——————|   |—–P3——

By which the whole set in divided into three equivalence partition P1(-∞, 0], P2 [1, 10] and P3 [11, ∞). where P1 and P3 are invalid partitions and P2 is valid Partition.

P1  and P3  => Invalid partition

P2                => Valid partition

In test cases tester will use random data from each of the equivalence classes and data from same equivalence classes should show same behavior for application X.

3. Boundary value Analysis

It states that if the equivalence classes has been derived out of which we are going to pick test data for making test cases then we should pick data on the boundaries because these are the points where there is maximum chances that a programmer will do mistakes there.

Bugs lurk in corners and congregate at boundaries – Boris Beizer

For the equivalence classes which we got above, our test data should be on boundaries i.e the test data after performing boundary value analysis on the equivalence partitions  will be {0, 1, 10, 11}.