Fault, an Evasive Concept

6.2.1 Fault, an Evasive Concept

The discussions in Section 6.1 make it sound like faults are a simple concept, they are easy to characterize and locate, and easy to remove; reality is more complicated than that.

Let us consider again the program of Section 6.1:

{ s=s+1; // line 1 s=2*s;

// line 2 s = s % 3;

// line 3 s=s+12;}

// line 4

We assume that the fault is in line 2 and that correcting the fault consists in replacing the statement (s=2*s) by the statement (s=s*s). Alternatively, we could also argue that a way to correct this program is to change line 3 from (s=s%3) to (s=((s/2)**2)%3). Alter- natively, we could also argue that a way to correct the program is to insert a statement between lines 2 and 3 that reads (s=(s/2)**2). Alternatively, we could also argue that a way to correct the program is to change line 1 from (s=s+1) to (s=(s+1)**2–2) and line 2 from (s=2*s) to (s=s+2). Alternatively, we could argue that a way to correct the program is to change line 1 from (s=s+1) to (s=(s+1)**2) and to remove line 2. Of course, all these alternatives sound convoluted and far-fetched, but any definition of fault ought to make equal provisions for all these possibilities.

Furthermore, if we consider a non-deterministic specification, then we now have two degrees of failure: the program may fail because it violates its (non deterministic) specification or because it fails to compute the function it was designed to compute. This distinction is important in practice: if we are conducting unit testing, for example, then we want to judge the program against its intended function, but if we are conduct- ing acceptance testing, then we want to judge it against its (possibly non-deterministic, much less-refined) specification.

We let space S be the set of natural variables and let R be the following specifi- cation on S:

R= s,s s mod 3 = s + 1 2 mod 3

Imagine that upon inspecting R, the programmer decides to write a program that computes the following function:

π = s,s s=s+1 2 mod 3

104 FAILURES, ERRORS, AND FAULTS

We consider the following candidate programs on S: • p1: {s=s+1; s=s*s; s=s%3; s=s+12}

• p2: {s=s+1; s=s*s; s=s%6; s=s+12} • p3: {s=s+4; s=s*s; s=s%3; s=s+12}

These programs are not correct with respect to π but they are correct with respect to R. Hence whether these programs have faults or not depends on whether we are judging them against R or against π.

From these discussions, we draw the following conclusions about faults in programs:

A fault is not a characteristic of a program but rather depends on a program and a specification. • Neither the existence, nor the number, nor the location, nor the nature of faults is uniquely determined: the same faulty program behavior can be remedied in a num- ber of different ways, involving a number of locations and involving different types of corrective actions (changing an existing statement, adding a statement, removing a statement, changing the location of a statement, etc.). This observation should give us an opportunity to ponder what it means to measure fault density in a program, or fault proneness, or other fault-related metrics.

• Designating a particular statement as a fault is often a tentative decision that is contingent on assumptions made about other parts of the program; as such, the designation of a statement as faulty is as valid as the assumptions made about other parts of the program.

• Very often, when we designate a program part (a statement or a set of statements that may or may not be contiguous) as faulty, we do so on the basis of an assump- tion we have about the specification of the program part; hence we are in effect second-guessing the designer by presuming to know what his intent is with respect to the designated program part. Clearly, our diagnosis of the fault is only as good as our assumption.

In this chapter, we give a definition of a fault that has the following attributes: It involves the program, the (possibly) faulty program part, and the specification; it makes no assumption on the correctness of incorrectness of any other part except the faulty program part; and it makes no assumption about the intent of the program designer.