Black box testing
Black box testing is a technique of software testing by examining its functionality without peering into internal structure or coding of the software. The basic sources of black box testing are specifications and requirements for that software.
In this method, tester takes a function and check its functionality by giving it input and check whether it is giving expected output or not. If the function is producing the correct output, then it is passed in testing otherwise, failed. Testing team inform result to the development team and then test next function. After completing all functions if there are severe problems, then it is given back to the development team for correction.
Generic steps of black box testing
Test procedure in Black box testing
The procedure in black box testing is the process in which tester should have the specific knowledge what the software is supposed to do and design test cases according to the functionality of the software. It's not necessary to have programming knowledge of the software. All test cases are designed by considering the input and output of a particular function.
A tester is aware of the certain output of particular input but not aware of how it is producing the result. Decision table technique, boundary value analysis technique, state transition, All-pair testing, cause-effect graph technique , equivalence partitioning technique, error guessing technique, use case technique, and user story technique are the various techniques used in black box testing. All explained in detail in this tutorial.
Test cases in Black box testing
Test cases are constructed with consideration of specifications and requirements. These are generally yielded from working descriptions of the software including requirements, design parameters, and specifications. For the testing, the test designer selects both positive test scenario by taking valid input values and adverse test scenario by taking invalid input values to determine the correct output. Test cases are mainly designed for functional testing but can also be used for non-functional testing. Test cases are designed by the testing team there is not any involvement of the development team of software.
Decision table technique in Black box testing
The decision table is also known as a cause-effect table. It is one of the widely used black box test design technique. These are used to pick the test cases in a systematic manner. This technique saves the testing time and gives good test coverage.
Decision table technique is appropriate for functionalities which has logical relationships between inputs. This technique deals with the combination of inputs. To design the test cases with decision table, we need to consider conditions as inputs and actions as outputs.
Let's understand it by an example:
Most people use an email account, so when you want to access the email account, first you need to specify email ID and password. If both email and password are matched correctly, then it will be redirected to email account homepage otherwise, turned back on login page with error message incorrect. So, let's see how can make a decision table for email and password, where email and password both are conditions and expected result is action.
To find the number of all possible conditions, multiply the number of values of the first condition (which is 2 one is true and second is false) with a number of values of the second condition (which is 2 one is true and second is false)
Number of possible conditions = Number of Values of the first condition* Number of Values of the second condition
By using decision table, a tester already knows what result will be given by the function in particular condition if it does not do the same so, it is failed and informed to the development team.
Boundary value analysis in Black box testing
Boundary value analysis is also known as BVA. It is one of the widely used black box test design technique. It is based on testing the boundary values by making valid and invalid partitions. This technique is mainly used for the functions that use the maximum and minimum value like somewhere age is required between 18 to 40 another example account balance for particular account minimum must be 1000 and maximum 20000 and so on. Let's understand via example.
Imagine there is a function which accepts a number between 18 to 30. There is 18 minimum partition value, and 30 is maximum partition value and partition between 18 to 30 like 19, 20, 21, 22, 23, 24, 25, 26, 27, 28 and 29 is a valid partition.
All the numbers less than 18 like 17, 16, 15, 14........ And so on and the numbers more than 30 like 31, 32, 33, 34, 35, 36, 37 And so on both build an invalid partition.
On testing valid partition output must be according to expectation means it should accept the valid numbers and on testing invalid portion, it must not accept the invalid numbers.
If it is doing according to partitions then passed in testing otherwise in adverse condition sent to the development team.
State transition in Black box testing
This technique is used in applications that give the different result as output for the same input depending on what has happened in earlier statements. This is applicable in those types of applications which provide more than one attempt such as login page of an application which locks username after three wrong attempts for example; in mobile, we use the password it gives a particular number of attempts after crossing highest number of attempts it gets locked with an error message.
Let see in the diagram:
There's login page of an application which provides a maximum of three attempts, and after three attempts, it will redirect to an error page.
State transition table
In the above state transition table, we can see state S1 is for first login attempt. When it is invalid, it redirected to the second attempt means state S2. If the second attempt is also invalid, then it is redirected to S3. Now if this third and last attempt is valid so, it will be redirected to S4 which is homepage state, but if it is invalid, it will also be redirected to the error page.
Let's see state transition table if third attempt is valid:
We can see in the above state transition table the third attempt is valid so, it is redirected to the homepage (S4).
All-pairs testing in Black box testing
All-pairs testing technique is also known as pairwise testing. It is used to test all the possible discrete combinations of values. This Combinational method is used for testing the application that uses checkbox input, radio button input (radio button is used when you have to select only one option such as when you select gender male or female so, you can select only one option), list box, text box, etc.
Suppose, if there a piece of software to test which has ten fields to input data, then there are total 10^10 (10000000000) possible discrete combinations for input, but it is complicated to test all the combinations because it will be much time-consuming. So, let us understand how it can be tested with an example:
Assume there is an application with list box which contains 10 elements along with text box (It can accept 1 to 100 characters), radio button, checkbox and OK button.
There are the values which each GUI object (Textbox, list box, checkbox, the radio button is GUI objects) can accept:
So, the total number of test cases including negative cases will be 4000
Now to test the 4000 positive and negative test case is a very lengthy and time-consuming process so, the task is to bring down the number of test cases. To do that we can consider list box values first one is 0 and the second one is other neither positive nor negative so, total 2 values for the list. Values of checkbox and radio button cannot be reduced because each one has the only combination of 2 values. The last value of the text box can be divided into three input categories valid integer, invalid integer, and alpha-special character.
We have the total number of test cases including negative test cases is
Now, the task is to make combinations into all pair technique in which each column must have an equal number of values, and total values must be equal to 24.
To make textbox column put the most common input on first place. It is valid integer second least common is an invalid integer, and last is AlphaSpecialCharacter.
Then start filling column by column. The first column is a text box which has three values, and the next column is list box which contains 2 values.
The third column is a checkbox which has 2 values, and the last one is a radio button with two values.
We can see in table conventional software method gives a result only in 24 test cases of 4000 cases, and pairwise testing method gives result in just 6 pair test cases.
Cause and effect graph inBlack box testing
Cause and effect graph testing technique is a test case writing technique which is used to write test cases dynamically. In this technique, the input conditions are referred to as causes and effects as a result of those input conditions.
Cause-Effect graph testing technique based on a collection of requirements and used to determine minimum possible test cases which can cover a maximum test area of the software.
The main advantage of cause-effect graph testing is, it reduces the time of test execution and cost.
The aim of this technique is to reduce the number of test cases but still covering all necessary test cases with maximum coverage to achieve the desired application quality.
Cause-Effect graph testing technique converts the requirements specification into a logical relationship between the input and output conditions by using logical operators like AND, OR and NOT.
Notations used in the Cause-Effect graph
AND - E1 is effect and C1, C2 are causes. If both causes C1 and C2 are true, then effect E1 will be true.
OR - If anyone cause from C1 and C2 is true, then effect E1 will be true.
NOT - If cause C1 is false, then effect E1 will be true.
Mutually Exclusive - When only one of the causes is true.
Let's try to understand this technique with some examples:
The character in a column 1 must be an alphabet A or B. A character in column 2 must be a digit. If both columns contain appropriate values then update is made. If the entry in column 1 is incorrect means not A or B, then message X will be displayed. If the entry in column 2 is incorrect means not digit, then message Y will be displayed.
First, we are going to make Cause-Effect graph for the above situation:
Where AND, OR, NOT are logical gates.
Effect E1- Update made- The logic for effect E1 is (C1 OR C2) AND C3 that means for C1 OR C2 either C1 or C2 should be true (Character in column 1 can either be A (cause C1) or B (cause C2)) and for logic AND C3 (Character in column 2 should be a digit), C3 must be true so, effect E1 (Update made) can exist. We can see in graph cause C1 and C2 are connected through, OR logic and effect E1 is connected with AND logic.
Effect E2 - Message X displayed - The logic for effect E2 is NOT C1 AND NOT C2 that means both C1 (Character in column 1 should be A) and C2 (Character in column 1 should be B) should be not true. In other words, character in column 1 is not either A or B then effect E2 can exist. We can see in graph C1, OR C2 is connected through NOT logic with effect E2.
Effect E3 - Message Y displayed- The logic for effect E3 is NOT C3 that means cause C3 (Character in column 2 is a digit) should not be true. In other words, character in column 2 should not be a digit so; effect E3 can exist. We can see in graph C3 is connected through NOT logic with effect E3.
So, it is the cause-effect graph for the given situation. A tester needs to convert causes and effects into logical statements and then design cause-effect graph. If function gives output (effect) according to input (cause) so, it is defect free, and if not doing so, then it is sent to the development team for the correction of the defect.
Summarizing the steps:
Equivalence partitioning inBlack box testing
Equivalence class partitioning or Equivalence partitioning is a technique of software testing in which input data divided into partitions and it is mandatory that all partitions must exhibit the same behavior. If a condition in one partition is true so, it must be true in another equal partition, and if a condition in one partition is false so, it must be false in another equal partition. The principal of Equivalence partitioning is test cases should be designed to cover each partition at least once. Each value of every equal partition must work same as other.
The equivalence partitions are derived from requirements and specifications of the software. The advantage of this approach of software testing it helps to reduce the time of testing due to a smaller number of test cases from infinite to finite. It is applicable at all levels of testing.
For example, assume an application unit that accepts a particular number of digit not greater than and not less than that particular number like an OTP number which accepts only six digits less than and more than six digits will not be accepted and the application will redirect to the error page.
Let's see one more example
A particular function of an application accepts a mobile number of 10 digits.
In the above examples, we can see that there is a partition of two equally valid and invalid parts. On applying valid value, both valid portions behave same such as redirect to the next page.
In the above example, there is a valid value of 6 digits in the first example and of 10 digits in the second example.
Another two partitions are of invalid values. On applying invalid values, both invalid portions behave same like redirect to the error page on applying the invalid value of 5 or less than 5 and of 7 or more than 7 digits in the first example and of 9 or less than 9 and 11 or more than 11 digits in the second example.
Equivalence partitioning reduces the number of test cases, as we can see there are only three test cases for each example in place of that if test cases like that use all 10 digits number, more than 10 digits number and less than 10 digits number so, test cases will be infinite but in this technique test cases are finite and even much less than expectations.
Error guessing in Black box testing
Error guessing is a technique which does not have any particular method to identify the error. It is based on the experience of the test analyst where tester uses the experience to guess the problematic areas of the software.
Error guessing is a type of black box testing technique which does not have any defined structure to find the error.
How is the Error guessing technique implemented?
The implementation of this technique depends on the experience of the tester or analyst having prior experience with similar applications. It requires only well-experienced testers with quick error guessing technique. This technique is used to find errors that may not be easily captured by formal black box testing techniques, and that is the reason, it is done after all formal techniques.
The scope of error guessing technique would totally depend upon the tester and kind of experience in the past testing involvements because it does not follow any method and rules.
Test cases are prepared by the analyst to identify conditions; probably the conditions can give error test cases are designed for them.
The main purpose of this technique is to identify common errors at any level of testing like:
The increment of test cases depends upon the ability of tester and his/her experience.
Purpose of Error guessing
On the basis of intuition and experience of the tester, all defects cannot be corrected.
There are some factors that can be used by the tester to use his/her experience are as follows-
Example of Error guessing
A function of an application requires mobile number which must be of 10 characters.
Now, below are the techniques that can be applied to guess error for mobile number field:
After applying these techniques if the output is the same as expected result so consider that the particular function is bug-free but if the output is not according to the expected result, so it is sent to the development team.
Though, Error guessing is the key technique out of all testing techniques as it depends on the experience of a tester so, there is no surety of highest quality benchmark. It does not provide full coverage to the software. This technique can yield a better result if combined with other techniques of testing.
The use case in Black box testing
The use case is functional testing of black box testing used to identify test cases according to the use of the system from start to end. By using this technique, the test team makes a test scenario that can exercise the whole software on the basis of the functionality of each function from start to end. In this scenario, there is an actor who represents user to use the functions of a system one by one.
It describes the functionality of the application step by step. We can easily understand it with an example, assume there is an application of online money transfer transaction so, what can be the various steps:
If the system is following all steps successfully so, no need to design a test case for this function.
By describing steps of using the application, it is easy to design test cases for the system or software.
So, this is all about use case testing.