In functional testing the structure of the program is not considered. Test cases are decided solely on the basis of requirements or specifications of the program or module, and the internals of the module or the program are not considered for selection of test cases.
Due to its nature, functional testing is often called black box testing. The basic for deciding test cases in functional testing is the requirements or specifications of the system or module.
For the entire system, the test cases are designed from the requirement specification document for the system. For modules created during design, test cases for functional testing are decided from the module specifications product during the design. There are no formal rules for designing test cases for functional testing. In fact, there are no precise criteria for selecting test cases. However, there are a number of techniques or heuristics that can be used to select test cases that have been found to be very successful in detecting errors.
We’ll be covering the following topics in this tutorial:
Equivalence Class Partitioning
Because we cannot do exhaustive testing, the next natural approach is to divide the domain of all the inputs into a set of equivalence classes, so that if any test in an equivalence class succeeds, then every test in that class will succeed. That is, we want to identify classes of test cases such that the success of one test case in a class implies the success of others. However, without looking at the internal structure of the program, it is impossible to determine such ideal equivalence classes.
The equivalence class partitioning method tries to approximate this ideal. Different equivalences classes are formed by putting inputs for which the behavior pattern of the module is specified to be different into similar groups and then regarding these new classes as forming equivalence classes. The rationale of forming equivalence classes like this is the assumption that if the specifications require exactly the same behavior for each element in a class of values, then the program is likely to be constructed so that it either succeeds or fails for each of the values in that class.
Boundary value analysis
Test cases that have values on the boundaries of equivalence classes are therefore likely to be high yield test cases, and selecting such test cases is the aim of the boundary value analysis. 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.
Boundary values for each equivalence class, including the equivalence classes of the output, should be covered. Boundary value test cases are also called extreme cases. Hence, we can say that a boundary value test case is a set of input data that lies on the edge or boundary of a class of input data or that generates output that lies at the boundary of a class of output data. One way to exercise combinations of different input conditions is to consider all valid combinations of the equivalence classes of input conditions. This simple approach will result in a usually large number of test cases, many of which will not be useful for revealing any new errors.
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 does not become unmanageably large. The technique starts with identifying causes and effect of the system under testing. A cause is a distinct input condition and an effect is a distinct output condition. Each condition forms a node in the cause-effect graph.
The condition should be stated such that they can be set to either true or false. After identifying the causes and effects, for each effect we identify the causes that can produce that effect and how the conditions have to be combined to make the effect true. Conditions are combined using the Boolean operators and or and not which are represented in the graph by & ! and ~.
Then for each effect, all combination of the causes that the effect depends on which will make the effect true, are generated. By doing this, we identify the combinations of conditions that make different effects true. A test case is then generated for each combination of conditions, which make some effect true.