Defect Removal process

In the recent past,IT projects are spending more time in arriving at 'defect prediction', 'defect detection', defect prevention' activities as this plays a key driver for the overall QUALITY of the product / project.

Out of this, defect removal efficiency is the one which is getting more important to the project teams as this is one of the measurement to assess the quality of the project team delivery.

You need to be a member of Software Testing Club - An Online Software Testing Community to add comments!

Defect Removal Efficiency Definition : The defect removal efficiency (DRE) gives a measure of the development team ability to remove defects prior to release. It is calculated as a ratio of defects resolved to total number of defects found. It is typically measured prior and at the moment of release.

Calculation To be able to calculate that metric, it is important that in your defect tracking system you track: affected version, version of software in which this defect was found. release date, date when version was released DRE = Number of defects resolved by the development team / total number of defects at the moment of measurement.

DRE is typically measured at the moment of version release, the best visualization is just to show current value of DRE as a number.

Example For example, suppose that 100 defects were found during QA/testing stage and 84 defects were resolved by the development team at the moment of measurement. The DRE would be calculated as 84 divided by 100 = 84%

So it is all about the ratio of bugs fixed and total bugs found prior to release!!! What if there were 10 bugs out of which 8 were cosmetic and 2 would crash the system. Now according to the given formula if developers fix all the 8 cosmetic bugs that will mean they are very efficient, but is it really the case? what about the defect severity?

Numbers are not good or bad. They're just numbers. Sometimes, numbers can be an indicator of a potential issue or problem. Sometimes not. The question I would ask: "Is the time spent tracking these numbers that may indicate a potential problem time that could better be spent elsewhere?" Assuming you're using any sort of defect management tool developed in the last 20 years, I'd say the calculations are probably done for you, so why wouldn't you look at this number? I'm sure you could find an edge case somewhere of a manager who bases your performance on this and only this number, but in that case, I'd say the problem lies with the manager, not the number.