Defect vs Bug vs Error vs Failure — Defect Bug Management
Here is complete guide on Defect Bug Management:
Defect
A deviation between the actual result and the expected result.
Bug
The informal name for a defect. When any defect is found by the testing team, we call it a bug.
Error
Any mistake in programming; a mistake made by developers.
Issue
A problem faced by customers.
Failure
When end users face many issues. It stems from the customer/client environment, where the application is unable to perform its functions.
Miss
One or more customer requirements were overlooked during implementation.
Wrong
Indicates an incorrect implementation of customer requirements.
Fault
An incorrect step, process, or data definition in a software product.
Showstopper Defect
A defect that highly impacts the business, due to which we cannot proceed with further testing.
Defect Age
The time gap between the date of detection and the date of closure of a defect.
Defect Report Contents
A defect report typically includes:
- Defect ID — a unique number to identify the defect.
- Defect Title — the defect name.
- Defect Description / Summary (Steps to Reproduce) — a brief description of the defect.
- Defect Status — Deferred / Rejected / Duplicate / New / Assigned / In Progress / Fixed / Closed.
- Expected Result
- Actual Result
- Attachment / Screenshot
- Environment
- Severity
- Priority
- Reported On
- Reported By
- Assigned To
Severity vs Priority
Priority
- Concerned with the application from the business point of view.
- How quickly we need to fix the bug / how soon the bug should get fixed.
Severity
- Concerned with the functionality of the application.
- How much the bug affects the application's functionality.
In short:
- Severity = How the bug impacts the application (Blocker/Showstopper, Critical, Major, Minor).
- Priority = Which bug needs to be fixed first (Urgent, High, Medium, Low).
Priority always impacts the customer's business.
Severity Types and Priority Types
Severity Types
Blocker
We cannot proceed to the next module, and the test engineer sits idle.
Critical
The main functionality is not working, and the test engineer cannot continue testing.
Major
The supporting components and modules are not working fine, but the test engineer can continue testing.
Minor
UI problems exist, but testing can proceed without interruption.
Priority Types
Priority determines which bug is fixed first and how soon.
It can be:
- Urgent
- High
- Medium
- Low
High
A major impact on the customer's application. It has to be fixed first.
Medium
Should be fixed before the release of the current version in development.
Low
Should be fixed if time allows, but can be deferred to the next release.
Severity–Priority Examples
High Severity and Low Priority
The tester clicks the "Privacy Notice" hyperlink at the bottom of the Amazon.com homepage, but the page does not display.
This is high severity because the functionality isn't working, but low priority because people don't typically read the privacy notice.
Example: One rarely used flow of a task is not working.
High Severity and High Priority
You log in to Amazon.com, add items to your cart, click "Proceed to Checkout," complete payment, and the system crashes.
This renders the entire buying functionality unusable, so the severity is high.
Because buying and selling are the site's core purpose and affect most customers, this is a high priority and must be fixed immediately.
Other examples:
- Products added to the cart aren't visible on the payment page.
- The login button isn't working.
Low Severity and High Priority
The Amazon.com logo is displayed as "amazn.com" with the letter "o" missing.
This doesn't affect functionality, so the severity is low.
However, a mistake in the company logo affects brand identity and user experience, so the priority is high.
Other examples:
- If the Flipkart logo is misspelled, it directly impacts the business. People think it isn't genuine and won't buy, so business impact is huge and priority is very high, but for developers the fix is easy and breaks no workflow, so severity is very low.
- The "About Us" page is giving an error message. It blocks no business flow, so low severity, but every business needs an About Us page, so high priority.
Low Severity and Low Priority
The tester clicks the "Conditions of Use" hyperlink at the bottom of the Amazon.com homepage and finds an alignment issue or spelling mistake.
Low priority because people rarely read this page and it doesn't impact the experience.
Low severity because functionality is not affected.
Other examples:
- A spelling mistake on a rarely visited page.
- Text color not matching the website theme.
Who Decides Severity and Priority?
- Severity is decided by the tester.
- Priority is decided by the developer.
The Defect Life Cycle
New
When a tester finds a defect, the status is set to New.
Assigned
The defect is assigned to the development team by the project lead or the testing team manager.
Open
The developer starts analyzing the defect and works on fixing it.
If the developer feels the defect is not appropriate, it may be moved to:
- Duplicate
- Deferred
- Rejected
- Not a Bug
based on a specific reason.
Fixed
When the developer finishes fixing the defect by making the required changes, the status is marked Fixed.
Retest
The tester retests to verify whether the defect is fixed accurately per the requirements.
Reopen
If the issue still occurs, it is reassigned to the developer, and the status becomes Reopen.
Closed
When the defect no longer exists, the tester marks it Closed.
Other Statuses
Rejected
The developer does not consider it a genuine defect.
Duplicate
The defect is the same as, or matches the concept of, another defect.
Deferred
The defect is low priority and can be fixed in a later release.
Not a Bug
The defect does not affect the application's functionality.
Steps to Follow Once a Defect Is Found
- Recreate the defect.
- Attach the screenshot.
- Log the defect.
How to Report a Bug
When reporting a bug, fill in all mandatory fields:
- Project
- Summary
- Description
- Status
- Detected By
- Assigned To
- Date Detected
- Detected-in Version
- Closed-in Version
- Expected Date of Closure
- Actual Date of Closure
- Severity
- Priority
- Bug ID
After reporting, the bug reporting tool generates a unique Bug ID, which is then associated with the failed test case.
This helps link the bug to the failed test case.
After a bug is reported, it is assigned the status "New," which keeps changing as the bug-fixing process progresses.
If no bug reporting tool is used, we write it in a table with four columns:
- Test Step Number
- Test Case Description
- Expected Result
- Actual Result
This file, along with the test case and screenshots, is sent to developers for reference.
As the tracking process is not automated in that case, it is important to keep the bug information up to date from the time it is raised until it is closed.
Defect Triage
Defect triage is the process of prioritizing each bug based on its severity, frequency, risk, and other factors.
The goal is to evaluate, prioritize, and assign the resolution of defects.
During triage:
- A bug is reviewed.
- A priority is assigned.
- According to the priority, it is either assigned to a developer for fixing or deferred to the next release.
- High-priority bugs are fixed urgently.
- Low-priority bugs are deferred.
What Happens During a Defect Triage Meeting?
- The test team leader sends out a bug report with the new defects.
- Each defect is analyzed to ensure the correct priority and severity are assigned. Priorities are rearranged as needed.
- Defects are evaluated by the degree of their severity.
- Discussion covers the complexity of the defect, risks, error rejection, and error reassignment.
Bug Leakage, Bug Release, Latent Defect & Deferred
Bug Leakage
When a customer or end user discovers a bug that could not be detected by the testing team, or when a bug that should have been detected in a previous build is found later.
Bug Release
When a build is handed to the testing team, knowing that a defect is present in the release.
The priority and severity of the bug are low.
It is done when the customer wants the application on time.
Latent Defect
A defect not identified during the testing phase and later identified (after release) by the customer.
It is an existing defect that doesn't cause a failure because the exact set of conditions has never been met.
Deferred
If the release date is near and there is no time to fix the defect, it is not fixed in the current release and is scheduled for a future/next release.
Such a defect is mentioned in the Release Note for the customer's understanding.
Defect Principles: Clustering, Cascading, Density, Velocity, Masking
Defect Clustering
One of the seven principles of software testing.
Most defects are caused by a small number of modules.
Defects are not uniformly distributed across the application but are concentrated in limited sections.
When a small number of modules contain most of the detected bugs, that situation is called Defect Clustering.
Defect Cascading
When one defect produces another defect.
Defect Density
A measure of the number of defects identified relative to the number of lines of code.
Defect Velocity
How much work is done by the team in one sprint.
Fault/Defect Masking
When the presence of one defect hides another.
Example:
If a negative value causes an unhandled system exception, the developer prevents negative-value input.
This resolves the issue but hides (masks) the unhandled-exception defect.
Types of Defects
Performance Defect
When a page loads, but some element takes more time to load.
For example, if the search button does not appear properly or appears late, we call it a performance defect.
UI Defect (User Interface Defect)
- Font problems
- Oversized options
- Improper alignment
- Blurred display
These come under UI defects.
UX Defect (User Experience Defect)
When, according to users, they are unable to find the logo/icon in the application.
They are unable to focus on a particular option.
API Defect
When the search button does not work, it is considered an API defect.
FAQs
1. What is the difference between a defect, a bug, and an error?
A defect is a deviation between actual and expected results.
A bug is the informal name for a defect found by the testing team.
An error is a mistake in programming made by a developer.
2. What is the difference between severity and priority?
Severity is how much the bug affects the application's functionality (as determined by the tester).
Priority is about how soon the bug should be fixed from a business perspective (as determined by the developer).
3. Can a defect have high severity but low priority?
Yes.
For example, a rarely used page failing to load.
The functionality is broken (high severity), but users seldom visit it (low priority).
4. What are the stages of the defect life cycle?
- New
- Assigned
- Open
- Fixed
- Retest
- Reopen (if needed)
- Closed
Other statuses include:
- Rejected
- Duplicate
- Deferred
- Not a Bug
5. What is defect triage?
A process where each bug is reviewed and prioritized by severity, frequency, and risk, then assigned to a developer or deferred to a later release.
6. What is the difference between bug leakage and bug release?
Bug Leakage: A bug escapes the testing team and is found by the customer.
Bug Release: A build is knowingly released with a low-severity, low-priority defect, usually to meet a deadline.
7. What is a latent defect?
An existing defect that stays hidden because the exact conditions to trigger it have never been met.
It is typically found after release.
8. What is defect density?
A measure of the number of defects identified relative to the number of lines of code.
9. What is fault masking?
When one defect hides another in the system.
10. What should you do the moment you find a defect?
- Recreate the defect.
- Attach a screenshot.
- Log it.
