Hardware Reference
In-Depth Information
We believe that answering these questions will clarify some of the ambiguity cur-
rently associated with TC interpretation, and pave the way to articulating a formal TC
definition. If and when widely accepted, it can relieve some of the ambiguity associ-
ated with software testing metrics that commonly relies on counting TCs. Further-
more, an appropriate formal definition can drive automation of TC generation and
management. Therefore, this work is clearly a contribution to software process im-
provement by dealing with an important aspect of testing - the test case.
The rest of the paper is organized as follows: common software testing processes and
practices are briefly described in the next chapter, showing the importance of testing
processes in software engineering, and the TC as the testing building block. We then
describe the literature survey methodology employed. Next, several definitions for TCs
are presented as a result of the literature survey, showing the conceptual variability of
these definitions. We then proceed to a review of the literature discussing the centrality
of TCs in testing processes, concluding with a suggestion of dimensions by which a TC
definition can be evaluated, as well as an evaluation of existing definitions based on
these dimensions. The paper concludes with a discussion of the implications of the lack
of a unified approach to TCs and whether there is a need to re-define this term.
2 Common Practices in Software Testing
In the following section the importance of testing in terms of its substantive role in
software development on the one hand, and of its complexity, on the other hand, is
briefly presented. This background clarifies the merit in further looking into TC use
and definitions, since TCs are building blocks of testing.
The testing effort undoubtedly comprises a significant portion of the programming
effort. For example, an early research conducted at NASA [2] found that testing ef-
forts comprise 30% of the time invested by programmers, and 37% of their actual
work days (Figure 1).
Fig. 1.
Distribution of the effort among programmers' tasks (NASA) [2]
