Analysis of Defects, “The Defect Analysis Report”

Reporting is one of the crucial aspects of testing or shall I say one of the major criteria’s that talks about the road bump one has traversed through. It also helps in planning to build the future road much smoother than before. In other words, such reporting helps us learn from the past and build a more quality oriented software and helps to reduce the bugs, post analysis of there pattern.

So, What is a Defect Analysis Report? [Quoting from my own reference]

A defect Analysis Report is a document that helps to provide analysis of the bugs logged  in a release/sprint or throughout the lifecycle of a project  into different categories, thereby providing an insight of improving the quality of software by taking corrective measures for the AUT

Let’s see what are the peculiarities included in a defect analysis report:

  • First and foremost, the report should highlight the number of logged defects based on their statuses.
     

Number of bugs logged based on statuses

This categorization should include all the bugs logged based on their statuses, this helps to see the overall stability of the application. This is also one of the important parameters of acceptance of the software post a release.

  •  The second characterization is based on the number of bugs versus modules/features
       

Number of bugs logged versus modules of the AUT

This provides detail about the number of bugs occurring across the features. It indicates buggy areas of the application categorized in terms of features

  • The third categorization is based on the number of bugs versus severity and bugs versus priority
          

Bugs Versus Severity

   

Bugs Versus Priority

This categorization helps stakeholders visualize the impact of the bugs logged and their corresponding importance. It helps them evaluate the quality of the software by these parameters.

  • The fourth categorization is crucial and important in terms of analysis of reports. This deals with the number of times the bugs were reopened. The reopened areas highlight the most impactful areas of the application and should be more focused while testing them in upcoming releases
Number of bugs reopened versus Module

The above tabular data helps in identifying that the ‘category listing’ feature needs more focus and deep driven testing as compared to the others due to its instability.

  • The fifth categorization is also important and deals with the root cause of the defects. So basically root cause helps to find reasons behind bugs so that corrective measures can be taken to ensure they do not reoccur and are one of the important segments that become part of a closure report in the form of learnings.  
     

Root cause versus the number of bugs

In the above tabular data, we divide the bug into types of categories that cause the issues, for example, the major reasons behind bugs were Logic issues, which could be either due to lack of knowledge of the code of intertwined features or lack of understanding of business use cases. The same goes out to Integration issues, these days we have a lot of third parties been integrated into the software, be it a payment gateway, mobile service provider, background verification organizations etc. All of these required that there API’s are studied thoroughly, any scenario left lead to integration issues.

  • The sixth categorization may be used for internal purposes, just to evaluate the quality parameter measured across each developer. In this, the number of bugs raised across developer is measured. This measurement stands valid in case of an agile model where user stories/features are assigned to each developer and the number of bugs logged across each story. This helps the organization identify the developers whose work needs more detailed code review and the ones who have keen eyes towards quality.
Note: This categorization can be removed while sending the report to the client and should be used only for internal purposes.
There are optional items that can also be included and categorized with the number of bugs based on sprint or releases/milestones if we are creating a defect analysis report for the complete project. 
Defect analysis report should be created post every release and shared with the related stakeholders, this helps to provide an insight of the project and its stability. Analysis of the report within the testing team helps to build better testing strategies, focus on more bug-prone areas and helps to reduce invalid bugs.


“If we want to be serious about quality, it is time to get tired of finding bugs and start preventing their happening in the first place.” Alan Page


Author: Sadhvi Singh
Linkedin: https://www.linkedin.com/in/sadhvi-singh-86a85b65

     


  •  
  •  
  •  
  •  
  •  

10 Thoughts to “Analysis of Defects, “The Defect Analysis Report””

  1. Thankx for this fruitful comment.

    Keep doing on important topics of testing.

    God bless!!!!!!

  2. Nice blog Sadhvi. Thanks for that…

  3. Saurabh Warghade

    Good explanation…Sadhvi…Thanks

Leave a Comment