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




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.  