Gunnar Kudrjavets

Paranoia is a virtue

New resolution type for bugs – "Not a bug"

[GK, 07/10/2004] Please apply 's/Not a bug/Invalid/g' while reading this post. The resolution type is meant to describe the bug quality not the correctness of application's behavior (Thanks, Larry Osterman!) Lesson learned: read and reread the stuff you post ;-)

We’re currently in the process of restructuring our bug database and here’s one thing I have wanted to do a very long time - add a new resolution type called “Not a bug“. I seriously doubt that this proposal will be accepted, but there’s no harm in trying ;-) The current set of values for resolution we’re using is following:

  • By Design
  • Duplicate
  • External
  • Fixed
  • Not Repro
  • Postponed
  • Won’t Fix

When I put on my triage hat then I’m quite passionate about making a very clear distinction between different resolution types. The only way to get any meaningful statistics and take action based on that is to make sure that your data is correct. For years we’ve been encountering some bug entries which we just can’t classify under existing resolution types. They are either bug entries just stating some basic facts without having expected result and actual result being specified; bug entries with content which doesn’t make sense to anyone in the room; general suggestions which are too broad to classify under ‘Suggestion’ type etc.

Typically we just assign the active bug we don’t understand back to a bug opener and send a follow-up e-mail asking additional information. There are a couple of problems with that:

  • People working in test organization tend to care more about resolved bugs than active bugs (your test organization may vary of course). Based on my experience it takes more time to get a response in regards to active bug than resolved bug.
  • Development leads and managers are monitoring constantly active bugs and then we run into "Why SDE/T or STE has active product bug assigned to him? Is he/she going to fix it?" discussion.
  • If we would use any other resolution like "Won’t Fix" or "Not Repro" then this would imply that there is actually bug in the product which we decided not to fix or we desperately tried to reproduce the problem, but couldn’t. This will of course start playing tricks with my beloved figures ;-)

Personally I would like to resolve any bug triage team doesn’t understand as “Not a bug” because this will keep everyone honest. Also I would assume that term ‘Not a bug’ will have bigger psychological impact than “Other” or something like this ;-)

The main justification I’ve been using for this is efficiency. Let’s say that there are 20 people in triage meeting and we spend 3 minutes per every triage discussing bugs nobody understands, deciding should we either resolve it, should we ask for the additional information, to whom to assign this bug etc. Practically we just spent 1h in total of people’s time instead of making a quick decision and moving on.

It’s a bug world and I think good way to mock my post is to say that we should be also using tabs instead of spaces, because this will help us to save hard disk space ;-) This is what I call self-critical cynicism ;-)

Posted: Jul 10 2004, 02:59 PM by gunnarku | with 9 comment(s)
Filed under:

Comments

Gunnar Kudrjavets [MSFT] said:

Thanks, Brant! This is very informative, "Invalid" is much better name than "Not a bug".
# July 10, 2004 6:42 PM

Larry Osterman said:

What's the difference between "By Design" and "Not a bug"?
# July 10, 2004 7:51 PM

Larry Osterman said:

Brant's right - invalid is a better term.

Not a bug is a comment about the behavior of the application, not the quality of the bug report, invalid is a comment about the quality of the bug report.
# July 10, 2004 7:52 PM

Drew said:

It might be nice to have a metric for the quality of the bug report. That could handle the "what the heck does this mean" bugs and would also be beneficial for testers when at review time. The only bug-finding metrics I've seen used for testers at review time are total bugs found and total (or percent) fixed. Neither of those are great for testers who find deep bugs and take the time to fully understand and describe them well; those systems reward testers who find many "shallow bugs". Those metrics also encourage filing many bugs instead of logically grouping related problems into a single bug. (Can you tell that I'm a tester who recently wrote his review?)
Or maybe mine is a bad suggestion because it would add too much complexity.
# July 10, 2004 9:47 PM

Gunnar Kudrjavets [MSFT] said:

Good comments, Drew! Cem Kaner has written about bug counts and bug reports quite a lot: http://www.kaner.com/pdfs/bugcount.pdf and http://www.kaner.com/articles.html. I don't fully agree with him and at one beautiful day I plan to write post about bug counts in general ;-)

Back to metric. Measuring bug counts blindly is definitely a very bad idea. Measuring them intelligently is hard to accomplish and requires lots of precision when it comes to making sure that the priority and severity of bugs is taken into the account, specifics of the area (basic GUI vs. kernel crashing bugs for example), usefulness of every bug, all triage teams use the similar standards etc. For a while I’ve been planning to have every bug to have a weight describing its “usefulness” (1..n). Simple example: one bug which describes a major security hole is order of magnitude more useful than ten little bugs describing typos in documentation, a couple of pixels off in GUI etc.

This is tough subject to discuss.
# July 10, 2004 10:36 PM

Larry Osterman said:

I feel obliged at this point to include the following link: http://weblogs.asp.net/larryosterman/archive/2004/04/20/116998.aspx

It's about measuring testers by the quantity of their bugs (as opposed to the quality of their bugs)
# July 10, 2004 11:45 PM

Shrini K said:

Hi Gunnar
This is precisely we were discussion some time back. Wow --- Exactly some kind of arguments and thoughts. here are my views on this post.

1. you dont seems to address question by Larry - "what is difference between "By design" and "Not a bug" kind of resoution.
For me both look same and can be used interchably.
Your views...?

2. IMHO, It is not proper to call everything that triage team is not sure about as "not a bug" - we may be missing real bug there. The missing thing might be the way the bug is written. That brings me to next point about bug report.

3. Somewhere in between the discussion in this post, it was hijacked and discussion went about discussing about quality of bug report.

3.IMHO, it is also not correct to related "bug report quality" to "bug resolution". I have have used a diffrent field named "Is bug report OK?" and trige team shall update this field. This is one way (metric) of measuring bug report quality.

4.So it is still OK to have a resolution like - "Not a bug" or "By design". IMHO, "Invalid" is a harsh term for bug and can demotivate the person logging the bug.

5. One last word w r t Product studio - Microsoft's bug tracking application. I could not get any entry (drop down value) introduced as "Not a Bug" even though I am admin on the PS database.

Great post and lot to learn in terms of bug life cycle. Thanks for this

Shrini
# July 26, 2004 4:58 AM

Brandon Paddock said:

Shrini K,

I think the idea is that "Not A Bug" does not mean "This is not a bug in the program." That's what "By Design" means.

Instead, "Not A Bug" in this case means "Not A Bug Report" - thus, "Invalid" is a much better name for this resolution... as it better communicates that the problem is in the bug report itself, not in the program.

It can be a hard distinction to explain, as I've just found :) But I definitely see the difference. Or at least I think I do ;)
# July 26, 2004 2:45 PM

Dora said:

Sorry. It is fortunate to be of high birth, but it is no less so to be of such character that people do not care to know whether you are or are not. Help me! Need information about: Turbo tax and netfile. I found only this - <a href="turbo-tax.biz/">turbo tax deals</a>. Turbo tax, the forensic center brings varieties visiting a well-known half to expeditions looking panels of once 20 use. Turbo tax, at that merchant, i drafted myself too began in the case of the act. With respect :o, Dora from Germany.

# March 26, 2010 8:17 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)