Defect

DEFINITION

A Software Bug / Defect is a condition in a software product which does not meet a software requirement (as stated in the requirement specifications) or end-user expectations (which may not be specified but are reasonable). In other words, a bug 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.
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 bugs exist but NOT that bugs do not exist.

CLASSIFICATION

Software Bugs /Defects are normally classified as per:

Severity / Impact
Probability / Visibility
Priority / Urgency
Related Module / Component
Related Dimension of Quality
Phase Detected
Phase Injected
Severity/Impact

Severity indicates the impact of a bug on the quality of the software. This is normally set by the Software Tester himself/herself.


Critical:

There is no workaround.
Affects critical functionality or critical data.
Example: Unsuccessful installation, complete failure of a feature.
Major:

There is a workaround but is not obvious and is difficult.
Affects major functionality or major data.
Example: A feature is not functional from one module but the task is doable if 10 complicated indirect steps are followed in another module/s.
Minor:

There is an easy workaround.
Affects minor functionality or non-critical data.
Example: A feature that is not functional in one module but the task is easily doable from another module.
Trivial:

There is no need for a workaround.
Does not affect functionality or data.
Does not impact productivity or efficiency.
Example: Layout discrepancies, spelling/grammatical errors.
Severity is also denoted as S1 for Critical, S2 for Major and so on.

The examples above are only guidelines and different organizations/projects may define severity differently for the same types of bugs.


Probability / Visibility

Probability / Visibility indicates the likelihood of a user encountering the bug.

High: Encountered by all or almost all the users of the feature
Medium: Encountered by about 50% of the users of the feature
Low: Encountered by no or very few users of the feature
The measure of Probability/Visibility is with respect to the usage of a feature and not the overall software. Hence, a bug in a rarely used feature can have a high probability if the bug is easily encountered by users of the feature. Similarly, a bug in a widely used feature can have a low probability if the users rarely detect it.

Priority / Urgency

Priority indicates the importance or urgency of fixing the bug. Though this may be initially set by the Software Tester himself/herself, the priority is finalized by the Project Manager.

Urgent: Must be fixed prior to next build
High: Must be fixed prior to next release
Medium: May be fixed after the release/ in the next release
Low: May or may not be fixed at all
Priority is also denoted as P1 for Urgent and so on.

Normally the following are considered when determining the priority of bugs

Severity/Impact
Probability/Visibility
Available Resources (Developers to fix and Testers to verify the fixes)
Available Time (Time for fixing, verifying the fixes and performing regression tests after the verification of the fixes)
If a release is already scheduled and if bugs with critical/major severity and high probability are still not fixed, the release is usually postponed.

If a release is already scheduled and if bugs with minor/low severity and medium/low probability are not fixed, the release is usually made by mentioning them as Known Issues/Bugs. They are normally catered to in the next release cycle. Nevertheless, any project’s goal should be to make releases will all detected defects fixed.

Related Module /Component

Related Module / Component indicates the module or component of the software where the bug was detected. This provides information on which module / component is buggy or risky.

Module/Component A
Module/Component B
Module/Component C
…
Related Dimension of Quality

Related Dimension of Quality indicates the aspect of software quality that the bug is connected with.

Functionality
Usability
Performance
Security
Compatibility
…
Phase Detected

Phase Detected indicates the phase in the software development lifecycle where the bug was identified.

Unit Testing
Integration Testing
System Testing
Acceptance Testing
Phase Injected

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
Coding
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 bug tracking tool that is being used. It is essential that project members agree beforehand on the categorization (and the meaning of each categorization) to be used so as to avoid arguments, conflicts, and unhealthy bickering later.

A BUG JOKE

“There is a bug in this ant’s farm.”
“What do you mean? I don’t see any ants in it.”
“Well, that’s the bug.”

A BUG STORY

Once upon a time, in a jungle, there was a little bug. He was young but very smart. He quickly learned the tactics of other bugs in the jungle: how to bring maximum destruction to the plants; how to effectively pester the animals; and most importantly, how to maneuver underground so as to avoid detection. Soon, the little bug was famous / notorious for his ‘severity’. All the bugs in the jungle hailed him as the Lord of the Jungle. Others feared him as the Scourge of the Jungle and mothers started taking his name to deter their children from going out in the night.

The Jungle Council, headed by the Lion, announced a hefty prize for anyone being able to capture the bug but no one was yet successful in capturing, or even sighting, the bug. The bug was a living legend.

For years, the bug basked in glory and he swelled with pride day by day. One day, when the Lion was away hunting, he burrowed to the top of the Lion’s hill and, standing atop the hill, he roared “I have captured the lily-livered Lion’s domain. I am now the true King of the Jungle! I am the Greatest! I am Invincible!”

His words resonated through the jungle and life stood still for a moment in sheer awe of the bug’s capabilities. Just then, it so happened that a Tester was passing by the Jungle and he promptly submitted a bug report with the exact longitude and latitude of the bug’s location. Then, a Developer hurriedly ‘fixed’ the bug (The bug was so swollen up after his boastful speech that he could not squeeze himself back into the burrow on time.) and that was the tragic end of the legendary bug.

NOTE: We prefer the term ‘Defect’ over the term ‘Bug’ because ‘Defect’ is more comprehensive.