Programming Software Quality Assurance

Functional Testing

Sumit Dhameliya
sdhameliya@conestogac.on.
ca
Course Outline

 7.1:
Describe the principles and the role of
functional testing in a development project

 7.2:
Apply functional testing techniques using
boundary condition analysis, decision tables,
and/or randomized testing as applicable
Outline

 Overview of functional testing and test vectors

 Equivalence classes

 Boundary value analysis

 Overview of decision tables

Functional Testing
 Basic
idea: we test a program unit strictly on the basis of
analyzing the program outputs based on the values of its inputs

 Testingwhere the functionalities of a software are tested by

giving different inputs

 Functional testing involves:

 Identifying how a functionality is expected to behave
 Creating input data to check the functionality, based on the software's
requirements
 Executing the prepared test cases
 Comparing actual results with the expected results
Test Vectors

A test vector is an instance of an input to a

program
 a.k.a. test data
 Ifa program has N input variables, each of which
can take on k special values, then there are kN
possible combinations of test vectors
 We have more than one million test vectors even
for k = 3 and N = 20
 Hence, we must identify a method for reducing the
number of test vectors
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
Partitioning Inputs by
Equivalence Classes

Figure 9.8: (a) Too many test inputs; (b) One input is selected from each of the
subdomains
Test Cases and Equivalence
Classes
 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
Advantages of Equivalence
Classes
 A small number of test cases are needed to cover a large input
domain adequately

 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
Boundary Analysis and Ranges
 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

 For
example, we may construct test cases for values that have
one of the following:
 Minimum value
 Just above the minimum value
 Maximum value
 Just below the maximum value
 Nominal (average) value
Robustness Testing
 Robustness testing is an extension to boundary value analysis

 Systematically test the program with both valid and invalid values,
either singly or in combination

 For numeric values, we may have any of:

 Minimum value
 Just above the minimum value
 Just below the minimum value
 Just above the maximum value
 Just below the maximum value
 Maximum value
 Nominal value
BVA and Other Data Types
 Boundary value analysis works with ordered types
 Integer, fixed decimal, date, time, timestamps

 Does not work well with approximate numeric types

 Float or double
 Problem – the accuracy of the result is not guaranteed

 Does not work well with unordered sets of values

 What does boundary value analysis mean for string values?
 Enumerated types?
 Complex objects?
About Decision Tables

 Decision
tables provide a systematic way to define a
number of different complex business rules

 Createa set of possible results from a number different

inputs and what the possible outcomes are

 Help
to define what would be the best cases to test, as
sometimes the number of combinations can be huge

 Follows a logical method of creating a decision table

About Decision Tables
(continued)
A decision table is typically used in functional testing,
particularly when there are many possible combinations to test
with multiple actions to take
 In practice, this means the program has a variety of nested IF-ELSE IF-
ELSE conditions

A decision table comprises a set of conditions (causes) and a

set of effects or actions (results) arranged in columns on the
left of the table
 Columns describing actions are known as "Events" or "Rules"
 The set of actions in a specific column are sometimes referred to as
"Action Sets"
Decision Table Example
Decision Table Definitions
 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}

 Eachrule comprises a Yes (Y), No (N), or Don't Care ("-")

response, and contains an associated list of effects {E1, E2,
E3}, which are sometimes also termed actions

A "checksum" is used for verification of the combinations the

decision table represent

 Each event, or rule, of a decision table represents a potential

test case
Example

 CUSTOMER
 If the customer is a new customer, offer 20% discount on
next order
 If the customer is a repeat customer, offer free shipping

 RISK LEVEL OF GOODS

 If the risk level of goods is high, then:
▪ If the customer is a new customer, check their credit record
▪ If the customer is a repeat customer, then:
▪ If the past orders total > $350, no further action
▪ Otherwise check their credit record
Example Decision Table

Stub Entry
New Customer T T T T F F F F
High risk level
T T F F T T F F
of goods
Past orders total
> 350 T F T F T F T F

20% discount
next order X X X X

Free shipping X X X X
Check credit
X X X
history
Limited Entry and Extended Decision
Tables
 In
the second column, next to each condition, we have each
column's possible values

 In
a limited entry decision table, conditions are binary values
restricted to "True" or "False."
 These are sometimes replaced by the values Yes (Y) and No (N)

 In
an extended entry decision table, a condition may have many
possible values

 Actionswithin an action set may be numbered when it is

essential to recognize the ordering of specific actions
Example Extended Decision Table

Stub Entry
Customer Type New Customer Repeat Customer
Conditio

Risk level of goods High Risk Low Risk High Risk Low Risk
n

Past orders total > <=35 > <= > <= > <=
350 0 350 350 350 350 350 350
20% discount next
order X X X X
Action

Free shipping X X X X
Check credit
X X X
history
Action
Sets
Example Decision Table – Adding Don't
Cares

Stub Entry
Customer Type New Customer Repeat Customer
Conditio

Risk level of goods High Risk Low Risk High Risk Low Risk
n

Past orders total > <=

- - - - - -
350 350
20% discount next
order X X X X
Action

Free shipping X X X X
Check credit
X X X
history

The "-" indicates a "don't care" condition that does not affect any of the
documented actions.
Steps in Developing a Decision Table
for Testing
 Step1: 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

 Step2: 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

Steps in Developing a Decision Table
for Testing (continued)
 Step
4: Fill the columns with all possible
combinations – each column corresponds to one
combination of values.

 Step 5: Reduce the number of combinations (rules).

 Find different combinations: place a "-" (don't care) and
join those columns where the semantics are identical.
 While doing this, ensure that all actions (effects) are the
same
Steps in Developing a Decision Table
for Testing (continued)
 Step6: Add actions to the column of the decision table.
Go through the table column by column and determine
the actions
 If more than one action can occur in a single combination,
then assign a sequence number to the actions, thereby
specifying the order in which the actions should be performed
 Check the consistency of the decision table

 Step7: The columns in the decision table are

transformed into test cases
Decision Table  Test Cases
 Build test cases on inputs (actions) and outputs
Test ID(results)
Test Steps Expected Outcome

1 As a new customer that purchases a Verify that the customer is provided with
high risk level of goods, regardless of a 20% discount on the next order and a
past order total check of their credit history is
performed.
2 As a new customer that purchases a Verify that the customer is provided with
low risk level of goods, regardless of a 20% discount on the next order only.
past order total
3 As a repeat customer that purchases a Verify that the customer is provided with
high risk level of goods, with a past free shipping only.
order total of $351
4 As a repeat customer that purchases a Verify that the customer is provided with
high risk level of goods, with a past free shipping and a check of their credit
order total of $350 history is performed.
Questions?