 |
 |
|
 |
 |
1
Possibility of Reuse in Software Testing
³DQQXDO,QWHUQDWLRQDO6RIWZDUH7HVWLQJ&RQIHUHQFHLQ,QGLD´
th
Manjari Gupta
Dept. of Comp. Engg., Institute of Technology,
Banaras Hindu University, Varanasi-221 005
manjari_gupta@rediffmail.com
Meeta Prakash
meeta_prakash@rediffmail.com
2
ABSTRACT
Testing of software is considered to be the most important component of software quality
assurance process. The inherent errors that are left behind in a software code, will eventually
lead to a lot of software failures. There is a possibility of applying reuse techniques in testing, as
reuse is well known as a means for improving software quality and productivity. Unfortunately,
software reuse and testing, both, are areas that are generally neglected by the professionals,
during the development, because of various constraints and limitations. Reuse is useful and
Testing is an important task, then it is obvious to get interested in and be concerned with the
application of reuse in software testing. To get the maximum benefit of reuse, it should ideally be
implemented in all the phases of software development rather than only at coding. Since testing
phase is considered as the most difficult and time consuming, it may be possible to reduce the
total software development cost, by applying reuse in the testing phase. This work identifies
various possibilities of reuse in the testing process. Different kinds of reusable testing artifacts are
highlighted, and the categorization of these artifacts in reuse repository is explained.
KEY WORDS
Software reuse, Software testing, Test design patterns, Test environments, Test
reuse repository.
1. INTRODUCTION
Quality assurance is an important issue in software development that is mainly achieved by
testing among others like design reviews, formal specifications, model checking and inspection
etc. In recent years, there have been significant strides in technologies supporting reuse-based
software development, including the widespread adoption of design patterns, frameworks and
component implementation technologies such as .NET and J2EE. However, reuse has not been
much applied in testing phase. Testing process includes taking test requirements as input and
preparing data for test execution, performing test execution, and evaluating test results. Testing
normally requires 50% to 60% effort of total software development. Since testing is a difficult and
time consuming activity of the software development there is a need to use, with other things, the
integrated and automated testing tools. Testing involves exercising the program using real data to
be processed by the program. The existence of defects is detected from the unexpected system
output. Reuse has been considered as a technology that improves productivity and quality.
Initially reuse was considered and used only at coding phase. But later it was found that only
reuse at coding phase cannot solve the software crisis. And now reuse is being applied at each
phase of software development. However, it is not being practiced very well. There are both
technical and non-technical problems that inhibit organizations to practice it [1]. Since testing is
hardest and time consuming activity in software development, possibility of reuse must be seen
and applied at this phase. The idea is, to document and save the experiences that a tester gains
during testing so that novices can take benefit from the experience of the work done already by
others.
The idea of reuse has been very promising in terms of effort reduction during the software
development phase and the subsequent software maintenance phase. It will be very useful for
the software industry to reduce cost and enhance quality of testing by applying and practicing
reuse. Patterns and frameworks for testing can effectively be used to achieve this aim. This paper
is an attempt to demonstrate this philosophy of approach. The activities of test case generation,
test case execution environment/tools, test deliverables generation, analysis of test deliverables
all have a good deal of possibilities of reuse. The job of debugging, that is removal of faults, itself
goes for reuse of test cases so as to be confident that the software works as per specification
after corrections have been applied to it.
In the next two sub-sections, we describe software testing and reuse in brief. In section 2, we
explain how reuse can be applied in different phases of testing process. Reusable test artifacts
and their categorization are explained in section 3. The concluding section 4 summaries the idea
and its usefulness.
3
1.1 SOFTWARE TESTING
In this section, we briefly describe all the testing methods. There exist a vast number of testing
techniques and methodologies that help to achieve cost effectiveness for the testing phase. Two
basic approaches to testing are: functional and structural [2]. In functional testing the structure of
the program is not considered. The test cases are decided solely on the basis of the requirements
or specification of the program or module, while in structural approach test cases are generated
based on the actual code of the program or modules to be tested. Both testing approaches are
complementary to each other. That is both must be carried out to test a system satisfactorily. The
intent of structural testing is not to exercise all the different input or output conditions but to
exercise the different programming structures and data structures used in the program. Control
flow-based criteria, data flow-based criteria, mutation testing etc. are examples of structural
testing approach. There are a lot of levels at which testing is considered by various researchers.
A usual testing process goes through the following levels:
1. Unit testing
2. Integration testing
3. System testing
4. Acceptance testing.
When applying the well-understood levels of testing during the usage of test methodology, it
becomes a difficult task.
Unit testing is called the first level of testing. It is essentially for verification of the code produced
during the coding phase, and hence the goal is to test the internal logic of the modules.
Consequently, mostly structural testing is performed at this level. The next level of testing is
integration testing. The goal here is to see if the modules can be integrated properly, that is,
many unit-tested modules are combined into subsystems, which are then tested here. The next
level is system testing and acceptance testing. Here the entire software system is tested against
requirements document. Acceptance testing is sometimes performed with realistic data of client
to demonstrate that software is working satisfactorily. The internal logic of the program is not
emphasized here, only external behavior is tested. Consequently, mostly functional testing is
performed at these levels.
Further, testing object-oriented programs has different issues. There are several reasons that
traditional testing cannot be directly applied to test object-oriented programs. Few of them among
others are: classes cannot be tested directly, only an instance of a class can be tested. How can
an abstract class be tested, as it cannot be instantiated? Lack of sequential control flow within a
class requires different approaches of testing. State-based testing and incremental testing for
subclasses etc are testing methods for object oriented programs. State-based testing is a
technique to test whether or not the methods of a class interact correctly among themselves by
monitoring the data members of the class. It is to test all the methods of a class, one by one,
against the set of states that the object can take. During incremental testing class hierarchies are
tested.
1.2 SOFTWARE REUSE
6\VWHPDWLFIRUPDOµUHXVH¶WHUPZDVSURSRVHGDW the NATO software Engineering Conference in
1968 [3]. Software development involves understanding the requirements followed by designing
(identifying components and their integration) and implementation. It is always understood that
something that has been worked out earlier and is usable (as specification or component) can be
reused to bring down the cost of development and possibly minimize the failures (as time tested
entities are always better than a new item that has yet to be thoroughly tested).
The idea is to store such entities that have been developed and are of use in applications later.
The general understanding is that almost all the applications in a domain may have many
common components and such components can be developed once and reused many times.
Similarly various types of specifications may also be reusable. Various methods of
4
review/analysis and verification may also similarly be reusable. Different architectural/design
experiences may be reusable across applications and across domains.
This clearly shows that the scope of reuse is vast. Software is related to two issues: one
³GHYHORSLQJJHQHULFVRIWZDUHFRPSRQHQWVWKDWFDQEHUHXVHGLQPDQ\DSSOLFDWLRQV´DQGRWKHURQH
³GHYHORSPHQWZLWKWKHVHUHXVDEOHVRIWZDUHFRPSRQHQWV´6RIWZDUHUHXVHFDQEHFODVVLILHGLQ
various ways according to development scope, modification, approach, domain scope,
technologies used, management and reused entity, as given in the Figure 1 [4].
Development Modification Approach Domain Management Reused entity
Scope
scope
Internal White box General Vertical Ingrained Requirements
External Black box Compositional Horizontal Planned Design
Adaptive In-the-small Coordinated Component
In-the-large Monitored Architecture
Indirect Initial Test cases
Direct
Carried over
Leveraged
Loose
Tight
Figure 1: Classification of Software Reuse
Design patterns and frameworks are two technologies that provide high-level of reuse. Design
patterns solve specific design problems and make object oriented design more flexible, elegant
and ultimately reusable. A design pattern describes solution to a recurring problem in software
design phase [5]. Frameworks are one of the object-oriented reuse techniques that provide
highest level of reuse. It provides the reuse of the whole architecture, design and implementation
of common features in all applications belonging to a particular domain. A framework is the
skeleton of an application that can be customized by an application developer [6].
2 REUSE POSSIBILITIES IN TESTING PROCESS
As said earlier, to get the maximum benefit of reuse, it should ideally be implemented on all the
phases of software development rather than only at coding. It is evident that the total automation
of whole testing process is not possible. The test case generation, the process of identifying a set
of test cases that satisfy a test case adequacy criterion is known to be un-decidable [7] and
hence human interaction throughout the testing process is a necessity. The analysis of test
deliverables and debugging also require human interaction. In such a situation an environment,
which automates the activities that can be performed by the software on the computer and
enables the intervention by the tester whenever and wherever required, may be beneficial.
Further, test design patterns may also be developed for different activities carried out during
testing. In the following sub-sections, we tried to seek the possibility of reuse in different activities
of software testing process.
2.1 REUSE IN TEST PLAN GENERATION
In general, test plan generation is the 1 activity in software testing. Although testing is done at
st
the end of software development process but it should be planed at the beginning. A test plan is a
document that defines the scope, approach to be taken (test criterion), and the schedule of
testing as well as the test items for the entire testing process and the personnel responsible for
different activities of testing [2]. Although this activity can not be automated but some of the
activities like checking consistency between schedule defined in project plan and testing
schedule, selecting test units from the detailed design (during unit testing) and the system design
(during integration testing) can be automated. However, unit suggested by tools may not be good
enough in terms of its testability, but at unit testing level tools for this can be defined once and
reused many times. Further, if history of testing of the previously developed and tested projects
 |
|
 |
|