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 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 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.