Regression Testing in Object-Oriented
Problem and Solutions
Regression testing is an important activity
during the software maintenance phase. It is execution of a set of test cases
after changes are made to the system to make sure that nothing got broken while
making changes to the product. It is important to regression test the product
to make sure that the final product is stable and no new bugs are introduced. Since
the object oriented testing is complex due to inter-dependencies amongst the
classes, there is not much research around it. In this paper we will see the
problems with regression testing in Objected-Oriented programming and the possible
solutions for them. We will discuss the concept of an ORG diagram to come up
with the relations amongst the classes and also the class firewall to decide
upon the dependencies amongst them.
The Object Oriented programming is becoming
popular these days due to number of advantages offered by them. We should be
able to understand some of the OOP’s terms clearly before going into the
problems which testers face while testing them. First is “Inheritance”, It is a
mechanism by which the subclass acquires all the properties and behavior of the
parent class. Next comes polymorphism, which is a property by which a single
object can take different forms based on context. Then we have encapsulation
which deals with hiding the data and method inside the class. The outside
entities do not need to know how the functionality has been implemented inside
Now regression testing in object oriented
programming needs retesting of affected classes such that all the classes ,
directly or indirectly dependent on the changing class are tested again to make
sure that there are no negative impact on unchanged classes. This leads to few
problems that we need to address before starting the testing i) How do we
identify the classes that are affected by the change, ii) What approach do we take to test the affected
In this paper, we will look at these two
problems and try to find answers for them. WE will look at different regression
strategies. We will introduce the concept of an ORG (Object Relations Graph)
diagram and Class Firewall , to address the above two problems.
The purpose of Regression testing is to
provide solution to the following problems with the object Oriented programs
How to identify the affected classes due to change in
classes, variables or modules.
How to decide the order of testing those classes.
How to decide the test coverage criterion for the classes
that need retesting.
How to reuse the previous test cases
In this paper , we will address only the first two problems and their
4. Regression Test
The Regression test process has the following
1. Find the class that is changing in the program
This is the first
step in starting the regression testing planning is to analyze and find the
class that was modified or added in the program. This is usually easy as there
is enough documentation of the recent update made in the program.
2. Find the classes that are affected by the changing
The second step is to
identify the classes that are affected by the change or addition of the new
class in the program. This is difficult as it’s hard to determine the
relationships between the complex classes and know what is that which is
affected in the class.
3. Decide the order in which the classes need to be
Once we are done
isolating the affected class, the next step is to find the testing order. The
classes that are directly affected by the changing class are tested first followed by classes
4. Select the reusable test cases.
Next is filtration
of the already existing test cases, we need to find the existing test cases
which will be meaningful in the current scenario as well. We can use them for
5. New test cases generation
For the newly added
classes or the changes made, we will need to perform test planning and test
design to generate new test cases.
6. Test execution/ Reporting
This is the last
step in the regression testing cycle. The selected test cases are executed to
test the system as a whole and results are reported.
solution to the problems we discussed are as below:
How to identify affected classes?
The solution to this problem is provide by the Object
Relations Graph which provides insight to the relationships between different classes
in the program. The class firewall for the changed class will enclose all the
affected classes, directly or indirectly.
How to decide the
test order of affected classes?
The solution to this problem is provided by the firewall.
When we create firewall, we can identify the classes which are directly
affected with the changing class and the classes affected indirectly. Also for
the indirectly affected classes, we have different levels. Obviously, the
classes that are affected directly, need to be tested first followed by the
first level of indirectly affected classes followed by second level of indirect
We will discuss
these solutions and their components in detail in the coming sections.
6. Regression Strategy in traditional
Regression strategy provides the tester with the basic guidelines to
test the software in a systematic and organized method. There are various
different approaches available like one is based on number of test cases
executed in the regression test.
There can be two ways we can test the software based on
number of test cases:
Re-execute all the test cases and the newly implemented
Select the reusable test cases from the test plan and
re-execute them along with the newly implemented functionality.
It is very costly to execute all the test cases in
regression so mostly the second method is preferred where the test engineers
filter the reusable test cases from the test suite and execute them.
Fig1 – Regression Test Strategy
The other testing
strategy to test the object-oriented programs are:
Thread-based testing- It combines together all the classes
that are needed to provide output to one set of input of the system. All the
threads are then tested at unit level and are then integrated.
Use-based Testing – In this approach, the testing begins with the
independent classes that use very few server classes. After these are tested,
the dependent classes are tested. The layers of all depending classes are
tested till all classes are covered.
But the above mentioned approaches are very costly as they need testing
of all the classes and is very time consuming.
We will use the concept of testing selected test scenarios for
developing the method to cost-effectively test the objected oriented software.
The next important piece is to identify what is a change and how to identify
7. Identifying Change in traditional
One of the biggest challenge in performing the regression testing is
that its really hard to identify the change in the software. If the change is
isolated then it’s possible to really isolate the affected or dependent
classes. This task is tougher if the program is updated by different group of
people and testing is performed by a different set of people. The testers may
not know exactly what changed in the program. Normally, there are three type of
code changes in the object oriented software. They are listed below:
Data Change – Any update in the definition, access scope or
declaration of variable is considered a data change. New data addition is
considered as data change as well.
Method Change – Any change in the method of the class comes
under method change. There are three sub-categories of the method change based
on type of changes. They are –
i) Component Change
– Changing a predicate or a local data variable in the method.
Interface change – Changing access scope of the method.
Structure Change – Changing the control statements inside method
Class Change – Change in the class is again divided in three
categories based on the type of change
i) Component Change – Changing a method in the class
change – Changing access scope of the class.
– Changing the relationship with the other classes.
Different type of changes have different impact on the system. If there
is a requirement change the it will affect the system design, coding and
testing. If there are implementation changes, then it will affect the test
data, test cases and the test specification.
8. Regression Model – Object Relation
A ORG displays the relationships between different classes like aggregation,
association and inheritance and their objects. This way ORG can be used to
identify the inter- dependency amongst the classes.
to have clear understating of ORG, let’s first understand the different
relationships that exist between the classes in the object oriented
Inheritance – It is a IS-A type of relationship where a
child class is creating using the code from the parent class. Eg: Apple is a
fruit. Here apple is the child class and fruit is the parent class.
Composition – It is a part of type of relationship where one
object is part of anther object instance. Eg: Wheels are part of the car.
Association – In this, the objects of two classes can be
shared with each other but can exist independently as well. Eg – Employee and
Aggregation – It is a special form of association as it is
one sided. One class acts as the owner. Eg : Student and address class. Each
student will have a address but its not necessary that each address has a
The formal definition of Object Relation Graph according to (Kung, Gao,
Hsia & Lin, 1993) is , “An edge
labeled diagraph G=(V,L,E) is a directed graph, where V=(V1, V2,…..,Vn} is a
finite set of labels and
E Í V X V X L is the
set of labeled edges.”
Let’s try to understand the concept clearly with a diagram.
There are three different type of relationships that are
shown in the diagram. They are-
There are four different directed edges in the graph
corresponding to a relationship between the joining classes.
Car is a super class and vehicle is type of car. So this
relation is an inheritance relationship which has been identified with an “I”. There
is an association relationship between car and person which is
single-directional. A person can be associated with many cars but a car can
only be associated with one person.
Example Object Relations Graph
Engine is a part of car and Tire is a part of car, so these are
aggregation type of relationships.
9. Class Firewall
After the change in
software, it needs retesting at different levels – classes, modules and subsystems
to make sure that nothing is broke. Since we want cost-effective solutions and
also save the time, only a part of system is retested which is assumed to be
most affected by the change made. In this section we will discuss about the
class firewall which helps to isolate the effect of the change in any class. We
assume that no relations are updated within the classes.
By definition, a class
firewall is a set of classes that are affected by change in any class C in the
program. So if C is changed, then to ensure that system is working perfectly,
we will need to test all the classes in the firewall. Vehicle is a super class
of class Car and Car inherits all its features from Vehicle. If Vehicle class
is changed, then Car class needs to be retested as it inherits all it’s
features from super class Vehicle.
The changes made in the
super class can affected the inherited class in three different ways-
The subclass inherits the features of super class that
have been changed.
The subclass access the members of super class which have
There is no affect of the changing superclass.
To derive a class firewall, according to (Kung, Gao, Heis
& Chen, 1993), “we need to introduce a binary relation R from ORG =
Where R is the dependence relation as it defines the relationship
between classes. In all cases, C1 is dependent on C2 such that any code changes
in C2 would affect the behavior of C1.
The computed firewall is as
where R* is the transitive
closure. Any relation A on a set
Y is transitive if, for every a, b, c in Y, whenever a A b and b A c then a
10. An example to demonstrate class firewall concept
Let’s look at one simple class diagram and understand the different
concepts introduced. As we can see there are ten classes in the program and
they are related to each other with different relations. The strongest
relationship between the classes is Inheritance followed by aggregation and
then association. The rule says that whichever class in directly linked with
the changing class needs to be re-tested. For deciding the dependent classes at
the level two, we need to see the type
of relation they have with other classes in the program. If it’s an inheritance
or an aggregation, then we need to include those classes for re-testing as
Lets assume that class C7 changed in the program below.
Now we need to find the classes affected by that change. The classes which are
directly linked to C7 that is C4, C3, C2, C9 and C8 will be retested as they
directly interact with class C7 which has been modified. At the second level,
we need to chek for each of the affected classes at first level, the
relationship they have with the classes they are linked further.
Fig3 – Sample Class diagram
Indirectly affected classes are C3, C10, C9, C5 and C6.
They all will need to be retested to make sure that no new bug is introduced in the program after
the code change.
This method of identifying the affected classes from a code change will
save money and time. So it can prove to be very useful in industry.
In this paper we discussed about the regression concepts and then
applied them to object oriented software testing. We discussed the most
important problem with testing the object oriented program which is
identification of affected class. We also presented how the Object Relations
Graph helps identifying the relationship and dependencies amongst classes. Also
the class firewall can be really effective in reducing the number of classes to
be retested after code change. Also it
decides the test order for the classes that are affected by the change in the