What is Software Bug? Learn Defect Management Process
What is bug?
A bug is the consequence/outcome of a coding fault.
What is a defect?
A defect is a variation of deviation from the original business requirements.
These two terms have very thin line of difference. In the industry both are faults that needs to be fixed and so interchangeably used by some of the Testing teams.
When a tester executes the test cases, he might come across the test result which is contradictory to the expected result. This variation in the test result is referred to as a Software Defect. These defects or variation are referred by different name in an organization like issues, problems, bugs or incidents.
While reporting the bug to the developer, your bug report should contain the following information:
- Defect_ID - Unique Identification number for the defect
- Defect Description - Detailed description of the defect including information about the module in which the defect was found
- Version - Version of the application in which the defect was found
- Steps - Detailed steps along with screenshots with which the developer can reproduce the defects.
- Date Raised - Date when the defect is raised
- Reference - Where in you provide a reference to the documents like requirements, design, architecture, or maybe even screenshots of the error to help understand the defect.
- Detected By - Name/ID of the tester that raised the defect.
- Status - Status of the defect.
- Fixed By - Name/ ID of the developer that fixed it.
- Date Closed - Date when the defect was closed.
- Severity which describes the impact on the application.
- Priority which is related to defect fixing urgency. Severity priority could be High/Medium/Low based on the impact urgency at which the defect should be fixed respectively.
Consider the following as a Test Manager
Your team found bugs while testing the Guru99 Banking project.
After a week the developer responds -
The next week tester responds
As in the above case, if the defect communication is done verbally then things become very complicated. So to manage defects we need a defect life cycle.
Defect Management Process
Please do follow the below mentioned steps to manage defects
Discovery
In the discovery phase, the project teams have to discover as many defects as possible, before the end customer can discover it. A defect is said to be discovered and change to status accepted when it is acknowledged and accepted by the developer.
Let's have a look at the following scenario; your testing team discovered some issues in the website. They consider them as defects and report to the development team, but there is a conflict -
For the scenario above, a resolution should be applied to avoid the conflict, you take the role as a judge to decide whether the website problem is a defect or not.
Categorization
Defect categorization help the software developers to prioritize their tasks.
This kind of priority helps the developers in fixing those defects first that are crucial.
Defects are usually categorized by the Test Manager
Resolution
Once the defects are accepted and categorized, you can follow the following six steps to fix the defect:
- Assignment: Assigned to a developer or other technician to fix, and changed the status to Responding
- Schedule Fixing: The developer side takes charge in this phase. They will create a schedule to fix these defects, depend on the defect priority.
- Fix the defect: While the development team is fixing the defects, the Test Manager tracks the process of fixing defect compared to the schedule above.
- Report the resolution: Get a report of the resolution from developers when defects are fixed.
Verification
After the development team fixed and reported the defect, the testing team verifies that the defects are usually resolved absolutely.
For example, in the scenario above, when the development team reported that they already fixed 61 defects, our team would test again if the defects are tested properly and completely or not.
Closure
Once a defect has been resolved and verified, the defect is changed status as Closed. If not, you have to send a notice to the development team to test again.
Reporting
The management board has the right to know the defect status. They must understand the defect management process to support you in this project. Therefore, you must report them the current defect situation to get feedback from them.
Important Defect Metrics
Back to the above scenario. Developer and test teams have reported the defects. Result of the discussion is as follows:
How to measure and evaluate the quality of the test execution?
This is a question which every Test Manager wants to know. There are 2 parameters which you can consider as following
In the scenario above, we can calculate Defect Rejection Ratio(DRR) is 20/84 = 0.238(23.8%)
Another example, suppose the bank website has total of 64 defects, but your testing team has only detected only 44 defects. The Defect Leakage Ratio(DLR) is 44/64 = 0.6875(68.7%)
Conclusion, the quality of test execution is evaluated via following two parameters:
Defect Rejection Ratio = 23.8%
Defect Leakage Ratio = 68.7%
The smaller value of DRR and DLR are, the better quality of test execution is. What is the ratio range which is acceptable? This range could be defined and accepted base in the project target or you may refer the metrics of similar projects.
Recommended acceptable ratio would be around 5-10%. It means the quality of test execution is low.
You can countermeasure to reduce their ratios such as
- Improve the testing skills of the member
- Spend more time for testing execution,especially for reviewing the test execution results.
