Black Box Testing

Every software, before getting launched into the market, is tested for its functionality thoroughly. And it is necessary too, as a lot of money is on roll, for every software that is made for diversified applications, be it banking, airways, railways or even educational system. This is where software testing comes into picture, to check whether or not an application is functioning correctly, using all the permutation and combinations of possibilities that may or may not occur. Once an application is developed with a particular software, there are many types of testing that are done on the software. One of the software testing methodologies is black box software testing.

Black box software testing can be defined as a test design method, which helps in checking the functional requirements of an application, without explicitly using the knowledge of the core structure of the application. A set of test cases are created with a combination of correct and incorrect inputs, depending on the design, requirements and specifications of the application developed. This testing usually commences as soon as the code for application is developed in a raw form. Other names for this testing method are:

• Functional testing
• Closed box testing
• Opaque box testing
• Behavioral testing

Black Box Software Testing Techniques

There are certain set of techniques used in black box testing which speculate the various possible outputs, from which the inputs and the functionality of the application software can be validated. Go through the techniques mentioned below to understand this subject better.

Decision Table
A decision table as the name suggests, is a testing strategy, which gives outputs to your test cases, based on decision. It comprises a table containing 4 quadrants, conditions, condition entries, action statements and action entries. Precisely, all possible conditions are tried out to check if the desired output is attained after trying different inputs. So how to make a decision table? Follow the points below to create one.

• First before designing a decision table, eliminate all the impossible situations, redundancies and inconsistencies that could be a part of the input data.
• Determine the number of conditions that have an impact on the decision.
• Determine all possible actions that could be taken, and the number of condition alternatives for every condition. Considering a simple decision table, the alternatives are ‘yes’ or ‘no’.
• Now, try to figure out the possible unique combinations/possibilities which can be calculated by finding possible values for each condition and multiplying them together. This will also give you the total number of columns to insert in the table.
• Enter all the possible combinations derived, in the columns in top of the decision table.
• For every unique possibility, mark an X in the right lower quadrant in the appropriate action row. This symbol indicates the intersection of the required action and the unique combination.
• Once the table is complete, check for any contradictions and remove them. Rearrange the table contents accordingly.

Let’s take a simple black box testing example using this method: Consider a marketing company which has decided to market 4 products (A, B, C and D), depending on the three characteristics: Gender (Male – M or Female – F), City dweller (Yes – Y or No – N) and Age group ( 60 (Z)). So the total number of columns are: 2 (Gender) x 2 (City Dweller) x 3 (Age group) = 12 columns. Now rule set says:

• Product A for females who dwell in the city
• Product B for young females
• Product C for middle aged male shoppers who are not city dwellers
• Product D for all except old females

Condition alternativesProcess1
2
3
4
5
6
7
8
9
10
11
12
Sex
F
M
F
M
F
M
F
M
F
M
F
M
City
Y
Y
N
N
Y
Y
N
N
Y
Y
N
N
Age
X
X
X
X
Y
Y
Y
Y
Z
Z
Z
Z
Action EntriesMarketing Product1
2
3
4
5
6
7
8
9
10
11
12
Product A
X
–
–
–
X
–
–
–
X
–
–
–
Product B
X
–
X
–
–
–
–
–
–
–
–
–
Product C
–
–
–
–
–
–
–
X
–
–
–
–
Product D
X
X
X
X
X
X
X
X
–
X
–
X

Here, the table can be further simplified. How? If you observe the table, the rules of column 2, 4, 6, 7, 10 and 12 have the same action items. Similarly, rules 2, 6 and 10 satisfy 2 out of the three condition entries of gender and city dweller. Rules for 4 and 12, although have same action pattern cannot be merged because of the different age criteria. And lastly, age group Y is not covered. So the modified decision table is as follows:

Condition alternativesProcess1
2
3
4
5
6
7
8
9
10
Sex
F
M
F
M
F
F
M
F
F
M
City
Y
Y
N
N
Y
N
N
Y
N
N
Age
X
–
X
–
X
Y
Y
Y
Z
Z
Action EntriesMarketing Product1
2
3
4
5
6
7
8
9
10
Product A
–
X
–
–
X
–
–
X
–
–
Product B
X
–
X
–
–
–
–
–
–
–
Product C
–
–
–
–
–
–
X
–
–
–
Product D
X
X
X
X
X
X
X
–
–
X

Equivalence Partitioning
Equivalence partitioning is yet another black box testing method aimed at reducing the total number of test cases for software testing by dividing the input data into partitions. This method is useful in determining the valid and invalid inputs for application testing. Further the test cases are prepared on each partition to ensure that the application processes the input data correctly when a valid input is entered and otherwise throws an error message. Based on inputs, where the results are identical, those test cases are grouped as one equivalence class. There is a particular airline company which offers different privileges for the various memberships, based on the number of flights availed by a regular air customer.

Number of FlightsMembership5-10
Silver
11-15
Gold
16-20
Platinum
21-40
Diamond

So from the above data, it can be inferred that the conditions stated apply for number of flights that range between 5-40. Any number that is below 5 or more than 40 is an invalid input for the program. So here, the equivalence partitioning yields 7 partitions that include the above mentioned 4 valid test cases and 3 more test cases which are inclusive of the invalid inputs like, 40 and non numeric values. The reason why invalid inputs are also considered is to calculate the absolute test coverage of the application being tested.

Boundary Value Analysis
As the name suggests, this method is aimed at defining and rechecking the limits defined in the equivalence partitioning method. Here the test cases are specially designed to include the boundary values to locate errors in the application software. So the first step is to identify the inputs and the possible outputs, both valid and invalid. It has been observed that most errors identified during testing occur at the boundaries of the input domain. For instance, let’s have a look at the below example where the black box testing is being done for an input box which accepts numbers between 1-1000. The possible test cases with variations in the boundaries include:

• Test case with test data 1 – 1000 (both the input boundary values inclusive)
• Test case with test data 0 – 999 (starting from one less than the extreme boundaries)
• Test case with test data 2 – 1001 (starting from one greater than the extreme boundaries)

Testing the application with the above combination of test data is also a part of negative or stress testing which will help in assessing the positive and the negative test coverage accurately.

Cause and Effect Graphing
Cause and Effect Graphing as the method suggests, is about identifying a cause and then anticipating the effect, converting the layman procedure to a software based algorithm by first listing the causes and the effects, then graphing them, converting the graph to a decision table and then finally to test cases. So this method helps in identifying the correct inputs for equivalence partitioning method. Now, follow the below steps to graph the cause and effect and convert it to a decision table as mentioned above.

• Identify the application requirements and break them into subsets of small functionalities.
• Identify the cause and the effect for the requirements set.
• Now create a logical relationship between the subsets of requirements.
• Derive possible and impossible combinations of cause and effect duo, and graph them.
• Convert the graph into a decision table, with the column signifying the test case and row as the cause/effect.
• Now the columns can be converted into test cases which have a definite set of valid and invalid inputs, which aid in determining the test coverage.

State Transition Diagram
To understand the behavior of a system application, state transition diagrams are required. This method graphically depicts a series of events occurring in different states/conditions. Using this testing technique, one gets to understand the internal system design and requirements. If you have a clear understanding of flowcharts, a state transition diagram would be a cake walk for you. This diagram comprises four states:

• Current state
• Event
• Action
• Next state

Events happening in the current state always bear 2 possibilities, yes or no. So based on that, actions too are different and depending on these actions, the next state is identified. After graphing this diagram, one can easily create a state transition table which aids in unearthing some undetected combinations which may not have been identified or documented in other techniques as listed above. So when creating test cases, one must ensure that all the events in the application are triggered at least once, and the pathways connecting the events and the actions are tread at least once. If there are internal loops created when designing a state transition diagram, there is a possibility of deadlocks, memory leaks, etc., which need to be worked on. This method is best recommended for real time applications. For instance, take a simple example of filling a bottle.

• You have an empty bottle which needs to be filled. This is an event, which immediately calls for action of filling the bottle.
• Now the bottle is being checked, for whether it is full or not. If it is full, the next action is to seal it. If it is not full, the event is redirected to filling it first.
• Once the bottle is filled with water. It needs to be checked for leaks. If there is a leak, then it is broken and is redirected to the first event of empty.
• Else the action of sealing the bottle comes across as the last step.

This was a simple example illustrating the behavior of a system. To understand this concept better, one has to be well versed with the subject of UML (Unified Modeling Language).

White Box versus Black Box Testing

Unlike black box software testing where the tester need not have a knowledge on the working of code deployed in the application, for white box testing, it is a must. Specially, when the graphical user interface keeps changing during code merges and deployments in the software testing phase, the tester needs to introspect the changes being done every now and then. Also, if one is following the state transition diagram method for black box testing, then the white box testing will help in evaluating the re-usability of the test cases generated and also will help in checking whether all the pathways connecting the actions and the events have been traversed at least once. But as far as software testing is concerned, both these testing techniques are very important for checking not only the overall functionality of the application but also the code quality and application.

Software testing is an integral part of software development life cycle. Without the testing part, an application remains incomplete. There are many testing tools, available on Internet, for both black box testing and white box testing which help in generating test cases for your applications. But make sure that you understand the testing techniques well, before implementing them in your application. Good luck!