Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Optimizing the Defect Lifecycle – with Resolution


Published on

*** Visit for more articles, papers, and presentations. ***
Just as defect reports provide valuable insight into the types of common classes of defects that have occurred in the past, analysis of other attributes can provide useful information for improvement. One of the classifications that can be applied to a defect would be its resolution.

Not all defects are simply fixed by development. Without specific tracking of defect resolutions, the true defect find rate and defect clustering in the code is obscured by duplicates, not repros, by designs, and enhancement requests.

In this presentation, we will look at the implications of how including a resolution attribute as part of your defect reports can help optimize the one of the core processes related to developing software. We will explore how we can use this field to facilitate process automation and data collection to help make team interactions more efficient and that the right people are making the decisions about product functionality.

*** Delve deeper into these and other software testing and quality assurance topics simply by visiting

About Trevor Atkins
Trevor Atkins (@thinktesting) has been involved in literally 100’s of software projects over the last 20+ years and has a demonstrated track record of achieving rapid ROI for his customers and their business. Experienced in all project roles, Trevor’s primary focus has been on planning and execution of projects and improvement of the same, so as to optimize quality versus constraints for the business.

Published in: Software
  • I presented “Optimizing the Defect Lifecycle – with Resolution” to, the Vancouver Software Quality Assurance User Group. Subsequently I presented it to the Southern Idaho Society for Software Quality Assurance and UBC Continuing Studies (, and I wanted to share that material with you.
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Optimizing the Defect Lifecycle – with Resolution

  1. 1. Optimizing the Defect Lifecycle – with Resolution Silverpath Technologies Inc. Thinking Through Testing
  2. 2. 2 Opportunity for Improvement  According to a National Institute of Standards and Technology study:  Software errors cost the U.S. economy an estimated $59.5 billion annually, or about 0.6% of the GDP  80% of the software development costs of a typical project are spent on identifying & fixing defects  About 1/3 of these costs, or an estimated $22.2 billion annually, could be eliminated by an improved testing infrastructure - NIST 2002-10 Report
  3. 3. 3 The Defect Lifecycle  Often channels the majority of the project team’s interactions  Challenge: “Teflon” culture and/or excessive dialogue or "churn" around addressing issues  Challenge: Decisions about functionality made by team members who are not in that role Defects Issues Tasks Ready Complete Progress Status Project Communication Hub  A core process in any company that produces software  Makes for an important area where a little effort can give big returns…
  4. 4. 4 So, You Have Found a Bug  What happens next?  How is that quality report handled?  How is it investigated?  How is it determined to be resolved?  How do we manage the intense communication that occurs as a project enters into its testing cycles  How do we track & lower the costs of these activities?
  5. 5. 5 Leverage Defect Resolution  Obtain an accurate picture of the defect counts by providing the right set of choices for resolution  Drive ownership & closure of the issue through process automation But not all defects are resolved “fixed”! Start Open Resolved Closed Deferred Defect reported Defect fixed Defect confirmed fixed Defect is not fixed End Defect to be addressed later Simplified Defect Lifecycle
  6. 6. 6 Example Defect Resolutions  Fixed: The programmer says it's fixed. Check it  Need Info: The programmer needs more info about the bug. Elaborate, talk to them  Duplicate: This is a repeat of another bug report. Cross reference it on this report  3rd Party: This bug lies in code outside of the software under test  Deferred: It's a bug, but it will be fixed later. Reopen at the scheduled time. Aka: Postponed  Cannot Reproduce: The programmer can't make the failure happen. Confirm it still happens, add details, notify the programmer. Aka: Not Repro  By Design: The program works as it's supposed to. Get confirmation, update your tests. Aka: As Designed  Spec Issue: The program works as documented, but maybe the requirements are wrong, incomplete, ambiguous, etc. Appropriate new issue opened after discussion & decision is made. Aka: Requirements Issue, Enhancement, Feature Request
  7. 7. 7 Resolution Implications  Each resolution option should make sure the right questions are asked of the right people:  Who decides how the issue is to be truly resolved?  Who is assigned the issue next?  Resolution data can also be leveraged to make broader observations & conclusions from trends, eg:  Do the testers need more testing or product training?  Are the requirements or design poorly captured?  Is technical debt becoming an issue?  Which resolution options would help with each?
  8. 8. 8 Consider Roles on the Project Team  Product Management: must decide product behaviour & priorities  Project Management: negotiates scope & priorities vs. constraints (schedule, resources, etc)  Business Analysis: describes the product behaviour to be implemented  Development: implements the described product behaviour  Testing: verifies the implemented product behaviour against what was described; connecting the other roles with information Development Product Management Business / Requirements Analysis Project Management Testing Defined Product Behaviour Decided Product Behaviour Scope Priorities Constraints Simplified Project Team Interfaces Decided Product Behaviour
  9. 9. 9 Process Automation using Resolution Make sure the right people are making the decisions! Fixed Not Repro By Design Deferred Withdrawn Spec Issue Third Party Product Management Business Analysis Testing For Re-Verification Need Info Resolved Automated Responsibility Assignment
  10. 10. 10 Common Defect Report Attributes  Status  Assigned To  Priority  Severity  Functional Area  Feature  How Found  Type  Environment  Resolution  Opened Version  Opened By  Opened Date  Related Test Case(s) or Requirement(s)  History or Audit Trail  Resolution is just one of many typical fields or attributes:  What other opportunities for efficiency can you find?
  11. 11. 11 Defect Lifecycle Optimization Tips  Defect management needs thoughtful consideration to ensure that communication & turnaround time is as efficient and collaborative as possible  Without specific tracking of defect resolutions, the true defect find rate & defect clustering in the code is obscured:  By Duplicates, Not Repros, By Designs, Enhancements, and Feature Requests  An effective defect lifecycle ensures that:  The highest ratio of valid & unique defects are being reported  Total time required to address each defect is minimized  The right role in the project team is making the decision for each next step in the defect lifecycle  Improved definition & analysis of the data captured can drive improvements in processes and training, resulting in more successful projects!
  12. 12. Thinking Through Testing Thinking Through Testing For our latest updates:  Visit  Follow @ThinkTesting We are always sharing our ideas on crafting “right-fit” approaches to software testing. We are sure you will find something you can apply to your own projects and organizational environment. Discussing "right-fit" approaches for software testing