Black-Box Test Techniques — Software
There are three general test technique categories outlined by the International Software Testing Qualification Board(ISTQB), white-box test techniques, black-box test techniques, and experienced-based test techniques. Here we focus on the black-box test techniques.
The main idea behind black-box test techniques is that you test a software feature without seeing its code. Test cases are driven directly from the specification or other models that specify what the system should do. It is an analysis of the outputs based on the inputs, not the inner workings of the system.
Equivalence Partitioning
It is one of the black-box techniques. We can partition both our inputs and outputs.
Input Partitions
Valid inputs partition:
One of the seven testing principles is that exhaustive testing is not possible. For example, in a calculator app, one feature of a calculator app is that it takes positive, negative, and floating point numbers. To test this feature we cannot input all the positive, negative, and floating point numbers that are out there. All we have to test here is one number from every group or partition, to see if our app meets the specification. Any one positive number, a negative number, and a floating point number.
Invalid inputs partition:
For our example’s sake let’s assume that beside the input field there is a separate field for operators, so our input field only takes numbers. The partitions we identified above were all the valid inputs that the app should/could accept. For the invalid partition, however, we pass values that the app is not supposed to accept. For example, on a keyboard, besides the numbers we have two more categories of keys — the alphabets and the special characters. We pass one value from each of these groups/partitions and test if our calculator meets the specification by rejecting them as an input.
Output Partitions
Just as we can test the valid and invalid inputs in our program, we can also partition our expected output values in the same manner and test our application.
Boundary Value Analysis
One of the common mistakes with loops in code is that our loops end up off by one repetition. It is usually because logical operators operate on the boundary values. We know that errors cluster around these values.
For example, let’s assume our calculator app has only 9 digit screen space for output, if the output is greater than eight digits, the last digit of our calculator should display a “-”, representing that there are other hidden digits to the number. And if it is shorter than 9 digits it should not display a “-” and istead should display the complete number. If it is equal to 9 digits it should display the complete number. As you can see it can get tricky around the number 9 and this is exactly why errors cluster around boundaries. Testing for these boundary values is a must in situations like this.
The rule for boundary values is to test values as close to the boundary as possible. In the example above we will test for an 8 digit output, a 9 digit output, and a 10 digit output.
Decision Table Testing
Product specifications often contain business rules that then define system functions. The same rules may also specify conditions under which each function operates. It is important to assure ourselves that every combination of these conditions are tested.
The formula for having the total number of possible conditions is the number of states raised to the number of conditions. For example if we have three conditions each having two states, true and false, we get 2³. Look at the following example, we assume a cash transferring feature that has three conditions and each of those conditions could be either true or false at a time. Following are the eight different cases and decisions based on their combinations.
State Transition Diagram
Decision table was possible when conditions had fixed values. For example, in the table above each condition could either be true or false, it could only have either of the two states as an input at a time.
In scenarios where conditions (state) keep changing and the application has to behave accordingly, we utilize a state transition diagram.
In the diagram above the state of our ATM usage process changes. After the card is inserted, on the first try the system has to decide based on a correct or an incorrect pin and an accumulation of one try. On the second try, the system’s state changes, now it has to decide based on a correct or an incorrect pin, and an accumulation of two tries. For the last one, a correct or an incorrect try and one last try before the ATM eats the card. The orange boxes show the changing states of the system.
Use Case Testing
Use case captures the individual interaction between the user and the system. A user could be a particular type of user and the use case captures the interactions that each user takes part in to produce some output that is of value.
For example, an admin account holder uploads documents to a portal and a user account holder should be able to read or download those documents. We can test both use cases by developing test cases. Test cases could be based on any of the other techniques we have used. That is: we prioritize, test typical examples, then attempt some in correct process flows, exercise the boundaries, and so on.