Functional Testing

Functional testing techniques attempt to design those test cases which have a higher probability of making a
software fail. These techniques also attempt to test every possible functionality of the software. Test cases are
designed on the basis of functionality and the internal structure of the program is completely ignored. The
software is treated as a black box and therefore, it is also known as black box testing. The test cases are
designed on the basis of user requirements without considering the internal structure of the program. This
black box knowledge is sufficient to design a good number of test cases.

BOUNDARY VALUE ANALYSIS

Experience has shown that such test cases have a higher probability of detecting a fault in the software. In
boundary value analysis, we select values on or close to boundaries and all input values may have one of the
following:

(i) Minimum value

(ii) Just above minimum value

(iii) Maximum value

(iv) Just below maximum value

(v) Nominal (Average) value

The number of inputs selected by this technique is 4n + 1 where ‘n’ is the number of inputs. We also consider
‘single fault’ assumption theory of reliability which says that failures are rarely the result of the simultaneous
occurrence of two (or more) faults. Normally, one fault is responsible for one failure.

Robustness Testing

This is the extension of boundary value analysis. Here, we also select invalid values and see the responses of
the program. Invalid values are also important to check the behaviour of the program. Hence, two additional
states are added i.e. just below minimum value (minimum value –) and just above maximum value (maximum
value +).Thus, the total test cases in robustness testing are 6n + 1, where ‘n’ is the number of input values.

Worst-Case Testing

This is a special form of boundary value analysis where we don’t consider the ‘single fault’ assumption theory
of reliability. Now, failures are also due to occurrence of more than one fault simultaneously. This will increase
the number of test cases from 4n + 1 test cases to 5n test cases, where ‘n’ is the number of input values.

Robust Worst-Case Testing

In robustness testing, we add two more states i.e. just below minimum value (minimum value–) and just above
maximum value (maximum value+). We also give invalid inputs and observe the behaviour of the program. A
program should be able to handle invalid input values, otherwise it may fail and give unexpected output values.
There are seven states (minimum -, minimum, minimum +, nominal, maximum –, maximum, maximum +) and a
total of 7n test cases will be generated.

Applicability

Boundary value analysis is a simple technique and may prove to be effective when used correctly. Here, input
values should be independent which restricts its applicability in many programs. This technique does not make
sense for Boolean variables where input values are TRUE and FALSE only, and no choice is available for nominal
values, just above boundary values, just below boundary values, etc. This technique can significantly reduce the
number of test cases and is suited to programs in which input values are within ranges or within sets.

EQUIVALENCE CLASS TESTING

A large number of test cases are generated for any program. It is neither feasible nor desirable to execute all
such test cases. We may divide input domain into various categories with some relationship and expect that
every test case from a category exhibits the same behaviour. If categories are well selected, we may assume
that if one representative test case works correctly, others may also give the same results. This assumption
allows us to select exactly one test case from each category and if there are four categories, four test cases may
be selected. Each category is called an equivalence class and this type of testing is known as equivalence class
testing.

Creation of Equivalence Classes

The entire input domain can be divided into at least two equivalence classes: one containing all valid inputs
and the other containing all invalid inputs. Each equivalence class can further be sub-divided into equivalence
classes on which the program is required to behave differently.

Applicability

It is applicable at unit, integration, system and acceptance test levels. The basic requirement is that inputs or
outputs must be partitioned based on the requirements and every partition will give a test case. The design of
equivalence classes is subjective and two testing persons may design two different sets of partitions of input
and output domains.

DECISION TABLE BASED TESTING

An output may be dependent on many input conditions and decision tables give a pictorial view of various
combinations of input conditions.

Parts of the Decision Table

The four parts of the decision table are given as:

Condition Stubs: All the conditions are represented in this upper left section of the decision table. These
conditions are used to determine a particular action or set of actions.

Action Stubs: All possible actions are listed in this lower left portion of the decision table.

Condition Entries: In the condition entries portion of the decision table, we have a number of columns and
each column represents a rule. Values entered in this upper right portion of the table are known as inputs.

Action Entries: Each entry in the action entries portion has some associated action or set of actions in this
lower right portion of the table. These values are known as outputs and are dependent upon the functionality
of the program.

Limited Entry and Extended Entry Decision Tables

Decision table testing technique is used to design a complete set of test cases without using the internal
structure of the program. The decision tables which use only binary conditions are known as limited entry
decision tables. The decision tables which use multiple conditions where a condition may have many
possibilities instead of only ‘true’ and ‘false’ are known as extended entry decision tables.

‘Do Not Care’ Conditions and Rule Count

The ‘do not care’ conditions are represented by the ‘-‘sign. A ‘do not care’ condition has no effect on the
output. This is nothing but a representation facility in the decision table to reduce the number of columns and
avoid redundancy. Ideally, each column has one rule and that leads to a test case. The term ‘rule count’ is used
with ‘do not care’ entries in the decision table and has a value 1, if ‘do not care’ conditions are not there, but it
doubles for every ‘do not care’ entry.

Rule count can be calculated as:

Rule count = 2 number of do not care conditions

This is applicable only for limited entry decision tables where only ‘true’ and ‘false’ conditions are considered.
Hence, the actual number of columns in any decision table is the sum of the rule counts of every column
shown in the decision table.

Impossible Conditions

Some impossible conditions are also generated due to combinations of various inputs and an ‘impossible’
action is incorporated in the ‘action stub’ to show such a condition. We may have to redesign the input classes
to reduce the impossible actions. Redundancy and inconsistency may create problems but may be reduced by
proper designing of input classes depending upon the functionality of a program.

Applicability

Decision tables are popular in circumstances where an output is dependent on many conditions and a large
number of decisions are required to be taken. They may also incorporate complex business rules and use them
to design test cases. Every column of the decision table generates a test case. As the size of the program
increases, handling of decision tables becomes difficult and cumbersome. In practice, they can be applied
easily at unit level only. System testing and integration testing may not find its effective applications.

CAUSE-EFFECT GRAPHING TECHNIQUE

This technique is a popular technique for small programs and considers the combinations of various inputs
which were not available in earlier discussed techniques like boundary value analysis and equivalence class
testing. Two new terms are used here and these are causes and effects, which are nothing but inputs and
outputs respectively.

Identification of Causes and Effects

The SRS document is used for the identification of causes and effects. Causes which are inputs to the program
and effects which are outputs of the program can easily be identified after reading the SRS document. A list is
prepared for all causes and effects.

Design of Cause-Effect Graph

The relationship amongst causes and effects are established using cause-effect graph. The basic notations of
the graph are shown

Use of Constraints in Cause-Effect Graph

There may be a number of causes (inputs) in any program. We may like to explore the relationships amongst
the causes and this process may lead to some impossible combinations of causes.

The purpose of all five constraint symbols is given as:

(a) Exclusive: The Exclusive (E) constraint states that at most one of c1 or c2 can be 1 (c1 or c2 cannot be 1
simultaneously). However, both c1 and c2 can be 0 simultaneously.

(b) Inclusive: The Inclusive (I) constraints states that at least one of c1 or c2 must always be 1. Hence, both
cannot be 0 simultaneously. However, both can be 1.

(c) One and Only One: The one and only one (O) constraint states that one and only one of c1 and c2 must be
1.

(d) Requires: The requires (R) constraint states that for c1 to be 1, c2 must be 1; it is impossible for c1 to be 1 if
c2 is 0.

(e) Mask: This constraint is applicable at the effect side of the cause-effect graph. This states that if effect e1 is
1, effect e2 is forced to be 0.

Consider the example of keeping the record of marital status and number of children of a citizen. The value of
marital status must be ‘U’ or ‘M’. The value of the number of children must be digit or null in case a citizen is
unmarried. If the information entered by the user is correct then an update is made. If the value of marital
status of the citizen is incorrect, then the error message 1 is issued. Similarly, if the value of number of children
is incorrect, then the error message 2 is issued.

The causes are:

c1: marital status is ‘U’

c2: marital status is ‘M’

c3: number of children is a digit

and the effects are:

e1: updation made

e2: error message 1 is issued

e3: error message 2 is issued

Design of Limited Entry Decision Table

The cause-effect graph represents the relationships amongst the causes and effects. This graph may also help
us to understand the various conditions/combinations amongst the causes and effects. These
conditions/combinations are converted into the limited entry decision table. Each column of the table
represents a test case.

Writing of Test Cases

Each column of the decision table represents a rule and gives us a test case. We may reduce the number of
columns with the proper selection of various conditions and expected actions.

Applicability

This technique is effective only for small programs because, as the size of the program increases, the number of
causes and effects also increases and thus complexity of the causeeffect graph increases. For large-sized
programs, a tool may help us to design the cause-effect graph with the minimum possible complexity.