Defects are inherent to any software development project and cannot be avoided. The best way to minimize the impact of defects is to put together a defect management process and ensure that defects are captured, reported, categorized and resolved with minimal effort and cost spends.
There is huge competition in the software development market which has resulted in high pressure on delivery teams to release the software in minimum possible time. Though software practices too have improved over the recent times but increased pressure on teams to deliver faster always comes with an increased risk of defects in the final software.
In this article we will talk about various aspects of defect management process, defect metrics, various defect tracking and management tools and best practices for defect management.
Why Defect Management Process?
The best thing one can do is to minimize occurrence of defects by improving software development practices since defects come with a cost and the cost is really high if defects happen to escape through to production. The effort and cost required for finding and fixing defects too is high and multiplies with every phase escaped by the defect.
The next best thing is to put in all efforts in findings and fixing the defects as early as possible and the starting point for that is a well-defined defect management strategy.
A well-defined defect management strategy is a discipline in itself and involves multiple parts including defects management process, Defect tracking tools, Defect metrics and proven best practices.
Defect Management Process – Steps
To start with, let us look at the defect management process in a bit more detail. The key components of the process are as listed below –
- Defects Prevention
- Process Improvement
Prevention is better than cure but not always possible.
The first and the foremost activity in any defect management process is the planning to get rid of defects altogether. Prevention strategies are costly and take lot of efforts and at times more efforts than detecting and fixing defects in next iteration/phase.
Where to spend efforts – in prevention – or in fixing – is the question that you need to answer based on the size, complexity and criticality of the software (or module) that you are building.
What works the best in most of the cases is to focus mainly on the areas of the software that are high risk and critical, and eliminate or minimize occurrence of defects in those areas by using various tools, techniques and best practices.
Testing and Discovery
Testing in software development is the discipline that validates behavior of software against the specifications and reports any deviations as defects. Thorough testing that covers each and every corner and all scenarios ensures that defects are detected early and no escaped to the next phase.
Talking about the defects management process, testing at times gets sidelined as a separate discipline but it is the integral part of an overall defect management planning. Testing is effort consuming and needs a careful planning and execution since testing is the phase to discover and log defects back for the development team.
Talking a bit more about testing, there is unit testing, system testing, integration testing, QA and user acceptance testing. Discovery of defects in unit testing phase probably is the most desirable option whereas discovery in user acceptance testing phase would be the least preferred one. Of course, we are leaving production at bay for now.
Defect categorization is another critical aspect of overall defect management process and is often a collaborative effort of development managers, QA managers and project manager. There are multiple ways to categorize a defect, given below are few of the most used defect categorization techniques –
- Severity of Defect (Show Stopper, Major, Minor, Trivial etc.)
- Priority of Defect (Critical, High, Medium, Low etc.)
- Phase Reported (Unit Testing, System Testing, User testing, Production etc.)
- Phase Injected (Design Phase, Development Phase, Integration Phase etc. )
- Defect Class (Technical, Functional, Performance, Security etc.)
- Module Wise
- And more…
While there is no industry standard when it comes to various defect categories but it helps to go with one or more of the above mentioned categories, as these are proven workable options.
Furthermore, since there is no fixed standard, one can always add more values to these categories for a more granular segregation of defects, or the other way round too.
This is where the real action begins, fixing the defects and improving the software. What defects to fix on priority becomes tricky at times. Many a times, low criticality defects are easy to fix whereas critical defects eat up lot of time of development team.
Developers are always under the pressure to reduce defects count and for that reason they tend to go for easy fixes first, if there are no clear guidelines.
Defects resolution is not the easiest one since touching one piece of the code can impact other areas as well and can result in additional defects.
Validation is about re-testing the software to ensure that reported defects have been fixed. Validation typically includes testing other related modules or features that are linked to the feature that contained defects. This is to ensure that new defects are not introduced in other sections during defect resolution process.
Analytics is used to assess the current situation and figure out areas that need improvements. Analytics is also the key to continuous improvements in the software development processes to ensure that either defect are lesser or the impact is minimal, in the long run.
Defects analytics also includes calculation of various defect metrics, defect metrics are covered later in this article.
Process improvement opportunities are identified from the analytics done on the defects data. The idea is to strengthen the processes to ensure that defects of similar nature do not occur in future.
Defect Management Tools
There are many free as well as commercial tools out there in the wild that are used for defects management. Depending on the requirements, size and complexity of the project you can opt for an open source tool like MantisBT, Bugzilla etc. or a commercial tool like JIRA, YouTrack, FogBugz and HP ALM etc.
The benefit of using a defect management tool surpasses the cost by margins and for that reason it is always recommended that you use a defect management tool in your projects. Some of the key benefits of such tools are as listed below –
- Configurable workflows to track defects from first appearance till final closure
- Ease of prioritization, categorization and sprint planning
- Integration with other testing and developer tools
- Easy to use and intuitive interface – zero training costs
There were times when defects were tracking in Excel sheets and over emails etc. but now a days highly sophisticated tools are used that match up the pace of fast moving tech landscape.
Individuals as well as organizations of all scales use one or more of the defect management tools during development lifecycle of mobile, web and enterprise software.
Some of the key features of defect management tools are listed below for a quick reference –
- Detecting duplicate defects
- Create and update of defect details via emails
- Capture defect metrics
- Reports and Dashboards
- Option to customize workflows
- Multilingual support
- Access control as per roles
- Integration with org directories like LDAP
- And much more….
There is another dedicated article on defect tracking tools which was published couple of months ago, you might want to check that out for further details.
Defect Management Process – Metrics
Defect metrics is another important component of overall defect management strategy and is useful for measuring efficiency and effectiveness of development and testing teams as well as for making continuous improvements in the overall software development processes.
Metrics give development managers a clear indication of where more efforts are required to be spent to minimize occurrence and re-occurrence of defects.
Some of the key metrics used in defects management practices are as listed below –
- Defects Density
- Defects Detection Percentage
- Defect Removal Efficiency
- Escaped Defects
- Detection Time and Resolution time
- Open/Close Rates
- Defect Distribution
Defect Density – Defects density is a clear indication of how effective your developers are and how mature is your software development process overall. Defect density is defined as number of defects divided by size of the software. Talking about the software size – number of lines of code is one of the most used measures for software size. Function point is another measure for software size but is used less often these days.
Defect Density = Number of Defects/Size of Software
Defect Density = Number of Defects/Lines of Code
Defect Density = Number of Defects/Function Points (FP).
Defects Detection Percentage (DDP) – DDP tells you about the effectiveness of testing teams to detect defects and indicates maturity of your overall testing processes.
Most of the defects are typically detected by the time software is finally released but unfortunately few defects still escape to final version and are reported by the end users.
Defects Detection Percentage represents ratio of defects detected till software version release to the total defects (defects detected till release + defects escaped to production and detected by end users).
DDP = Defects Detected/Total Defects found by all means.
Defects Removal Efficiency (DRE) – Coming back to the efficiency of development team, DRE is another metric and it is defined as ratio of defects reported to defects resolved at the time of measurement.
DRE = Defects reported/Defects Resolved
Escaped Defects – Defects can escape to another phase, to next iteration, or to production itself. Defects that make it to production are those that happen to cost you the most.
Calculation for defects escaped to production would be –
Escaped Defects = Defects reported by end users/ (Total Number of Defects in prior Phases + Defects reported by end users)
Detection and Resolution Times
These are also called mean time to detect (MTTD) and mean time to repair (MTTR), MTTD gives an overall view to the management on the efficiency or productivity of testing teams whereas MTTR is more for development team’s productivity tracking.
MTTD = Total number of Defects/Total Execution Time
MTTR = Number of Defects Fixed/Development Time
Defect Distribution is another metric that is used to identify functional areas of software that are generating more defects. For example, a piece of code that deals with reporting might be giving lesser number of defects whereas a piece of code that does financial transactions might be generating more defects.
Defect Distribution = Total Number of Defects/Functional Area
If you are using a good defect management tool, then all the time stamps, defect counts etc. and other parameters can directly be obtained via reports and dashboards. Many of the advanced commercial tools provide these metrics out of the box.
Defects come with a cost and the cost is really heavy if defects happen to escape through to production. Defect management is integral and most important aspect of software development and needs to be given utmost priority
One should design a thorough defect management strategy, specifically for larger projects and put in good efforts in the below –
- Improve software development practices for lesser defects in the first place.
- Define defect metrics for reporting and continuous improvements
- Work with a defect tracking and management tool rather than emails or spreadsheets.
- Aligning testing and development teams with the overall defect management strategy.
The market is highly competitive and a single defect that reaches end users can make your software look in-competent and unprofessionally done.
Do share your thoughts around defect management with our readers via comments below. Happy defects management. Cheers!