use of a variety of diverse techniques, which complement each other, in such a
way that each is used wherever it delivers the greatest return on investment.
Hence software testing is better studied in a broader context that also encom-
passes other methods rather th an to be studied as an isolated set of techniques.
• Software testing as a complementary technique to static analysis. Since the early
days of software engineering, we have witnessed a colorful debate on the respec-
tive merits of software testing versus static program analysis in terms of effec-
tiveness, scalability, ease of use, etc. We take the position that each of these
techniques is effective against some type of specifications and less effective
against other types; also, very often, when we find that one technique or another
is difficult to use, it is not the result of any intrinsic shortcoming of the technique,
rather it is because the technique is used against the wro ng kind of specification.
Of course, we do not always get to choose the specification against which we
must ensure product correctness; but we can, in fact, decompose a complex spec-
ification into components and map each component to the technique that is most
adapted to it. This is illustrated in Chapter 6
.
• Software testing as a systematic stepwise process. Early on, software testing
earned the reputation of being a means to prove the presence of faults in pro-
grams, but never their absence; this is an undeserved reputation, in fact, because
testing can be used for all sorts of goals, as we discuss in Chapter 7. Nevertheless,
whether deserved or not, this reputation has had two consequences: first, the
assumption that the only possible goal of testing is fault exposure, diagnosis,
and removal. Second, the (consequent) belief that testing amounts merely to test
data generation, specifically the generation of test data that has the greatest
potential to expose faults. By contrast, we argue that testing follows a multiphase
process that includes goal identification and analysis, test data generation, oracle
design, test driver design, test deployment, and test outcome analysis. We devote
different chapters to each one of these phases.
• Software testing as a formal/formalizable process. Because it requires relatively
little analysis of the software product under test or its specification, te sting is
often perceived as an activity that can be carried out casually, and informally.
By contrast, we argue that testing ought to be carried out with the same level
of rigor as static program verification, and that to perform testing effectively,
one must be knowledgeable in software specifications, in program correctness,
in relative correctness, in the meaning of a fault, in fault removal, etc.. This is
discussed in more detail in Chapter 6
.
• Software testing as a goal-oriented activity. We argue that far from being solely
dedicated to finding and removing faults, testing may have a wide range of goals,
including such goals as estimating fault density, estimating reliability, certifying
reliability, etc. This is discussed in detail in Chapter 7.
This book stems from lecture notes of a course on software testing and quality
assurance and hence is primarily intended for classroom use; though it may also be
of interest to practicing software engineers, as well as to researchers in software
xvPREFACE
www.it-ebooks.info