Open Category List

What to do when there is a significant increase in the number of bugs reported on a specific component?

2 minutesread
  • Home
  • /
  • Knowledgebase
  • /
  • FAQs
  • /
  • What to do when there is a significant increase in the number of bugs reported on a specific component?

As testing is executed by the Applause Community, the testers will be submitting issues when encountered. Based upon your product and test cycle settings, each issue reports will be assigned to a single product component. Utilizing this functionality allows you to quickly identify the areas in the tested product, website, app or software build with most quality issues, thus focusing you and your team when handling, prioritizing and ultimately fixing them. Learn more about the benefits of using product components here. Over time, trends in the number of issues assigned to components may draw your attention, specifically when you see a significant increase. Such shift in the number of issues is likely to also be reflected in your build’s Applause Quality Score and not always for the better, and you may find yourself asking why – and what to do next.

First, it is important to acknowledge that the submitted issues are the symptom, not the cause. While intuitively having more submitted issues hints on greater quality problems with the product component, however in fact it may also potentially mean that the build was simply tested differently than before. Thus, further investigation might be due, to identify whether the increase indicates on matters directly related to the quality of the product component or a result of the implemented testing strategy. 

Here are a few directions to follow up on if you sense that the product quality resulted in the increase in submitted issues for a specific component:

  1. Is the product component disproportionately represented in the scope of new functionality delivered in the tested build? New functionality should be more prone to errors in design and implementation before the feature stabilized.
  2. Were there any time or other constraints that dictated rushing the build through internal processes while skipping critical steps such as code reviews and unit tests?

Obviously, none of these directions might be applicable, and yet the tested component is still “buggy”. This indeed might be a result of poor quality built into the product. But, in some cases it’s not that the product quality deteriorated, but that changes implemented to the testing strategy yielded more issues than usual.

Here are a few directions to follow up on if you sense that the testing strategy resulted in the increase in submitted issues:

  1. Was testing scope expanded beyond what is executed regularly to focus on the component? Clearly testing more time and/or product functionality increases the probability of finding more defects.
  2. Is there a specific issue that’s blocking the testers from properly testing the product? Oftentimes matters like incorrect access permissions, bad test data, a malfunctioning service or other infrastructural aspect of the testing environment as well as similar issues may present themselves to the end users as software defects.
  3. Has the list of known issues – specifically those known for the product component – been changed or not kept up-to-date prior to testing? It might be that the testers are unaware of previously-found issues you already prioritized.

Whatever the issue, you are advised to collaborate with your Applause team to further troubleshoot the causes for the increased number of issues reported on a specific component, and identify improvement opportunities in your processes and testing strategy. 

0
0
70
2 minutesread

Related Knowledge Base Posts