We have lots of terms in software testing, but we’re not always clear what they mean.  A common confusion is about the terms bug, defect, fault, failure, anomaly, incident, false positive, error, and mistake. Reader Rodrigo Cursino asks:

I read [Foundations of Software Testing]… You defined bug as a synonymous with fault or defect. If we exercise the part of software that contains that bug we’ll have a failure.

Now I’m reading your article “The Bug Reporting Processes” and I’m a little confused. Should the correct [title] be “The Failure Reporting Processes”. It’s because we report failures not bugs. The developers, based on the steps to reproduce the failure will be able to debug it and find the bug.

Rodrigo, you are right.  This is a case of common usage prevailing of terminological rigor, I suppose.  Many people talk about “bug reporting,” so I used that term in the article and in my book Critical Testing Processes. 

If we want to be rigorous in our terminology, here’s the way to think about the sequence of events:

• The programmer makes a mistake (also called an error).  This can be a misunderstanding of the internal state of the software, an oversight in terms of memory management, confusion about the proper way to calculate a value, etc.
• The programmer introduces a bug (also called a defect) into the code.  This is the programmatical manifestation of the mistake.
• The tester executes the part of the software that contains the bug.
• If the test was properly designed to reveal the bug, the test can cause the buggy software to execute in such a way that the behavior of the software is not what the tester–who is closely observing the behavior–would expect.  This difference between expected behavior and actual behavior is called an anomaly.
• The tester then investigates the anomaly to determine the exact failure. The failure may go beyond the obvious, immediately observable misbehaviors associated with the anomaly.  For example, data might have been corrupted, another process improperly terminated, etc.
• The results of that investigation are a report, which is commonly referred to in the software business as a bug report, an incident report, a defect report, an issue, a problem report, or various other names. 
• Whatever we call it, that report gets prioritized and (in some cases) ultimately routed to a programmer.  The programmer then debugs the program in order to repair the underlying bug.
• Ideally, the bug fix (typically as part of a larger test release) comes back to the tester who reported the problem in the first place for a confirmation test.  If the confirmation test passes, the report can be closed as fixed.  If the confirmation test fails, the report should be re-opened.

Now, a few additional points are worth making:

• In some cases, when a tester runs a test, she observes an anomaly, but not due to a failure.   This happens when the anomaly results from a bad test, bad test data, an improperly configured test environment, or simply a misunderstanding on the tester’s part.  This situation is referred to as a false positive.  Because some reports will inevitably be false positives–testers being human, they will also make mistakes–some people like to refer to them as incident reports.  An incident is some situation that requires further investigation, and in this case the programmer will investigate whether the incident was really caused by a failure.
• Bugs (or defects) can be introduced into work products other than software.  For example, a business analyst can put a bug into a requirements specification.  Bugs in requirements specifications and design specifications (and code, for that matter) are ideally detected by reviews.  When a bug is detected by a review (or by static analysis), notice that the bug is what is actually detected; the software is not executing, so no failure occurs.
• Some people use the word fault instead of bug or defect.  I don’t like that term, and avoid it.  When I talk about a fault, perhaps it sounds like I’m talking about something that is someone’s fault; i.e., implications of blame can arise.  Bugs happen for various reasons, and individual carelessness is not at the top of the list.  We should see bugs (and bug reports) as a way to understand the quality capability of the software process, not as a way to apportion blame.

So, back to Rodrigo’s bigger point:  Does it really matter what we call the report?  If you want to be 100% correct in your terminology, then incident report is probably the best name.  However, I think that failure report is fine, too.  I also think that, because these terms are so widely used, defect report and bug report are also acceptable.  However, when using the terms defect report or bug report, it’s important that people keep in mind the sequence of events laid out above, and that the report actually describes the symptom of the bug, not the bug itself.