Defect Management Process in Software Testing

A bug is the result/consequence of a code error.

Software Testing Defect

A software defect is a difference or divergence in the software program from the end user's or original business requirements. A software defect is a coding fault that results in inaccurate or unexpected outputs from a software program that does not satisfy its intended purpose. During the execution of test cases, testers may stumble across such flaws.

These two names have a very thin line of distinction in the industry; both are flaws that must be rectified, and some testing teams use them interchangeably.

When testers run the test cases, they may come into test findings that aren't quite what they anticipated. A Software Defect is defined as a variation in test findings. In various businesses, these flaws or deviations are referred to as issues, problems, bugs, or occurrences.

This guide will teach you how to

• Report a bug

• Process for Managing Defects

• Discovery

• Categorization

• Resolution

• Verification

• Closure

• Reporting

• Important Metrics for Defects

Software Testing Bug Report

In software testing, a bug report is a thorough document describing the flaws detected in the software program. A bug report comprises every information regarding a bug, such as the description, the date the problem was discovered, the identity of the tester who discovered it, the name of the developer who corrected it, and so on. A bug report aids in the detection of similar issues in the future, allowing them to be avoided.

Your Problem Report should include the following details when reporting the bug to the developer.

• Defect ID - The defect's unique identifying number.

• Defect Description - A detailed description of the Defect, including details on the module where it was discovered.

• Version - The program version in which the flaw was discovered.

• Steps - A detailed set of steps with screenshots that the developer may use to replicate the flaws.

• Date a Defect Is Raised - When a Defect Is Raised

• Provide references to documentation like specifications, design, architecture, or even images of the mistake to aid in understanding the fault.

• Detected by - The name or ID of the tester who reported the flaw.

• Status - The defect's current state; more on this later.

• Name/ID of the developer who made the repair

• Closed Date - The date on which the fault was resolved.

• The severity of the fault defines its influence on the application.

• The priority is connected to the urgency of defect correction. According to the effect urgency with which the issue should be rectified, the severity priority might be High, Medium, or Low.

As a Test Manager, consider the following

While testing the e-commerce project, your team discovered issues. The project manager was notified when the tester discovered 85 problems. After then, the project manager turned the project over to the development team.

The developer answers after a week by correcting 65 problems. The testing team then went through the project and discovered additional 10 issues in addition to the 65 that needed to be corrected.

If fault communication is done orally, as in the example above, things quickly get quite difficult. A defect life cycle is required to successfully control and manage defects.

What is the Process of Defect Management?

Defect Management is a method for identifying and resolving defects. The steps of a defect management cycle are as follows: 1) Detection of a Defect, 2) Categorization of Defects 3) Defect Fixing by Developers 4) Testers' verification 5) Repair of the flaw 6) Defect Reports at the Project's End

This article will show you how to use the defect management approach on the E-commerce website project. To handle faults, follow the procedures below.

Discovery

The project teams must find as many flaws as possible during the discovery phase before the final client notices them. When the developers admit and accept a flaw, it is considered to be detected and changed to status accepted.

The testers found 85 flaws in the website in the scenario above −

• Discover Defect

• Identify a flaw

• Make a Defect Report

• Accept a flaw

In this scenario, a dispute resolution method should be used, and you should act as a judge to determine if the website issue is a defect or not.

Categorization

Software engineers may use defect classification to prioritize their work. That is, having a high priority allows engineers to focus on correcting the most critical flaws first.

The Test Manager is generally in charge of categorizing defects -

Let's perform a little workout like this.

Select a Priority for Defects Below

Critical/High/Medium/Low-

• The website's response time is very long.

• The website's login mechanism isn't working correctly.

• The website's graphical user interface (GUI) does not appear appropriately on mobile devices.

• The website was unable to remember the user's login session.

• A number of links were broken.

Recommended Answers

Resolving Defects

In software testing, defect resolution is a step-by-step procedure for resolving issues. The defect resolution process begins with the test manager assigning defects to developers, who then schedule the defect to be resolved according to priority. Defects are then fixed, and developers deliver a resolution report to the test manager. This method makes it simple to correct and track issues.

• Assigned to a developer or other technician to resolve, and the status was changed to Responding.

• Fixing the schedule: This is where the developers take control. Depending on the fault priority, they will design a timeline to address these issues.

• Fix the problem: While the development team is working on the defect, the Test Manager keeps track of the process and compares it to the timetable above.

• When bugs are resolved, get a report on the resolution from the developers.

Verification

The testing team ensures that the faults have been repaired once the development team has rectified and reported them.

When the development team reported that they had previously repaired 61 issues, for example, your team would test again to ensure these flaws were resolved.

Closure

The status of a defect is changed to closed after it has been fixed and validated. If this is not the case, you must submit a notification to development to have the fault checked again.

Reporting of Defects

In software testing, defect reporting is the process through which test managers produce and transmit a defect report to the management team for input on the defect management process and the status of problems. The management team then reviews the problem report and delivers comments or offers further assistance as required. Defect reporting aids in improved communication, tracking, and explanation of faults.

The management board has the right to know how many defects there are. To help you with this project, they must grasp the defect management process. As a result, you must notify them of the present faulty scenario in order to get feedback.

Important Metrics for Defects

Support the circumstances outlined above. The bugs reported have been reviewed by the development and test teams.

How can the quality of the test execution be measured and evaluated?

Every Test Manager wants to know the answer to this question. There are two parameters that you should think about −

(Number of defects rejected/ total number of faults raised)* 100 Defect Rejection Ratio

(Number of defects missed/ total flaws of software)*100 = Defect Leakage Ratio

You may compute the defection rejection ratio (DRR) in the aforementioned case as 20/84 = 0.238. (23.8 percent).

For example, assume the Guru99 Bank website has 64 faults in total, but your testing team only finds 44 of them, leaving 20 issues undiscovered. As a result, the defect leakage ratio (DLR) may be calculated as 20/64 = 0.312 (31.2 percent).

Finally, the following two parameters are used to assess the quality of test execution

23.8 percent Defect Reject Ratio

31.2 percent Defect Leakage Ratio

The lower the DRR and DLR values, the higher the test execution quality. What is the allowable range of ratios? This range might be created and approved based on the project's aim, or measurements from comparable projects could be used.

The acceptable ratio in this project is considered to be between 5 and 10%. It indicates that the test execution quality is poor. You should come up with a plan to lower these ratios, such as

• Members' testing abilities should be improved.

• More effort should be spent on testing execution, particularly examining the test execution outcomes.

Vineet Nanda

Updated on: 30-Nov-2021

5K+ Views

Kickstart Your Career

Get certified by completing the course

Get Started