INTRODUCTION

Software Testing incorporates a primary part of software development life cycle. It

is a mechanism that helps to expose errors and therefore plays a crucial role in
developing any software product. Lack of appropriate testing can result in several
software related problems which can lead to various financial and social crisis.
Despite all the efforts people put in the quality of the software, effectiveness of
testing remains lower than expectations. But it does not mean that we can deliver an
unsatisfactorily tested software. Rather, testing should be done until the product
becomes valid and verifiable. Verification ensures that the system entirely works
according to the specification and simultaneously validation ensures whether the
software works according to the customers’ expectations and requirements.
Although it is expected that the software product delivered by the software developer
must be reliable but many errors and bugs are resolved only after performing proper
testing techniques. Testing takes both time and resource while developing a product
but only after that we can ensure to develop a good software product. The purpose
of testing is to crash the software and then identify errors in it and remove them.

There are different types of testing techniques and to identify which testing
technique to use and at which phase of software development life cycle we must
evaluate them thoroughly before categorizing them in any particular hierarchy.
Therefore, it is very crucial to have a detailed research of testing approach we want
to implement in our software product.

Software Testing can be broadly categorized in two basic approaches which are
functional testing and structural testing. In Functional Testing also known as Black
Box technique, the test cases are designed on the basis of specifications of the
software product only. It means the tester is not concerned with the internal
implementation of the software. On the other hand, Structural Testing also known
as White Box technique consider the internal structure of the software to design the
test cases. Both these methodologies are essential to software testing.

In this report, we have analyzed Equivalence Class Partitioning (ECP or EP) which
falls under the category of Black Box testing techniques.
 Equivalence Class Partitioning
It is a type of Black Box testing technique in which the input domain of the program
is divided into different classes known as Equivalence classes. It is a better testing
technique than exhaustive testing which comprises of all combination inputs
possible in a system and is highly impractical. Here the challenge for the tester is to
design a minimal test suite that can reveal all the possible bugs and errors in the
software. There are broadly two approaches to find the equivalence classes of the
input domain. In one approach, we partition the input domain considering one
variable at an instance such that each input variable leads to a partition of the input
domain. This approach is called as Uni-dimensional Equivalence Class Partitioning.
Another approach is to consider the set product of different input variables and then
their association forms the input domain. This is known as Multi-dimensional
Equivalence Class Partitioning.
The main target of Equivalence Class Partitioning is to define a test suite that
unravels classes of errors and that helps in the reduction of total test classes to be
developed, thereby reducing both time and cost. Therefore, we can say that the
fundamental idea of Equivalence Class Partitioning is that it either works correctly
for all values in a class or it does not. The efficacy of test cases generated by this
method for any system is measured by the number of faults these tests are able to
expose to the total number of faults lyrking in that system.
Types of equivalence class testing:

➢ Weak normal equivalence class testing: It is based on single fault assumption

which means that an error is rarely caused due to two or more faults occurring
simultaneously meaning that the variables are independent. Only one variable is
taken from each equivalence class [7].

Fig. 1. One variable is taken and that too only from valid equivalence classes.
In the figure given one variable is taken from each equivalence class. With respect
to the figure the square boxes represent the test cases and the test data are indicated
by each dot. Each class consists of one dot which means that there is one element
for each test case. Hence, the figure shows that we will have the same number of
weak normal equivalence class test cases as the classes in the partition.

➢ Strong normal equivalence class testing: Here it is assumed that errors result
in a combination of faults i.e. multiple fault assumption, where the variables are not
independent of each other. So, we test every combination of elements formed as a
result of the Cartesian product of the equivalence relation [7].

Fig.2. Test every combination of elements formed as a result of Cartesian product of the
equivalence relation

In the above figure, each test data is equally distributed among all the test cases.
With respect to the figure the square boxes represent the test cases and the test data
are indicated by each dot. Each class consists of one dot which means that there is
one element for each test case. These test cases work as same as truth tables in digital
logic’s making sure that we have got the similarities between these truth tables and
our pattern of test cases. The Cartesian product represents the ‘completeness’ in the
following ways:
1) Equivalence classes are covered.
2) We have possible combination of inputs at least one from each.

Approach to the solution

The steps to generate test case for equivalence class partitioning:

1. Firstly, determine the input domain of the program, after thoroughly analyzing the
requirements, which helps in identifying the input and output variables, their types,
and any constraints associated with their use.

2. Secondly, partition the input domain into various classes where the participants
of every class have some sort of relation with each other.

3. Thirdly, we expect that every test case from a class displays the same behavior.
Every class is thus, a separate equivalence class and we partition the set of values of
each variable into disjoint subsets which cover the entire domain, based on the
expected behavior.

4. Fourthly, sometimes equivalence classes are combined using the multi-

dimensional partitioning approach but usually this step is omitted. Nonetheless, if
we do combine the equivalence classes its helps create useful tests.

5. Lastly, infeasible equivalence classes, which contain a combination of input data

that cannot be generated during test need to be identified. Constraints in the
requirements depicts certain equivalence classes infeasible [4][5][6].

In order to perform equivalence partitioning the tester should follow the guidelines
mentioned in Table II.

Input condition Number of valid classes Number of

specification invalid classes

Range of values 1 2
Specific value 1 2
Element of a set 1 1
Boolean 1 1

Table I. Equivalence class count for various input cases

1) Field Name: Name - char [50]

The character set denotes a set of alphabets and white space. Let the character set
C={A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, a, b,
c, d, e, f, g, h, I, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z,’ ‘}
Then there will be one valid equivalent class which accepts all the elements of set C
and an invalid equivalence class is the complement set C’. So, we can choose any
random element from both partitions to design the test suite.
Test suite= {C, 4}
Where C is an element from valid partition and 4 is an element from invalid partition.

2) Field name: Date of Birth -month field

The month field of a DOB field can take the values ranges from 1 to 12. Though it
represents range of values there will be one valid partition and two invalid partitions.
Let ‘m’ denotes the month value. Then
▪ Valid class: 1≤ m ≤ 12 (Values range from 1 to 12)
▪ Invalid class 1: m<1 (Values less than 1)
▪ Invalid class 2: m>1 (Values greater than 12)

So, the minimal test suite consists of 3 test cases representing each partition.
Test suite= {-4,6,15}
The same can be applied for date field in various combinations based on th e month
value.

3) Gender: char
The gender field has three possible inputs. Male (M), Female (F) or Other (O). Let
set G= {M, F, O} represents the valid class, then G’ represents the invalid
equivalence class.

Design of the solution

We can implement and analyze the Equivalence Partitioning testing technique with
the following sample program in C to validate the month field of DateOfBirth data.

void main ()
{
int month;
printf (“Enter month”);
scanf (“%d”, &month) if((month>=1) && (month< 12))
printf (“Valid month”);
elseprintf (“Invalid month”);
}
In the above case if we apply the equivalence partitioning test suite, we got the
following test status report.
Module under test: Month field of DOB
Test case Expected Result Actual Result Test result
-4 Invalid month Invalid month Successful
6 Valid month Valid month Successful
15 Invalid month Invalid month Successful

Table II. Test status report for equivalence partitioning

In the above table, random input values have been taken and output value is
compared with the expected result and actual result. If the expected result and the
actual result are same then the test result will be successful. If the expected result
and actual result are not same then the test result will be unsuccessful.
For example, let us take the first test case as the input number which is -4. When the
input is taken in the above code in place of month, it will not satisfy the if statement
and prints invalid month i.e.
The first condition if (month >= 1) which is false because -4 is not greater than 1.
The second condition if (month < 12) which is true because -4 is less than 12.
But if you observe the code an if statement has AND operator which means both the
conditions has to be true. In our test case where we have taken -4 as the input the
first condition is false and the pointer does not go to the second condition as the first
condition is false because it is AND operator.
Likewise, all the other test inputs have to be checked with both the conditions and
has to compare with the expected result and actual result. Thus, the above program
code works perfect for equivalence partitioning test suite. Now we analyze the same
program code

Results
In Equivalence class if there are ‘N’ partitions for the input set, then there will be
‘N’ test cases in the minimal test suite.
We analyzed our DOB module with the standard testing metrics.

1. Percentage of test cases passed - This value denotes the pass percentage of the
executed tests.
Test case pass % = (No. of test cases passed Total / No. of test cases) ×100
In ECP, Test case pass % = (3/3) × 100 = 100%

2. Minimal Test suite size - The number of test cases in a test suite. For our DOB
module, Minimal test suite size of ECP = 3

So, we can say that Equivalence class partitioning has lesser number of test cases
and thereby requires less testing time and effort to design the test cases.

REFERNCES
[1] S.U. Farooq, “Evaluating effectiveness of software testing techniques with emphasis
on enhancing software reliability” Ph.D. thesis.
[2] M.E. Khan, & F. Khan, “A Comparative Study of White Box, Black Box and Grey Box
Testing Techniques”. International Journal of Advanced Computer Sciences and
Applications, 3(6), pp. 12-1 ,2012.
[3] Ian Sommeriele, “Software Engineering”, Addison Wesley.
[4] Pressman, “Software Engineering –A Practitioner’s Approach”.
[5] P. Jalote - An integrated approach to software engineering. Springer, 1997.
[6] T. Murnane, K. Reed & R. Hall, “On the learnability of two representations of
equivalence partitioning and boundary value analysis.” In Proceedings of the 2007
Australian Software Engineering Conference (pp. 274-283). IEEE Computer Society-
April- 2007.
[7] G. Davies, “Equivalence Class Testing” Swansea University -2007
[8] T. Murnane, & K. Reed. “On the effectiveness of mutation analysis as a black box
testing technique.” In Software Engineering Conference, 2001. Proceedings. 2001
Australian (pp. 12-20). IEEE – 2001.
[9] B. B. Agarwal, S. P. Tayal & M. Gupta - Software Engineering and testing. Jones &
Bartlett Learning, 2010.
[10] Black-box testing. In Wikipedia, The Free Encyclopedia, from
https://en.wikipedia.org/wiki/Black-box_testing – October, 2019.
[11] D. Galin - Software quality assurance: from theory to implementation. Pearson
education, 2004.
[12] W. L. Huang & J. Peleska, “Equivalence Class Partitions for Exhaustive Model-Based
Testing” - 2012
[13] R. Mall, Fundamentals of software engineering. PHI Learning Pvt. Ltd – 2009