Fog Creek Software
Discussion Board

FEATURE REQUEST: Assign ownership of a bug

We have a QA team that's primarily in charge of testing and entering bugs.  However, anyone on the team can enter a bug. 

Our problem is that once a bug has been resolved, it goes back to the person who entered it.  This means that if a developer entered a bug it goes back to them for verification of fix.  This is BAD.  The typical scenario is that one of the developers is working on a particular feature and sees a bug that's not directly related to the feature.  They need to submit the bug to capture the problem, but not be responsible for verifying the fix.

We'd like the ability to assign the bug to a QA person who should verify the fix. This keeps the the developer who entered out of the loop so they aren't bothered with it again.

Clint Edmonson
Friday, December 19, 2003

Actually its not "BAD", quite the reverse as its perfectly reasonable to want a person who identified a problem or requested a feature to agree that its been resolved.

What it is is inappropriate to your environment which is rather different.

From my POV I can see two distinct needs - one is an additional optional/alternative QA step in the workflow, the other is still to assign the ownership which is bound to be useful at some point!

Monday, December 22, 2003


Let me explain some of our thinking behind that. Many times a bug report is entered and then misinterpreted by the person who makes the fix. In my experience this can happen as often as 30-50% of the time.

The purpose of assigning it back to the original person is so that they can check that what they thought was the bug is really fixed. Assigning it to a QA person would eliminate this check.

If you receive bug reports from customers, executives, etc. who you really don't trust to verify the fix, they can enter these bugs by sending email into the system. In this case when the bug is fixed it can be automatically assigned back to a QA person who is responsible for that area.

Joel Spolsky (Fog Creek Software)
Monday, December 22, 2003

Thanks for the feedback.  I should have clarified that it's BAD in our environment.

I understand the motivation behind the design. 

What Joel proposes is exactly what we do.  As a db layer developer, if see a bug in the UI layer (toolbar image wrong, short cut key not working, etc), I send a "fire and forget" email to our QA manager who inputs the bug and assigns to a QA engineer for verification.  In our organization, it's up to the QA engineer to determine if it's actually a bug by checking it against the specs (they're required to fluent in the specs).  If so, it gets assigned to the engineer that developed it.

It's not a huge problem, but it does increases the paper trail in order to keep a developer from being distracted by a bug in another area of the app.

Maybe "Take Ownership" would be a better action to request.  (It could sit next to "Edit | Assign | Resolve")

Let me give you another usage scenario we encounter.  We have spikes in our bug counts based on our milestones, so we often shift technical support reps over into QA to handle any overflow.  We need to be able to assign them bugs from the existing pool, so the load can be balanced between the QA staff.

Also, we occasionally lose a QA employee and need to shift their bugs over to someone else.

Hope these thoughts shed some more light on where I'm coming from.

Clint Edmonson
Tuesday, December 23, 2003

Actually, that's not what Joel was suggesting, he was suggesting something a little more streamlined that may make your lives a little easier. Instead of firing that email to a person, fire it to an email account that is collected by a mailbox in FogBUGZ. Set up that mailbox to assign all incoming email cases to the FogBUGZ account for your QA manager.

This saves the QA manager entering the bug into the system, and it eliminates all those emails that are kicking around outside your issue tracking system. More to the point of your post, when the case gets resolved, the person FogBUGZ will automatically re-assigned it to will be the QA manager.

Dmitri (fogcreek)
Tuesday, December 23, 2003

I understand the suggested work around, but I have to agree that a 'take ownership' or 'change ownership' button would be most helpful instead of having to set up an additional e-mail account.

Debbie Conley
Monday, February 9, 2004

I must say that this issue is the second most important issue from my perspective. (the first being tracking bug resolving and release of versions to testing.)

Yes - the fact that the original submitter gets notification is fine, but that person sometimes does not have the bandwidth or knowledge to figure out that that bug is fixed. That is what QA is for.

The workaround - creating accounts and sending email is not an acceptable one, for practical and theoretical purposes.

Practical - when sending an email one cannot set important fields like "area". One can also not review the description (which is a nice usability thing when entering a case - after submitting it you get to see the result of submission).

Theoretical - One of two things are true - this scenario is invalid, in which case Fogcreek do not want to add the "take ownership" feature; or the scenario is valid, and it is a feature we are considering - here meanwhile is an awkward way to deal with this - sending email.

What I get from Joel's response is ambivalent- it's both somewhat invalid and valid at the same time.

Gil Tayar
Thursday, March 11, 2004

On the same note. The difference between Joel's and Clint's process is that in Joel's environment QA is distributed. In Clint's it is centralized.

Joel is not "afraid" of distributing the testing of fixing of bugs among... everyone.

Clint believes that there must be a centralized place to check bug fixes, or else chaos will ensue.

I definitely understand both views, and would like support for the two environments in fogbugz. As you can imaging, I have a Clint-like environment, and I would assume that most environments out there are like that.

As a way of accomodating both view - instead of adding a "take ownership" feature, one can get the best of both worlds - in the "Resolving" form, let me assign this to somebody other than the owner. In the case that I do - send an email to the assigned person ("please  check this bug") and to the owner ("please know that your bug has been resolved").

Gil Tayar
Thursday, March 11, 2004

On the same note. (I'm on a role here. I hope somebody's listening!)

I was wondering how Joel's environment works when tracking resolves and releases. Specifically:

when resolving a bug, there is no mention anywhere of when that bug is going to be released.

So a person that needs to check that bug does not know _when_ to check it. _Especially_ if that person is not in the QA team and thus does not know when releases come out.

Also - when resolving the developer has no real way of saying what release it is going to be in. Do you use the "fix for" field? The text for that says that it is for saying when the bug would like to be fixed. But I can live with that.

Gil Tayar
Thursday, March 11, 2004

Yes, I use the "Fix for" field for that purpose. Then if you do a filter for all cases for a release, you will see which have been resolved (and closed, if you wish) for that release.

It does mean "Fix for" is overloaded to mean both future and past tense, but the context is usually clear.

Stephen Trier
Friday, March 12, 2004

*  Recent Topics

*  Fog Creek Home