Course Process

What are Defect, Error, and Failure

What is Defect?

The defect is the deviation of the actual result from the expected result in the software application. It can also be defined as incapability of the software to perform any specific due to the variation from the specification of software. The defect is mainly found by the tester in the testing phase or stage. Defects can be introduced into software due to the following reason:

  1. Deviation from customer requirement
  2. Error in the logic of the code.
  3. Lack of proper information about the system


What is Error?

An error code be introduced due to logical mistakes made by the developer or business analyst misinterpreted some requirements or there is a flaw in the design. These are the possible scenarios of the error in the software.


What is Failure?

If the software fails to perform its usual task in a real environment it could lead to failure. Here customers report defects and are thus called failure. It is an end result of defects present in the software. It can also happen due to the way the human error is interacting with the software like providing incorrect data or cause malicious damage which system is unable to handle.


The defect could arise in various stage of the development cycle:

Case 1:

Correct Requirement -> Correct Design -> Correct Implementation -> Product works as expected

Case 2:

Correct Requirement -> Correct Design -> Wrong Implement -> Product has error

Case 3:

Correct Requirement -> Mistake in Design -> Implementation as per design -> Product has defect

Case 4:

Mistake in Requirement -> Design as per requirement -> Implementation as per design -> Product failure

Thus, we can conclude below

Cost of Defect

The cost of finding and fixing defects rises exponentially with time in the software development workflow. Fixing bugs in the field is very much costly, and risky.

If the defect is introduced in the requirement specification and it is detected while testing phase then it will be much more expensive to fix as it needs requirement update, design change as well as implementation change. There would be a huge impact on the system for each change and testing of all the impacted areas required to be performed again. Thus, if the defect made is detected in the requirements phase itself, then it is relatively cheaper to fix it.

It is much easier to detect issues in code when developers are implementing the code. When the software is in the testing phase, reproducing the defects in a developer’s local environment is another time-consuming task.

After the software has been released in the field, it is very risky if there is a major defect present in the system, as it will directly affect the live users.



Defect Life Cycle

A Defect life cycle, also known as a Bug life cycle, is a cycle of a defect that goes through in its entire life cycle. This starts when the tester found any new bug and ends after the defect is fixed. The defect life cycle depends mostly on the organization process with the tool used to raise defects.


The different states of a bug in the bug life cycle are as follows:

New: Whenever a new defect is logged for the first time, it is assigned a status as NEW. The defect is documented for the development team with proper steps to reproduce along with the expected result.

Assigned: After the defect is raised by the tester, it is assigned to the developer by test lead or test manager.

Invalid: If the defect raise is not appropriate or raised due to some misconception and scenario mentioned in the bug is working as per expectation, then the defect is marked as Invalid by developer or developer lead.

Deferred: If the raised defect is appropriate but is of less priority as it does not impact much on the software, then the defect is marked as deferred. This is done usually by discussing with developer lead or project lead.

Duplicate: If the defect raised is already captured before and is in the scope of the developer to fix in the upcoming releases then it is marked as duplicate.

InProgress: If the developer accepts the defects and starts working on it fix then the defect status is marked as InProgress.

Resolved: When the bug is fixed by the developer by making some necessary code changes then the status of the bug is changed to Resolved and the bug is passed to the testing team for validating the fix.

Re-open: If the defect persists after retesting by the tester or the fix is not working as per the expectations then the tester reopens the bug and assign it again to the development team to further work on the same. The defect will again go through the life cycle to get fixed.

Closed: If the fix is working appropriately and the defect is no more available in the system then it is marked as closed after validating by the testing team.