A Software DEFECT / BUG is a condition in a software product which does not meet a software requirement (as stated in the requirement specifications) or end-user expectation (which may not be specified but is reasonable). In other words, a defect is an error in coding or logic that causes a program to malfunction or to produce incorrect/unexpected results.
- A program that contains a large number of bugs is said to be buggy.
- Reports detailing bugs in software are known as bug reports. (See Defect Report)
- Applications for tracking bugs are known as bug tracking tools.
- The process of finding the cause of bugs is known as debugging.
- The process of intentionally injecting bugs in a software program, to estimate test coverage by monitoring the detection of those bugs, is known as bebugging.
Software Testing proves that defects exist but NOT that defects do not exist.
Software Defects/ Bugs are normally classified as per:
- Severity / Impact (See Defect Severity)
- Probability / Visibility (See Defect Probability)
- Priority / Urgency (See Defect Priority)
- Related Dimension of Quality (See Dimensions of Quality)
- Related Module / Component
- Phase Detected
- Phase Injected
Related Module /Component
Related Module / Component indicates the module or component of the software where the defect was detected. This provides information on which module / component is buggy or risky.
- Module/Component A
- Module/Component B
- Module/Component C
Phase Detected indicates the phase in the software development lifecycle where the defect was identified.
- Unit Testing
- Integration Testing
- System Testing
- Acceptance Testing
Phase Injected indicates the phase in the software development lifecycle where the bug was introduced. Phase Injected is always earlier in the software development lifecycle than the Phase Detected. Phase Injected can be known only after a proper root-cause analysis of the bug.
- Requirements Development
- High Level Design
- Detailed Design
Note that the categorizations above are just guidelines and it is up to the project/organization to decide on what kind of categorization to use. In most cases, the categorization depends on the defect tracking tool that is being used. It is essential that project members agree beforehand on the categorization (and the meaning of each categorization) so as to avoid arguments, conflicts, and unhealthy bickering later.
NOTE: We prefer the term ‘Defect’ over the term ‘Bug’ because ‘Defect’ is more comprehensive.