A black box testing is a software testing technique where the internal structure, internal design, coding, functions, and modules are kept isolated and the tester only applies the test case into the interface of the software and compare the actual output with the expected one.
The main advantage of this testing is that no expertise in programming is required to carry out this test. The main aim of this test is to detect incorrect functions, errors in interface, performance issues, initialization or termination errors.
In may be noted that, this testing may be done both for non-functional and functional requirements.
A simple kind of black box testing would be the software being run inside the ATM machine. The user simply performs all the functions provided by the ATM and sees for the flaws. Or maybe an internet browser, which can be used directly by a user and result is in front of our eyes.
It is important to note that, this testing is only intended to perform in these three levels of software testing, viz- Integration testing, System testing, and Acceptance testing.
In the equivalence class partitioning techniques, the input values are divided into a set of partitions. And this is done by choosing the different boundaries, and when we choose data from a class which belongs to the same partition, it says whether the set we have chosen is valid nor not.
In the equivalence class partitioning technique, we are concerned about the classes of input values and are laying emphasis on the valid and the invalid partitions as well, which is not the case in the boundary value analysis where we are only concerned about the boundary values.
The importance of equivalence class partitioning technique is that it can be clearly seen which set of values are going to provide us a wrong result and that can be added to the list of the expected result.
Let us see the below example:
Let the input values are partitioned as 10 to 20. and 40 to 60.
Now we make different can be classified as:
-- to 9 Invalid.
10 to 20 Valid.
21 to 39 Invalid.
40 to 60 Valid
61 to --- Invalid
Now we may select values from each class:
In this software testing techniques, we take values that create a boundary to the input which has to be input to the software. In this testing technique, we create values which are at the boundary between the partitions. Its values may include the maximum, minimum or outside the boundaries.
It also contains the typical values, complicated boundary value and also the error values. This technique is designed as it is seen how most of the error is occurring at the boundary values of the defined input values. The value which is at the center is not causing an error to that extent.
This software testing technique not only helps to check the boundary values but also helps us to see whether the software performs when any overlapped modules perform on the same values which are overlapping.
Software testing technique is the opposite of the equivalence class partitioning testing technique. Let us see the steps to be followed for using this software testing technique:
Below is an example:
This is a software testing technique, which is used to generate the test case itself. It does this by studying the input and the corresponding output, which is expected. This process produces a Cause-Effect Graph and generates test case accordingly.
Below is a diagram which shows how the Cause-Effect Graphing :
Cause-effect testing is fully based on the idea that almost all the functionalities along with the statement coverage should be carried out with the usage of the minimal test cases.
Since the goal is to use a minimal number of test cases, therefore the situations or cases are to be arranged logically, so that an output effect can be determined.
Let us take an example:
Suppose, for a customer verification you are supposed to enter three different types of credentials username, password or phone-no.
Now in this situation, the password is mandatory and either username or the phone-no should be entered along with the password to log in to the user session.
Situations or causes:
Analysis of the cause-effect:
Now, in this case, the conditions are, that either of the causes C1 or the C2 should be true. But as seen here in C1, there are two credentials namely: username and password. And in the C2, there are two credentials namely: phone-no and password.
Now, these criteria can be fulfilled by using an OR logic in the C1 with C2.
The OR logic, in this case, implies that satisfying either C1 or C2 cause will make the E1 as true (that is, the user will be able to login into the user session).
It should be noted that not only the OR logic but there can be a complicated combination of causes, which to make effect true may use complicated logic.
Some frequently used logics are: NOT, OR, X-OR and X-NOR. The cause-effect may sometime become more complicated to be expressed in terms of Boolean Expression.
This can be understood graphically below.
As shown in the above picture, C1 is the resultant of a AND logic and C2 is also the results of a AND logic. Therefore, the OR gate finally decides which combination is finally suitable and thus results in the effect.
This software testing technique is used in the case of the functions where the functions respond or work for the combination of inputs and do not depend on the single input. This software testing technique is useful when there are function works on complicated inputs.
For example, The Finish button will be activated only when all the credentials will be types into the boxes. As shown in the diagram.
As shown in the figure above, we have seen that the validate function came TRUE only when all the required inputs have satisfied all the Rules mentioned.
It may be noted that for every function, this decision table has to be created and all the rules must be checked before it can be concluded that whether the function should respond or not. The first task is to identify all the combinations of the inputs when the function should respond.
For every function, we should create a table for all the individual function and see the response of the function.
The steps to be followed while creating the decision table:
State transition technique is used when the input may be changed to see the API behavior. The state transition is used to when it is required to test a sequence of events occurring in the software.
State transition technique must be used when the tester wants to test the software for a limited set of input values.
Let us see an example:
If a user enters valid credentials in any of the five attempts, the user will be able to sign in or log in. Here, we have seen that the user is trying for the first attempt if he/she is failing, the next session is started and the user may apply again with the credentials.
In case, the user fails again, then the user is prompted to make the third attempts. It goes on up to the fifth attempt. And here if the user is not entering valid credentials into the software, then the user is barred to access the Log-in API for a limited time.
And also in some cases, the user may be requested to reset the user credentials or maybe only the password, in case of some highly secured software.
Let us see a practical example with a state tradition diagram:
As shown the above example, the user is given two chances after entering the incorrect PIN and on the third chance, if the PIN is entered incorrectly then the account is blocked for some time or the software may request the user to reset the user PIN or any credentials to be able to log in again.
Error guessing is a software testing technique, which is solely based on guessing the error.
This technique is used when the tester is much more expect or the software is of the organic type, that is similar kind of software and the related test is performed earlier by the tester and so the tester knows the possible error.
This type of technique is used when there is no time to apply the boundary value analysis or the equivalence class partitioning.
For the application of this kind of technique, the tester must have the following qualities:
In the black box testing, the output is tested for the corresponding input to the software. In this testing, the tester is unaware of the internal structure, codes, and architecture of the software and only the tester is concerned about the features and functionalities which are visible to the users.
In this testing, the tester may use the software's API, hardware interface or the software's interface itself to test the software. This testing is real-world oriented testing, in which the test cases are generated as per the users mentally of using the software and are mostly based on human psychology of users.
Black box testing can be carried out to test functional as well as non-functional requirements of the software. This testing can be performed with the test case and the testing manual and less professional tester can also carry out this kind of test with ease.