Sunday, June 16, 2013

Creating an effective defect report

It's easy to monitor on defects, but when you start reaching your 1000th defect and you keep track of all kinds of data, you might start loosing control on what the actual quality of your application might look like. You start to lose overview on where the issues lie and what actions need to be taken to control product quality within delivery time. You drown in the graphs you need to present and in stead of reading your report yourself and making the correct conclusions, you'll use your energy creating the shiny report that nobody reads.

Many test coordinators and test managers let themselves drive by all the information available and recorded in the defect registration tool, presenting all kinds of exotic graphs but at the same time lose focus on the actual reason of the defect report - Giving insight in product quality.

So how do we provide insight in product quality, making use of a defect report?

1. First of all, before starting to report, you need to get data in the defect registration system.
You only  want to capture data that is useful to show product quality. All other data is waste.

  • Divide your software into logical blocks to report defects on (Using functional and technical blocks) to report defects on eg: Intake; Contract; Interfaces System A; Interfaces System B,... Make sure you don't have more than 9 of those. If you have more, regroup.
  • Define defect priorities and/or severities : 'Urgent - High - Medium - Low' will do for starters
  • Defect statuses to report on do not equal your actual defect statuses - simplify and group them for a report. Use:
    • Open (For the developer to pick up or to resolve)
    • Closed - Rejected (Closed - Agreed not to fix)
    • Resolved (Needs a retest)
    • Closed - Fixed ( Closed and fixed)
    • Escalated (No agreement found - needs to be taken up in a defect board)
  • You want to know what the actual issue was of defect when it is being resolved. This can be data, test, design, front end code, back end code, business rule, migration... again make sure you don't have more than 9

2. Present your data in a way that anyone can understand what you want to show.

  • The titles of the graphs you present, should be meaningful and unambiguous
  • The report should be printable on maximum 2 pages and still be readable
  • Use the correct chart types to display what you want to show. Trend views are no luxury. 
  • The colors you present need to be in line with their meanings
  • Always provide an interpretation. A report that only shows metrics is can be easily misunderstood.

An example of how a defect report could look like, is shown below:


  1. Superb. I really enjoyed very much with this article here. Really it is an amazing article I had ever read. I hope it will help a lot for all. Thank you so much for this amazing posts and please keep update like this excellent article.thank you for sharing such a great blog with us. expecting for your.
    Digital Marketing Company in India
    seo Company in India

  2. Thanks for such a great article here. I was searching for something like this for quite a long time and at last, I’ve found it on your blog. It was definitely interesting for me to read about their market situation nowadays. Well written article Thank You for Sharing with Us pmp training centers in chennai| pmp training in velachery | project management courses in chennai |pmp training in chennai | pmp training institute in chennai |

  3. java
    Very good information. Its very useful for me. We need learn from real time examples and for this we choose good training institute, we need to learn from experts . So we make use of demo classes . Recently we tried java demo class of Apponix Technologies.


  4. Amazing Article ! I have bookmarked this article page as i received good information from this. All the best for the upcoming articles. I will be waiting for your new articles. Thank You !
    DevOps Training in Chennai

    DevOps Course in Chennai