What is a defect?

In software engineering, a defect is a bug or an error that causes the software to behave in an unwanted or unexpected way. It occurs when a developer makes a mistake while building that software.

The types of defects

A defect can be categorized into the following types:

• Wrong: A defect is wrong when the software’s functionality is not implemented as per the required specifications.
• Missing: A defect is missing when a functionality that is stated in the requirements is not implemented.
• Extra: A defect is extra when a functionality is implemented that is not stated in the set of requirements. The consumer might appreciate this.
• Error: An error occurs when someone from the development team makes a mistake. It might be a misunderstanding of the requirements or an error in the code.
• Bug: A bug is the result of an error in the code. In most cases, logical errors lead to bugs.
• Failure: Failure is when the software fails to provide the required functionality to the end-user.

How is a defect reported?

The testing or the quality assurance team reports the bugs to the development team via a detailed document called a bug report.

A bug report is a detailed document that contains the following details:

• Defect ID: A unique identification number for that specific defect.
• Description: A detailed description of the bug, e.g., the defect type, the buggy module, etc.
• Software version: The version of the software which is buggy.
• Steps: The steps required to reproduce the defect. This helps the development team trace the source of the bug.
• Date raised: The date when the defect was reported.
• Reported by: The name or unique identification of the person who reported the bug. It could be a consumer or someone from the testing team.
• Reference Material: Any material or documents that might help the development team fix the defect. This is optional.
• Current status: The current status of the defect or the current stage from the lifecycle of the defect.
• Fixed by: The name or unique identification of the developer who fixed the defect.
• Date closed: The date when the defect was fixed and marked closed.
• Severity: The severity or the impact of the defect on the overall functioning of the software. Severity could be critical, major, or minor.
• Priority: The urgency in fixing the defect. The urgency could be high, medium, or low.

How is a defect fixed?

For a defect to be fixed, it goes through an entire lifecycle. This lifecycle has the following stages:

• Defect identified
• Assigned
• Open
• Rejected
• Deferred
• Fixed
• Test
• Reopen
• Verify
• Close