SOFTWARE

TESTING
(EQUIVALENCE CLASS
PARTITIONING)
Rizwan Khalid
 OUTLINE
 Equivalence Classes
 Testing By Contract
 Defensive testing
 Types of Equivalence Classes
 Continuous Equivalence Class
 Discrete Equivalence Class
 Single Selection Equivalence Class
 Multiple Selection Equivalence Class
 Testing Valid vs Invalid Data
 Applicability and Limitations
 Examples
 Grocery Store
 Banking Problem 2
 Next Date Problem
EQUIVALENCE CLASSES
SCENARIO

How would you program?

APPROACH 1
APPROACH 2
EQUIVALENCE CLASS
 An equivalence class consists of a set of data that is treated the same by the module or
that should produce the same result.
WE EXPECT THE
PROGRAMMER WILL DO THIS
EQUIVALENCE CLASS
DESIGN BY CONTRACT : OOP
APPROACH
 In the design-by-contract approach, modules (called "methods" in the object-oriented
paradigm, but "module" is a more generic term) are defined in terms of pre-conditions
and post-conditions.
 Post-conditions define what a module promises to do (compute a value, open a file,
print a
 report, update a database record, change the state of the system, etc.).
 Pre-conditions define what that module requires so that it can meet its post-conditions.

 For example, if we had a module called openFile, what does it promise to do? Open a
file. What would legitimate preconditions of openFile be? First, the file must exist;
second, we must provide the name (or other identifying information) of the file; third,
the file must be "openable," that is, it cannot already be exclusively opened by another
process; fourth, we must have access rights to the file; and so on.
 Pre-conditions and postconditions establish a contract between a module and others
that invoke it.
TESTING BY CONTRACT
 Testing-by-contract is based on the design-by-contract philosophy.

 Its approach is to create test cases only for the situations in which the pre-conditions
are met.
 For example, we would not test the openFile module when the file did not exist.

 The reason is simple. If the file does not exist, openFile does not promise to work.

 If there is no claim that it will work under a specific condition, there is no need to test
under that condition.

 At this point testers usually protest.

 Yes, they agree, the module does not claim to work in that case, but what if the
preconditions are violated during production? What does the system do?
 Do we get a misspelled word on the screen or a smoking crater where our company
used to be?
DEFENSIVE DESIGN
 A different approach to design is defensive design.

 In this case the module is designed to accept any input.

 If the normal preconditions are met, the module will achieve its normal postconditions.

 If the normal pre-conditions are not met, the module will notify the caller by returning an
error code or throwing an exception (depending on the programming language used).
This notification is actually another one of the module's postconditions.
 Based on this approach we could define defensive testing: an approach that tests under
both normal and abnormal pre-conditions.
TYPES OF EQUIVALENCE
CLASSES
 Different types of input require different types of equivalence classes.
 Let's consider four possibilities.
 Continuous Equivalence Class
 Discrete Equivalence Class
 Single Selection Equivalence Class
 Multiple Selection Equivalence Class

 Let's assume a defensive testing philosophy of testing both valid and invalid
input.

 Testing invalid inputs is often a great source of defects.

CONTINUOUS EQUIVALENCE
CLASS
 If an input is a continuous range of values, then there is typically one class of valid
values and two classes of invalid values, one below the valid class and one above it.
 Consider the Goofy Mortgage Company (GMC):
 They will write mortgages for people with incomes between $1,000/month and
$83,333/month.
 Anything below $1,000/month you don't qualify.
 Anything over $83,333/month you don't need GMC, just pay cash.
 For a valid input we might choose $1,342/month. For invalids we might choose
$123/month and $90,000/month.
 DISCRETE EQUIVALENCE
 CLASS
If an input condition takes on discrete values within a range of permissible values,
there are typically one valid and two invalid classes.
 GMC will write a single mortgage for one through five houses.
 Zero or fewer houses is not a legitimate input,
 Nor is six or greater.
 Neither are fractional or decimal values such as 2 1/2 or 3.14159.
 For a valid input we might choose two houses.
 Invalids could be -2 and 8.
SINGLE SELECTION
EQUIVALENCE CLASS


GMC will make mortgages only for a person.
They will not make mortgages for corporations, trusts, partnerships, or any other type
of legal entity.
 For a valid input we must use "person."
 For an invalid we could choose "corporation" or "trust" or any other random text string.
 How many invalid cases should we create? We must have at least one; we may
choose additional tests for additional warm and fuzzy feelings.
 MULTIPLE SELECTION
 EQUIVALENCE CLASS
GMC will make mortgages on Condominiums, Townhouses, and Single Family
dwellings.
 They will not make mortgages on Duplexes, Mobile Homes, Treehouses, or any other
type of dwelling.
 For valid input we must choose from "Condominium," "Townhouse," or "Single Family."
 While the rule says choose one test case from the valid equivalence class, a more
comprehensive approach would be to create test cases for each entry in the valid
class.
 That makes sense when the list of valid values is small.
TESTING VALID DATA
 Now, rarely will we have the time to create individual tests for every separate
equivalence class of every input value that enters our system.
 More often, we will create test cases that test a number of input fields simultaneously.
For example, we might create a single test case with the following combination of
inputs:

 Each of these data values is in the valid range, so we would expect the system to
perform correctly and for the test case to report Pass.
TESTING INVALID DATA
 It is tempting to use the same approach for invalid values.
 If the system accepts this input as valid, clearly the system is not validating the four
input fields properly.
 If the system rejects this input as invalid, it may do so in such a way that the tester
cannot determine which field it rejected.
TESTING VALID VS INVALID
DATA
 In many cases, errors in one input field may cancel out or mask errors in another field
so the system accepts the data as valid.
 A better approach is to test one invalid value at a time to verify the system detects it
correctly.
TESTING VALID VS INVALID
DATA (CONTD.)
 Another approach to using equivalence classes is to examine the outputs rather than
the inputs.
 Divide the outputs into equivalence classes, then determine what input values would
cause those outputs.
 This has the advantage of guiding the tester to examine, and thus test, every different
kind of output.
 But this approach can be deceiving. ??????
TO DEFINE EQUIVALENCE CLASSES
FOLLOW THE GUIDELINE
1. If an input condition specifies a range, one valid and two invalid
equivalence classes are defined.
2. If an input condition requires a specific value, one valid and two invalid
equivalence classes are defined.
3. If an input condition is Boolean, one valid and one invalid class are
defined.
TEST CASES FOR INPUT BOX ACCEPTING
NUMBERS BETWEEN 1 AND 1000 USING
EQUIVALENCE PARTITIONING
 One input data class with all valid inputs. Pick a single value from range 1 to 1000
 Input data class with all values below lower limit. I.e. any value below 1, as a invalid input
data test case
 Input data with any value greater than 1000 to represent third invalid input class.
APPLICABILITY AND
LIMITATIONS
 Equivalence class testing can significantly reduce the number of test cases
that must be created and executed.
 It is most suited to systems in which much of the input data takes on values
within ranges or within sets.
 It makes the assumption that data in the same equivalence class is, in fact,
processed in the same way by the system.
 The simplest way to validate this assumption is to ask the programmer about
their implementation.
 Equivalence class testing is equally applicable at the unit, integration, system,
and acceptance test levels.
 All it requires are inputs or outputs that can be partitioned based on the
system’s requirements.
TEST CASE OF GROCERY
STORE APPLICATION
Consider a software module that is intended to accept the name
of a grocery item and a list of the different sizes the item comes
in, specified in ounces. The specifications state that the item
name is to be alphabetic characters 2 to 15 characters in length.
Each size may be a value in the range of 1 to 48, whole
numbers only. The sizes are to be entered in ascending order
(smaller sizes first). A maximum of five sizes may be entered
for each item. The item name is to be entered first, followed by
a comma, then followed by a list of sizes. A comma will be
used to separate each size. Spaces (blanks) are to be ignored
anywhere in the input.
 Derived Equivalence Classes
1. Item name is alphabetic (valid)
2. Item name is not alphabetic (invalid)
3. Item name is less than 2 characters in length (invalid)
4. Item name is 2 to 15 characters in length (valid)
5. Item name is greater than 15 characters in length (invalid)
6. Size value is less than 1 (invalid)
7. Size value is in the range 1 to 48 (valid)
8. Size value is greater than 48 (invalid)
9. Size value is a whole number (valid)
10.Size value is a decimal (invalid)
11.Size value is numeric (valid)
12.Size value includes nonnumeric characters (invalid)
13.Size values entered in ascending order (valid)
14.Size values entered in nonascending order (invalid)
15.No size values entered (invalid)
16.One to five size values entered (valid)
17.More than five sizes entered (invalid)
18.Item name is first (valid)
19.Item name is not first (invalid)
20.A single comma separates each entry in list (valid)
21.A comma does not separate two or more entries in the list (invalid)
22.The entry contains no blanks (???)
23.The entry contains blanks (????)
 Test Data Expected Outcome Classes Covered

xy,1 T 1,4,7,9,11,13,16,18,20,22
AbcDefghijklmno,1,2,3 ,4,48 T 1,4,7,9,11,13,16,18,20,23
a2x,1 F 2
A,1 F 3
Abcdefghijklmnop F 5
Xy,0 F 6
XY,49 F 8
Xy,2.5 F 10
xy,2,1,3,4,5 F 14
Xy F 15
XY,1,2,3,4,5,6 F 17
1,Xy,2,3,4,5 F 19
XY2,3,4,5,6 F 21
AB,2#7 F 12
BANKING PROBLEM BY
USING ECP TECHNIQUES
 A savings account in a bank has a different rate of interest depending on the
balance in the account. In order to test the software that calculates the interest
due, identify the ranges of balance values that earn the different rates of
interest. For example, 3% rate of interest is given if the balance in the account
is in the range of $0 to $100, 5% rate of interest is given if the balance in the
account is in the range of $100 to $1000, and 7% rate of interest is given if the
balance in the account is $1000 and above.
Id Input Expected output Actual output
1 -5 NA
2 50 3%
3 150 5%
4 1050 7%
5 -1 NA
6 0 3%
7 1 3%
8 99 3%
9 100 --
10 101 5%
11 999 5%
12 1000 --
13 1001 7%
TEST CASES FOR BANKING
PROBLEM
Id Input Expected output Actual output status
1 -1 Invalid
2 50 3%
3 150 5%
4 1100 7%

SO THE CONCLUSION IS : IN CASE OF REPETITION, YOU HAVE TO

DELETE THE DUPLICATIONS OF TEST CASES.
NEXT DATE PROBLEM USING
ECP TECHNIQUES
Input Classes Output Classes
 Day:  Increment Day
 D1: day between 1 to 28  Reset Day and Increment Month
 D2: 29
 Increment year
 D3: 30
 D4: 31
 Invalid Month

 Month:
 M1: Month has 30 days
 M2: Month has 31 days
 M3: Month is February

 Year:
 Y1: Year is a leap year
 Y2: Year is a normal year
NEXT DATE PROBLEM USING
ECP TECHNIQUES
How many tests are
required to check full
spectrum ???
 NEXT DATE PROBLEM USING
ECP TECHNIQUES
Test Case ID Day Month Year Expected Output Test Case ID Day Month Year Expected Output

E1 15 4 2004 16-4-2004 E13 30 4 2004 1-5-2004

E2 15 4 2003 16-4-2003 E14 30 4 2003 1-5-2003

E3 15 1 2004 16-1-2004 E15 30 1 2004 31-1-2004

E4 15 1 2003 16-1-2003 E16 30 1 2003 31-1-2003

E5 15 2 2004 16-2-2004 E17 30 2 2004 Invalid Date

E6 15 2 2003 16-2-2003 E18 30 2 2003 Invalid Date

E7 29 4 2004 30-4-2004 E19 31 4 2004 Invalid Date

E20 31 4 2003 Invalid Date

E8 29 4 2003 30-4-2003

E21 31 1 2004 1-2-2004

E9 29 1 2004 30-1-2004
E22 31 1 2003 1-5-2003
E10 29 1 2003 30-1-2003
E23 31 2 2004 Invalid Date
E11 29 2 2004 1-3-2004
E24 31 2 2003 Invalid Date
E12 29 2 2003 Invalid Date
THANK YOU