Black Box Testing-1
Black Box Testing-1
Black Box Testing-1
Black box testing is a technique of software testing which examines the functionality of
software without peering into its internal structure or coding. The primary source of black
box testing is a specification of requirements that is stated by the customer.
In this method, tester selects a function and gives input value to examine its functionality,
and checks whether the function is giving expected output or not. If the function produces
correct output, then it is passed in testing, otherwise failed. The test team reports the result
to the development team and then tests the next function. After completing testing of all
functions if there are severe problems, then it is given back to the development team for
correction.
Test procedure
The test procedure of black box testing is a kind of process in which the tester has
specific knowledge about the software's work, and it develops test cases to check the
accuracy of the software's functionality.
It does not require programming knowledge of the software. All test cases are designed by
considering the input and output of a particular function.A tester knows about the definite
output of a particular input, but not about how the result is arising. There are various
techniques used in black box testing for testing like 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. All these techniques have been explained in detail within the tutorial.
Test cases
Test cases are created considering the specification of the requirements. These test cases
are generally created from working descriptions of the software including requirements,
design parameters, and other 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.
State Transition State Transition Technique is used to capture the behavior of the
Technique software application when different input values are given to the
same function. This applies to those types of applications that
provide the specific number of attempts to access the application.
All-pair Testing All-pair testing Technique is used to test all the possible discrete
Technique combinations of values. This combinational method is used for
testing the application that uses checkbox input, radio button
input, list box, text box, etc.
Use Case Use case Technique used to identify the test cases from the
Technique beginning to the end of the system as per the usage of the system.
By using this technique, the test team creates a test scenario that
can exercise the entire software based on the functionality of each
function from start to end.
Boundary value analysis is one of the widely used case design technique for black box
testing. It is used to test boundary values because the input values near the boundary have
higher chances of error.
Whenever we do the testing by boundary value analysis, the tester focuses on, while
entering boundary value whether the software is producing correct output or not.
Boundary values are those that contain the upper and lower limit of a variable. Assume that,
age is a variable of any function, and its minimum value is 18 and the maximum value is 30,
both 18 and 30 will be considered as boundary values.
The basic assumption of boundary value analysis is, the test cases that are created using
boundary values are most likely to cause an error.
There is 18 and 30 are the boundary values that's why tester pays more attention to these
values, but this doesn't mean that the middle values like 19, 20, 21, 27, 29 are ignored. Test
cases are developed for each and every value of the range.
Testing of boundary values is done by making valid and invalid partitions. Invalid partitions
are tested because testing of output in adverse condition is also essential.
Imagine, there is a function that accepts a number between 18 to 30, where 18 is the
minimum and 30 is the maximum value of valid partition, the other values of this partition
are 19, 20, 21, 22, 23, 24, 25, 26, 27, 28 and 29. The invalid partition consists of the numbers
which are less than 18 such as 12, 14, 15, 16 and 17, and more than 30 such as 31, 32, 34,
36 and 40. Tester develops test cases for both valid and invalid partitions to capture the
behavior of the system on different input conditions.
The software system will be passed in the test if it accepts a valid number and gives the
desired output, if it is not, then it is unsuccessful. In another scenario, the software system
should not accept invalid numbers, and if the entered number is invalid, then it should
display error massage.
If the software which is under test, follows all the testing guidelines and specifications then
it is sent to the releasing team otherwise to the development team to fix the defects.
Equivalence Partitioning Technique
Equivalence partitioning is a technique of software testing in which input data is divided into
partitions of valid and invalid values, and it is mandatory that all partitions must exhibit the
same behavior. If a condition of one partition is true, then the condition of another equal
partition must also be true, and if a condition of one partition is false, then the condition of
another equal partition must also be false. The principle of equivalence partitioning is, test
cases should be designed to cover each partition at least once. Each value of every equal
partition must exhibit the same behavior as other.
The equivalence partitions are derived from requirements and specifications of the
software. The advantage of this approach is, 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 the testing
process.
Assume that there is a function of a software application that accepts a particular number of
digits, not greater and less than that particular number. For example, an OTP number which
contains only six digits, less or more than six digits will not be accepted, and the application
will redirect the user to the error page.
In both examples, we can see that there is a partition of two equally valid and invalid
partitions, on applying valid value such as OTP of six digits in the first example and mobile
number of 10 digits in the second example, both valid partitions behave same, i.e.
redirected to the next page.
Another two partitions contain invalid values such as 5 or less than 5 and 7 or more than 7
digits in the first example and 9 or less than 9 and 11 or more than 11 digits in the second
example, and on applying these invalid values, both invalid partitions behave same, i.e.
redirected to the error page.
We can see in the example, there are only three test cases for each example and that is also
the principal of equivalence partitioning which states that this method intended to reduce
the number of test cases.
Condition1
If the requirement is a range of values, then derive the test case for one valid and two
invalid inputs.
Here, the Range of values implies that whenever we want to identify the range values, we
go for equivalence partitioning to achieve the minimum test coverage. And after that, we go
for error guessing to achieve maximum test coverage.
According to pressman:
For example, the Amount of test field accepts a Range (100-400) of values:
Whenever the requirement is Range + criteria, then divide the Range into the internals and
check for all these values.
For example:
In the below image, the pressman technique is enough to test for an age text field for one
valid and two invalids. But, if we have the condition for insurance of ten years and above
are required and multiple policies for various age groups in the age text field, then we need
to use the practice method.
Condition2
If the requirement is a set of values, then derive the test case for one valid and two
invalid inputs.
Here, Set of values implies that whenever we have to test a set of values, we go for one
positive and two negative inputs, then we moved for error guessing, and we also need to
verify that all the sets of values are as per the requirement.
Example 1
Example 2
if we are doing online shopping, mobile phone product, and the different Product ID -
1,4,7,9
And if we give the product id as 4, it will be accepted, and it is one valid value, and if we
provide the product id as 5 and phone cover, it will not be accepted as per the requirement,
and these are the two invalid values.
Condition 3
If the requirement id Boolean (true/false), then derive the test case for both true/false
values.
The Boolean value can be true and false for the radio button, checkboxes.
For example
Note:
Here, we are testing the application by deriving the below inputs values:
When the pressman technique is used, the first two conditions are tested, but if we use the
practice method, all three conditions are covered.
We don't need to use the practice approach for all applications. Sometime we will use the
pressman method also.
But, if the application has much precision, then we go for the practice method.
If we want to use the practice method, it should follow the below aspects:
o It should be product-specific
o It should be case-specific
o The number of divisions depends on the precision( 2% and 3 %
Advantages Disadvantages
We can achieve the Minimum test This technique will not consider the condition for
coverage boundary value analysis.
It helps to decrease the general The test engineer might assume that the output
test execution time and also for all data set is right, which leads to the
reduce the set of test data. problem during the testing process.
Cause-effect graph comes under the black box testing technique which underlines the
relationship between a given result and all the factors affecting the result. It is used to write
dynamic test cases.
The dynamic test cases are used when code works dynamically based on user input. For
example, while using email account, on entering valid email, the system accepts it but,
when you enter invalid email, it throws an error message. In this technique, the input
conditions are assigned with causes and the result of these input conditions with effects.
The main advantage of cause-effect graph testing is, it reduces the time of test execution
and cost.
This technique aims to reduce the number of test cases but still covers all necessary test
cases with maximum coverage to achieve the desired application quality.
AND - E1 is an effect and C1 and C2 are the causes. If both C1 and C2 are true, then effect E1
will be true.
The character in column 1 should be either A or B and in the column 2 should be a digit. If
both columns contain appropriate values then update is made. If the input of column 1 is
incorrect, i.e. neither A nor B, then message X will be displayed. If the input in column 2 is
incorrect, i.e. input is not a digit, then message Y will be displayed.
o A file must be updated, if the character in the first column is either "A" or "B" and in
the second column it should be a digit.
o If the value in the first column is incorrect (the character is neither A nor B) then
massage X will be displayed.
o If the value in the second column is incorrect (the character is not a digit)
then massage Y will be displayed.
Now, we are going to make a Cause-Effect graph for the above situation:
Causes are:
o C1 - Character in column 1 is A
o C2 - Character in column 1 is B
o C3 - Character in column 2 is digit!
Effects:
Effect E2 - Displays Massage X - The logic for the existence of 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 false. In other words, for the existence of effect E2 the character in
column 1 should not be either A or B. We can see in the graph, C1 OR C2 is connected
through NOT logic with effect E2.
Effect E3 - Displays Massage Y- The logic for the existence of effect E3 is "NOT C3" that
means cause C3 (Character in column 2 is a digit) should be false. In other words, for the
existence of effect E3, the character in column 2 should not be a digit. We can see in the
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 the input (cause) so, it is considered as defect free, and if not doing so,
then it is sent to the development team for the correction.
Conclusion
Decision table technique is one of the widely used case design techniques for black box
testing. This is a systematic approach where various input combinations and their respective
system behavior are captured in a tabular form.
That's why it is also known as a cause-effect table. This technique is used to pick the test
cases in a systematic manner; it saves the testing time and gives good coverage to the
testing area of the software application.
Decision table technique is appropriate for the functions that have a logical relationship
between two and more than two inputs.
This technique is related to the correct combination of inputs and determines the result of
various combinations of input. To design the test cases by decision table technique, we need
to consider conditions as input and actions as output.
Most of us use an email account, and when you want to use an email account, for this you
need to enter the email and its associated password.
If both email and password are correctly matched, the user will be directed to the email
account's homepage; otherwise, it will come back to the login page with an error message
specified with "Incorrect Email" or "Incorrect Password."
Now, let's see how a decision table is created for the login function in which we can log in by
using email and password. Both the email and the password are the conditions, and the
expected result is action.
In the table, there are four conditions or test cases to test the login function. In the first
condition if both email and password are correct, then the user should be directed to
account's Homepage.
In the second condition if the email is correct, but the password is incorrect then the
function should display Incorrect Password. In the third condition if the email is incorrect,
but the password is correct, then it should display Incorrect Email.
Now, in fourth and last condition both email and password are incorrect then the
function should display Incorrect Email.
In this example, all possible conditions or test cases have been included, and in the
same way, the testing team also includes all possible test cases so that upcoming
bugs can be cured at testing level.
In order to find the number of all possible conditions, tester uses 2n formula where n
denotes the number of inputs; in the example there is the number of inputs is 2 (one is
true and second is false).
While using the decision table technique, a tester determines the expected output,
if the function produces expected output, then it is passed in testing, and if not
then it is failed. Failed software is sent back to the development team to fix the
defect.