Software Testing and Quality Assurance

Theory and Practice

Chapter 9
Functional Testing

Software Testing and QA Theory and Practice (Chapter 9: Functional Testing) © Naik & Tripathy 1
 Outline of the Chapter
• Equivalence Class Partitioning
• Guidelines for Equivalence Class Partitioning
• Identification of Test Cases
• Advantages of Equivalence Class Partitioning
• Boundary Value Analysis (BVA)
• Guidelines for Boundary Value Analysis
• Decision Tables

Software Testing and QA Theory and Practice (Chapter 9: Functional Testing) © Naik & Tripathy 2
 Equivalence Class Partitioning
• An input domain may be too large for all its elements to be used as test input
(Figure 9.8(a))
• The input domain is partitioned into a finite number of subdomains
• Each subdomain is known as an equivalence class, and it serves as a source of at
least one test input (Figure 9.8(b))
• A valid input to a system is an element of the input domain that is expected to
return a non error value
• An invalid input is an input that is expected to return an error value.

Figure 9.8: (a) Too many test input; (b) One input is selected from each of the subdomain

Software Testing and QA Theory and Practice (Chapter 9: Functional Testing) © Naik & Tripathy 3
 Guidelines for Equivalence Class Partitioning
• An input condition specifies a range [a, b]
– one equivalence class for a < X < b, and
– two other classes for X < a and X > b to test the system with invalid inputs
• An input condition specifies a set of values
– one equivalence class for each element of the set {M1}, {M2}, ...., {MN}, and
– one equivalence class for elements outside the set {M1,M2, ...,MN}
• Input condition specifies for each individual value
– If the system handles each valid input differently then create one equivalence
class for each valid input
• An input condition specifies the number of valid values (Say N)
– Create one equivalence class for the correct number of inputs
– two equivalence classes for invalid inputs – one for zero values and one for
more than N values
• An input condition specifies a “must be” value
– Create one equivalence class for a “must be” value, and
– one equivalence class for something that is not a “must be” value

Software Testing and QA Theory and Practice (Chapter 9: Functional Testing) © Naik & Tripathy 4
 Identification of Test Cases
Test cases for each equivalence class can be identified by:

• Assign a unique number to each equivalence class

• For each equivalence class with valid input that has not been covered
by test cases yet, write a new test case covering as many uncovered
equivalence classes as possible

• For each equivalence class with invalid input that has not been
covered by test cases, write a new test case that covers one and only
one of the uncovered equivalence classes

Software Testing and QA Theory and Practice (Chapter 9: Functional Testing) © Naik & Tripathy 5
 Advantages of Equivalence Class Partitioning
• A small number of test cases are needed to adequately cover a large
input domain

• One gets a better idea about the input domain being covered with the
selected test cases

• The probability of uncovering defects with the selected test cases

based on equivalence class partitioning is higher than that with a
randomly chosen test suite of the same size

• The equivalence class partitioning approach is not restricted to input

conditions alone – the technique may also be used for output
domains

Software Testing and QA Theory and Practice (Chapter 9: Functional Testing) © Naik & Tripathy 6
 Example
• Example: Adjusted Gross Income. Consider a software system that
computes income tax based on adjusted gross income (AGI)
according to the following rules:
• If AGI is between $1 and $29,500, the tax due is 22% of AGI.
• If AGI is between $29,501 and $58,500, the tax due is 27% of AGI.
• If AGI is between $58,501 and $100 billion, the tax due is 36% of
AGI.

Software Testing and QA Theory and Practice (Chapter 9: Functional Testing) © Naik & Tripathy 7
 Example
1. $1 ≤ AGI ≤ $29,500.
2. $29,501 ≤ AGI ≤ $58,500.
3. $58,501 ≤ AGI ≤ $100 billion.
•First we consider condition 1, namely, $1 ≤ AGI ≤ $29,500, to derive
two ECs:
EC1: $1 ≤ AGI ≤ $29,500; valid input.
EC2: AGI < 1; invalid input.
•Then, we consider condition 2, namely, $29,501 ≤ AGI ≤ $58,500, to
derive one EC:
•EC3: $29,501 ≤ AGI ≤ $58,500; valid input.

Software Testing and QA Theory and Practice (Chapter 9: Functional Testing) © Naik & Tripathy 8
• Finally, we consider condition 3, namely, $58,501 ≤ AGI ≤ $100
billion, to derive two ECs:
• EC4: $58,501 ≤ AGI ≤ $100 billion; valid input.
• EC5: AGI > $100 billion; invalid input.

Note that each condition was considered separately in the derivation of

ECs.
• Conditions are not combined to select ECs. Five test cases are
generated to cover the five ECs,

Software Testing and QA Theory and Practice (Chapter 9: Functional Testing) © Naik & Tripathy 9
 Boundary Value Analysis (BVA)
• The central idea in Boundary Value Analysis (BVA) is to select test
data near the boundary of a data domain so that data both within and
outside an equivalence class are selected

• The BVA technique is an extension and refinement of the

equivalence class partitioning technique

• In the BVA technique, the boundary conditions for each of the

equivalence class are analyzed in order generate test cases

Software Testing and QA Theory and Practice (Chapter 9: Functional Testing) © Naik & Tripathy 10
 Guidelines for Boundary Value Analysis
• The equivalence class specifies a range
– If an equivalence class specifies a range of values, then construct test cases by
considering the boundary points of the range and points just beyond the
boundaries of the range

• The equivalence class specifies a number of values

– If an equivalence class specifies a number of values, then construct test cases
for the minimum and the maximum value of the number
– In addition, select a value smaller than the minimum and a value larger than
the maximum value.

• The equivalence class specifies an ordered set

– If the equivalence class specifies an ordered set, such as a linear list, table, or a
sequential file, then focus attention on the first and last elements of the set.

Software Testing and QA Theory and Practice (Chapter 9: Functional Testing) © Naik & Tripathy 11
 Example

Software Testing and QA Theory and Practice (Chapter 9: Functional Testing) © Naik & Tripathy
13
 Decision Tables
• The structure of a decision table has been shown in Table 9.13
• It comprises a set of conditions (or, causes) and a set of effects (or, results)
arranged in the form of a column on the left of the table
• In the second column, next to each condition, we have its possible values: Yes (Y),
No (N), and Don’t Care (“-”)
• To the right of the “Values” column, we have a set of rules. For each combination
of the three conditions {C1,C2,C3}, there exists a rule from the set {R1,R2, ..,R8}
• Each rule comprises a Yes (Y), No (N), or Don’t Care (“-”) response, and contains
an associated list of effects {E1,E2,E3}
• For each relevant effect, an effect sequence number specifies the order in which
the effect should be carried out, if the associated set of conditions are satisfied
• The “Checksum” is used for verification of the combinations, the decision table
represent
• Each rule of a decision table represents a test case

Software Testing and QA Theory and Practice (Chapter 9: Functional Testing) © Naik & Tripathy 14
 Decision Tables

Software Testing and QA Theory and Practice (Chapter 9: Functional Testing) © Naik & Tripathy 15
 Decision Tables
The steps in developing test cases using decision table technique:
• Step 1: The test designer needs to identify the conditions and the
effects for each specification unit.
– A condition is a distinct input condition or an equivalence class of input
conditions
– An effect is an output condition. Determine the logical relationship between
the conditions and the effects
• Step 2: List all the conditions and effects in the form of a decision
table. Write down the values the condition can take
• Step 3: Calculate the number of possible combinations. It is equal to
the number of different values raised to the power of the number of
conditions

Software Testing and QA Theory and Practice (Chapter 9: Functional Testing) © Naik & Tripathy 16
 Decision Tables
• Step 4: Fill the columns with all possible combinations – each column
corresponds to one combination of values. For each row (condition) do the
following:
– Determine the Repeating Factor (RF): divide the remaining number of combinations by
the number of possible values for that condition
– Write RF times the first value, then RF times the next and so forth, until row is full
• Step 5: Reduce combinations (rules). Find indifferent combinations - place a “-”
and join column where columns are identical. While doing this, ensure that effects
are the same
• Step 6: Check covered combinations (rules). For each column calculate the
combinations it represents. A “-” represents as many combinations as the condition
has. Multiply for each “-” down the column. Add up total and compare with step 3.
It should be the same
• Step 7: Add effects to the column of the decision table. Read column by column
and determine the effects. If more than one effect can occur in a single
combinations, then assign a sequence number to the effects, thereby specifying the
order in which the effects should be performed. Check the consistency of the
decision table
• Step 8: The columns in the decision table are transformed into test cases
Software Testing and QA Theory and Practice (Chapter 9: Functional Testing) © Naik & Tripathy 17
 Decision Table
• Create a decision table for the following program in an office email
system, Send email when Recipient address present, subject present,
before 5:30pm
• If after 5:30pm then put in pending folder
• If Recipient address missing or subject message, give warning
message
 Example solution

Rules

Address
Y Y N N
Present
It is same as
Conditio Subject above and
ns Present considered as
one condition
Before
Y N Y N
5:30
Send
X
Mail
Error
Actions X
Message
Make X
pending
 Example
• A technical support company writes a decision table to diagnose
printer problems based upon symptoms described to them over the
phone from their clients. They type the following data into the advice
program:
• Printer does print
• Red light is not flashing
• Printer is recognized
• The program then uses the decision table to find the correct actions
to perform, namely that of Check / Replace ink.
 Solution

Rules
Conditions Printer does not print Y Y Y Y N N N N
A red light is flashing Y Y N N Y Y N N
Printer is un-recognized Y N Y N Y N Y N
Check the power cable X
Effects Check the printer-computer cable X
Ensure printer software is installed X X X X
Check/replace ink X X X X

Check for paper jam X X X