How Do You Track and Manage Defect Clustering in Jira?

Hi everyone,

We’re currently facing a challenge in our testing process and would love to get your insights on how you handle defect clustering. We use Jira to document our bugs, but we don’t track which feature is affected. Our setup includes a lot of services and clients, and we want to understand which features are the most affected to improve our test strategy in these areas.

I’m considering introducing a new field in Jira to track the affected feature, but we have so many different features that the list would be very long. Alternatively, we could use labels, but I’m concerned that people might use different labels or forget to apply them consistently.

How do you manage defect clustering in your testing? Do you use fields, labels, or another method to track the affected features? Any advice on best practices or lessons learned would be greatly appreciated!

Thanks in advance for your help!

3 Likes

Are each product/service/client for which testing happens using the same test strategy, done by the same persons, with the same testability, coverage, depth of testing, and complexity of service?
Are all bugs reported in the same place? (e.g. does no tester talk to a dev to fix a problem without reporting it?)
Isn’t the person testing more in tune with the coverage and information found in the area tested, assuming they are professionally testing something and have reasonable coverage based on the risks and testing mission?

From the outside, it looks like there’s a desire to change a strategy based on the bugs found, which I think is a bad idea - as any guess of strategy change based solely on the bugs can have a 50% chance of missing the point of why there are/aren’t problems found in a place…

And no, I haven’t used before Jira flags to label bugs solely for test strategy adjustments.
Here are some reasons why we’d flag bugs:

  • link to an epic/story/task, so when the development or refactoring is happening some bugs are considered;
  • backlog management, identify how the backlog owner is using it and how they classify the tickets, ideally, you want to make it easier for them to see interesting issues;
  • there are product development teams owning groups of products/services, so ideally, a bug is flagged to be part of that group and visible to the appropriate team;
  • finding duplicates(if a bug already exists); sometimes it’s easier to filter by a component/label; and that needs to be an agreement between team members;
    Anything would do here and I probably used most options: labels, title keywords, components, link to another ticket, change to type child of dev. epic, collect all bugs under a task, … I wouldn’t overthink it.
  • I’ve used labels and they work fine, yeah, someone could forget to select the proper one and any other field/info in the Jira ticket but I think it’ll take a small amount of time to deal with this and there won’t be lot’s of tickets without or incorrect label.
  • If your features are basically separate microservices/web apps then you can also use different projects in Jira you can even use different projects for different features or parts of the app this would be a more high-level way to track bugs and tickets in Jira. Link bugs to feature tasks (epics/user stories/etc).
  • You can even use a particular template for the title (but it can be a bit trickier to filter tickets in Jira, e.g. [Payment] [Setting] {{bug_title}}, [Payment] [Form] {{bug_title}}, [Subscription] [Management] {{bug_title}}, etc at least it’ll be obvious when you the list of tickets :slight_smile:

This stuff works for me always, maybe this requires some attention and manual work but this works and it’s simple, I don’t see any reason to look for any more complicated ways to track bugs in Jira and match them with particular features and get your stats and do whatever you want with it :slight_smile: this is not ideal and it’s fine and better than nothing :sweat_smile:

Jira Dashboards is one of the best ways to manage the defects
Here are the steps I follow

  1. Define the component for the feature.
  2. Create the pie charts basis the components
  3. Every bug reported should contain these as a thumb rule. Any outliers will clearly show up on dashboard.
  4. One can also use this method to identify regression tests for impact analysis

we use synapseRT (jira plugin) to manage it and build the relationship among stories, test cases and bugs. Each test case should be accociated with a story, each bug should be accociated with a test case. therefore, a bunch of bugs point to certain stories/features. it is easy to track those bugs which are linked to stories.

I wouldn’t limit my testing to a story.
I’d think also about things that haven’t been specified, haven’t been considered, are implicit, or are a combination of stories.
Products evolve, things get left behind, patch stories or a new version of the same story appears. For a product with a large history, I’ve seen finding anything in the tracking system can be painful.

Users don’t use stories, they interact with a product, a lot of the time in an unpredictable way.