How defects are detected, documented, and categorized?

As testers, we deal with defects all the time.

However how many of us understood the subtle difference between various terminologies like Bug/Failure/Fault/Defect & Errors?

Even most experience testers often get confused with these terms.

So today let’s examine each of these terms in detail:

  • Errors : Errors are usually caused by human action. Or in other word, it’s a mistake. For example omission or misinterpretation of user requirements in a software specification  is considered as a error. Incorrect implementation of requirements in design specification can also be considered as  errors or human mistakes.
  • Failure : Failures are observable incorrect behavior or observable deviation from expected behavior. E.g. While testing/production , product crashed when the user selected an option in a dialog box.
  • Fault / Bug : The cause of failure is termed as Fault. This can also be referred as Bug. E.g. Incorrect program code statement or condition. Most of the cases, this can be identified and removed.
  • Defect : Defect can be used to refer both fault(cause) and failure(effect).

When Can a Defect Be Detected?

A defect can be detected any stage in life cycle either through static testing (design or code reviews) or through dynamic testing (using test cases).

If a defect is detected and corrected in earlier stages (for e.g. in static testing),it is considered as the cost effective approach to produce high quality software. Here comes the importance of phase containment.

Phase containment is the percentage of defects that are removed in the same phase of the software life cycle in which they were introduced. i.e. Every requirement problem is found and fixed through a requirements review or user story review. Every coding mistake is found and fixed in a code review or through static analysis.

With perfect phase containment, each and every defect is removed in the same phase in which it was introduced.

After defect detection, it is important to write good defect reports in order to increase the probability of fixing those defects.

How to write a good defect report?

Below are couple of guidelines for writing a good defect report.

  • The bug report should be Complete.It contains all the information necessary for the decision makers to make an informed decision.
  • It doesn’t have irrelevant detail that no one cares about and that clutters up the important information.
  • The information in bug report should be correct and clear so the reader can understand what happened versus what was expected.
  • The report contains information that is objective rather than subjective and is a statement of fact rather than of opinion.
  • Severity and priority should be specified clearly.Severity refers to the impact of bug and priority should reflect when the company wants to fix those defects.
  • If you write a report that has multiple bugs on it, some of them will probably never be fixed. So never write a bug report which merges different bugs. Every bug deserves its own report.
  • If you think you are going to report a bug which is similar to another bug which has already been reported, make sure to verify them again. Reporting duplicate issues are always waste of time. Manage your time wisely.
  • Report defects promptly. As testers , we shouldn’t assume that certain obvious defects has already been reported. Sometimes it makes the bug not fixed until shipping.

While the usual goal in writing a defect report is to obtain a fix for the problem, the defect information must also be supplied to support accurate classification, risk analysis, and process improvement.

Defect classification helps to group defects and hence increase the efficiency of testing.

These classification information includes :

  • Activity during which the defect has been detected. This could be  review, inspection, coding or testing
  • life cycle stage in which the defect introduced (E.g. requirements, design, detailed design, code)
  • Repeatability – e.g., once, intermittent, reproducible
  • Symptom – e.g., crash, hang, user interface error, system error, performance
  • Root cause – the mistake that was made that resulted in the defect, e.g., process, coding error, user  error, test error, configuration issue, data issue, third party software, external software problem or a documentation issue
  • Type – e.g., logic problem, computational problem, timing issue, data handling, enhancement
  • Resolution – e.g., code change, documentation change, deferred, not a problem, duplicate
  • Corrective action – e.g., requirements review, code review, unit test, configuration documentation, data preparation, no change made
  • Severity – the impact of bug
  • Priority : when the company wants to fix those defects

Often these values are customized based on the project and organizational policies. Also this is one of the important factor in defect reporting tool selection.

Finally lets look into one of the few widely accepted life cycle models for defects, as the one shown below:


Defect life Cycle


Hope you would have found these terms are pretty self explanatory.

If not, have a look into the below table which has each stage and the corresponding description.


Defect Life Cycle Stages


At any time, defects are being tracked throughout the life cycle stages.

Having a good life cycle for defects / tool support helps to ensure effective defect processing in most of the project scenarios.

Please leave your comments below and share the post if you find this useful.