Black Box Test Design Techniques are widely used as a best practice in the industry. Black box test design techniques are used to pick the test cases in a systematic manner. By using these techniques we could save lots of testing time and get the good test coverage.
Note: Knowledge on the internal structure (code) of the AUT (Application Under Test) is not necessary to use these black box test design techniques.
These test design techniques are used to derive the test cases from the Requirement Specification document and also based on testers expertise:
Check the below video to watch “Black Box Test Design Techniques”
Please be patient. The video will load in some time.
Let’s see each technique in detail.
It is also known as Equivalence Class Partitioning (ECP).
Using equivalence partitioning test design technique, we divide the test conditions into class (group). From each group we do test only one condition. Assumption is that all the conditions in one group works in the same manner. If a condition from a group works then all of the conditions from that group work and vice versa. It reduces lots of rework and also gives the good test coverage. We could save lots of time by reducing total number of test cases that must be developed.
For example: A field should accept numeric value. In this case, we split the test conditions as Enter numeric value, Enter alpha numeric value, Enter Alphabets, and so on. Instead of testing numeric values such as 0, 1, 2, 3, and so on.
Click here to see a detailed post on Equivalence Class Partitioning .
Using Boundary value analysis (BVA), we take the test conditions as partitions and design the test cases by getting the boundary values of the partition. The boundary between two partitions is the place where the behavior of the application varies. The test conditions on either side of the boundary are called boundary values. In this we have to get both valid boundaries (from the valid partitions) and invalid boundaries (from the invalid partitions).
For example: If we want to test a field which should accept only amount more than 10 and less than 20 then we take the boundaries as 10-1, 10, 10+1, 20-1, 20, 20+1. Instead of using lots of test data, we just use 9, 10, 11, 19, 20 and 21.
Click here to see a detailed post on Boundary Value Analysis .
Decision Table is aka Cause-Effect Table. 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.
Click here to see a detailed post on Decision Table .
Using state transition testing, we pick test cases from an application where we need to test different system transitions. We can apply this when an application gives a different output for the same input, depending on what has happened in the earlier state.
Some examples are Vending Machine, Traffic Lights.
Vending machine dispenses products when the proper combination of coins is deposited.
Traffic Lights will change sequence when cars are moving / waiting
Click here to see a detailed post on State Transition Testing .
Usually this process will be carried out by domain experts. They perform testing just by exploring the functionalities of the application without having the knowledge of the requirements.
Whilst using this technique, testers could explore and learn the system. High severity bugs are found very quickly in this type of testing.
Error guessing is one of the testing techniques used to find bugs in a software application based on tester’s prior experience. In Error guessing we don’t follow any specific rules.
Some of the examples are: