Black box testing & its techniques

What is Black box testing ?

• Black box testing is a method of software testing that examines the functionality of an application without peering into its internal structures or workings.
• In black-box testing, the tester does not know the internal structure of the module, he tests only for input/output behavior.
• It enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program.
• The selection of test cases is based on the specification of the test object without knowledge of its inner structure.
• It is also very important to design the test cases that demonstrate the behavior of the test object on erroneous input data.
• The black box testing is also known by the name of functional testing, exterior testing, specification testing, data-driven testing, and input/output-driven testing.

Advantages of black-box testing:

The test is unbiased.
From the point of view of the user the test is complete, but not from the point of the designer.
Test cases can be designed as soon as the specification is complete.

Disadvantages of black-box testing:

If the software designer has already run a test case, the test can be redundant.
The test cases are difficult to design.

Different techniques used in black-box testing

Following are the techniques that uses for black-box testing:

A. Equivalence class partitioning:

1. The equivalence class partitioning is a method that divides the input data of a software unit into partitions of equivalence classes from which test cases can be derived.
2. Equivalence classes are usually formed for input domains and are classified into a valid equivalence class and one or more invalid equivalence classes.
3. The idea is to partition the input domain of the system into a finite number of equivalence classes such that each member of the class would behave in a similar fashion.
4. The techniques increase the efficiency of software testing as the numbers of input states are drastically reduces.
5. This technique involves two steps
   i. Identification of equivalence classes.
   ii. Generating the test cases.

B. Boundary value analysis:

1. Boundary value analysis is a technique in which tests are design to include representatives of boundary values in a range.
2. In boundary value analysis, we choose an input for a test case from an equivalence class, such that the input lies at the edge of the equivalence classes.
3. Boundary values for each equivalence class, including the equivalence classes of the output, should be covered.
4. Boundary value test cases are also says “extreme cases”.
5. A boundary value test case is a set of input data that lies on the edge of the boundary of a class of input data or that generates output that lies at the boundary of a class of output data.
6. Guidelines for boundary value analysis are:
   i. If an input condition specifies a range bounded by values a and b, test cases should be designed with the values a and b and just above and just below a and b.
   ii. If an input condition specifies the number of the input value, test cases should be developed that exercise the minimum and maximum number. Values that are just above and just below minimum values and maximum values are also testing.

C. Cause-effect graphing:

1. Cause-effect graphing is a technique that aids in selecting combinations of input conditions in a systematic way, such that the number of test cases do not become unmanageably large.
2. This technique starts with identifying the causes and effects of the system under testing.
3. A cause is a distinct input condition, and an effect is a distinct output condition.
4. The conditions that are in the cause-effect graph forms a node.
5. The condition should be stated such that they can be set to either true or false.
   
   The steps of cause-effect testing are as follows:
   1. For a model, identify input conditions (causes) and actions (effect).
   2. Develop a cause-effect graph.
   3. The effect-cause graph can be transform into a decision table.
   4. Convert decision table rules to test cases. Each column of the decision table are using to represents a test case.

Read more about Software Quality Assurance & its lifecycle