A Software DEFECT / BUG / FAULT 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.
- defect: An imperfection or deficiency in a work product where it does not meet its requirements or specifications.
- A program that contains a large number of bugs is said to be buggy.
- Reports detailing defects / bugs in software are known as defect reports / bug reports. (See Defect Report)
- Applications for tracking defects bugs are known as defect tracking tools / 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
- Build / Deployment
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.
Some metrics related to Defects are:
Defect vs Bug
Strictly speaking, a BUG is a deficiency in just the software but a DEFECT could be a deficiency in the software as well as any work product (Requirement Specification, for example). You don’t say ‘There’s a bug in the Test Case’; you say ‘There’s a defect in the Test Case.’
We prefer the term ‘Defect’ over the term ‘Bug’ because ‘Defect’ is more comprehensive.
Last Updated on September 12, 2020 by STF