Black box testing tests the functionality of the application without having the knowledge of code. It is also called as Specification based testing.
Black box testing design techniques are:
- Decision table testing
- All pairs testing
- State transition testing
- Equivalence partitioning
- Boundary value analysis
- Error Guessing
Decision Table testing
It is the testing of scenario which has yes or no condition. In this decision-based testing, we will test for both the conditions. What happens when the variable status is “Yes” or what happens if it is “No”? This is mostly like if-then-else, switch cases with each condition having some actions to perform. So we need to test all the actions.
All pairs testing
All pairs testing is a method to test all the possible discrete combinations of the parameters involved. Consider an application where we need to supply value to some three input parameters. So we need to test all possible combinations of input based on probability. We have to consider all possible scenarios like,
If we give value for all 3 parameters
If we do not give value for all 3 parameters
If we give value for 2 parameters.
This testing is mainly to produce an optimal number of test cases. We do not want to perform the entire test based on the probability (3 * 2) since we have 3 parameters but we can achieve the result by some combinations of input.
State transition testing:
This table shows the current state of the machine and to which status the machine will move to based on input parameters.
For example, if you request to withdraw $100 from a bank ATM, you may be given cash. Later you may make exactly the same request but it may refuse to give you the money because of your insufficient balance. This later refusal is because the state of your bank account has changed from having sufficient funds to cover the withdrawal to having insufficient funds. The transaction that caused your account to change its state was probably the earlier withdrawal.
Equivalence Partitioning is a common black box testing technique and aims to reduce the number of redundant test cases by eliminating those that generate the same output and do not necessarily reveal defects in a program functionality.
As the aim of testing is to find defects, then a successful test case is the one that does find a defect.
The process of equivalence partitioning technique involves identifying the set of data as an input condition that give the same result when executing a program and classifying them as a set of equivalent data (because they make the program behave in the same way and generate the same output) and partitioning them from another equivalent set of data.This involves partitioning the data into some sets/group so that one test case is enough to cover each partition. Consider an application where the app will work only if the value supplied by the user is between 10 to 100. So we can divide these as
“1 to 10 as one partition
10 to 100 as second
> 100 as third.”
So while testing any one value from each partition is enough to test. After portioning we have to apply boundary value cases in order to select the best-suited test case from each partition.
Boundary value analysis
For each range, there are two boundaries, the lower boundary (start of the range) and the upper boundary (end of the range) and the boundaries are the beginning and end of each valid partition. We should design test cases which exercise the program functionality at the boundaries, and with values just inside and just outside the boundaries.
Minimum Value, Minimum Value + 1, Minimum Value -1
Maximum Value, Maximum Value + 1, Maximum Value – 1
The Error guessing is a technique where the experienced and good testers are encouraged to think of situations in which the software may not be able to cope. In using more formal techniques, the tester is likely to gain a better understanding of the system, what it does and how it works. With this better understanding, a person is likely to be better at guessing ways in which the system may not work properly.
Typical conditions to try include division by zero, blank (or no) input, empty files and the wrong kind of data (e.g. alphabetic characters where numeric are required). If anyone ever says of a system or the environment in which it is to operate ‘That could never happen’, it might be a good idea to test that condition, as such assumptions about what will and will not happen in the live environment are often the cause of failures.
A structured approach to the error-guessing technique is to list possible defects or failures and to design tests that attempt to produce them. These defect and failure lists can be built based on the tester’s own experience or that of other people, available defect, and failure data, and from common knowledge about why software fails.