DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > Bugs: Prioritising by Bucket

Bugs: Prioritising by Bucket

Mark Needham user avatar by
Mark Needham
·
Dec. 22, 10 · Java Zone · Interview
Like (0)
Save
Tweet
5.23K Views

Join the DZone community and get the full member experience.

Join For Free

At a lot of organisations that I've worked there is a tendency to prioritise bugs by a priority bucket.

We might therefore have priority buckets 1-4 where the bucket number indicates how important the bug is to fix and then any buckets ranked below 4 would not be fixed but would be logged anyway.

From what I've noticed this isn't a particularly effective way of managing bugs.

To start with there tend to be a lot of discussions around what the priority of each bug should be where a QA will argue that it should be a higher priority while a developer disagrees.

I'm not convinced that we actually get any value out of these discussions.

Another thing that I've noticed recently is that developers are much less motivated to fix bugs if they've been put in Bucket 4 rather than one of the higher priority buckets.

I think a better way to solve this problem is just to store whether or not we're going to fix the bug before the next release or not. We can then list them in the order that they should be fixed as well.

It's a much simpler binary categorisation and there's no stigma attached to picking up a 'low priority' bug because each bug picked up is just the next one on the list.

We did this on one project I worked on and it was interesting to notice the number of bugs the client was completely disinterested in fixing before the next release because they just weren't that important.

I'm not convinced the same thing would have happened if we'd categorised by bucket.

The added benefit of this approach is that we can avoid discussions where we identify how many bugs of each category have been identified each iteration.

In some organisations the ability to detect higher priority bugs is an indication of the quality of QA work but I don't believe this is a useful metric to track.

 

From http://www.markhneedham.com/blog/2010/12/12/bugs-prioritising-by-bucket/

dev Release (agency) Question answering Metric (unit) IT

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Unit vs Integration Testing: What's the Difference?
  • Usage of Java Streams and Lambdas in Selenium WebDriver
  • CSS Position: Relative vs Position Absolute
  • Data Visualization of Healthcare Expenses by Country Using Web Scraping in Python

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo