A forum for technical support discussion related to Fogbugz.
The current workflow of FogBugz where it assigns a case back to the originator when it's resolved doesn't always seem appropriate to me. I can see that for customer support incidents but for bugs in a product development context, every process I've seen would always send next to a QA lead for testing.
I would very much like to see the ability to specify a user per project that is the default assignee for cases marked resolved. Right now, when I see a bug come back to my inbox because it's marked resolved, I have to go through the motions of assigning it over to someone else. After doing this enough times, I start to think that taking care of this grunt work for me is what computers are good for. ;-)
Yes, there does seem to be a need for a "ready for test" stage in the workflow. The simplest solution is to train your developers to not resolve the case but assign it to QA.
Thursday, December 1, 2005
This is the same issue that we have found trying to incorporate the testing cycle into fogbugz. Most of our cases will be coming from e-mail to a generic mailbox that auto-sorts them. This makes all the new cases to be created by the Administrator and therefore reassigned to the administrator when they are resolved.
Is there anyway fogbugz could take into account the workflow steps that an organization like ours has?
More specifically, are Case goes through the following steps:
5. Testing (Post-deploy)
We would love it to be able to specify the movement of a Case from one step to the next and the step contain an auto-assign person that could be set. (ie. If mark for Testing our Q/A Lead for that project would automatically get assigned the task.)
Thanks for the consideration.
>>The simplest solution is to train your developers to not resolve the case but assign it to QA.
True, but it becomes extremely problematic to distinguish cases which need work from cases which are being worked on from cases which are ready-to-test from cases which are ready-to-ship when the status of all of them is "active" and you rely on whether the case is assigned to Bob, Joe, or Dave to determine what its status really is.
In a workflow environment, there really are more than two states for a case (active or resolved). The "Resolve" action implies a resolution which may not be true when the case is simply moving through other states of the workflow. But "Resolve" is the only way to change the status even when you've edited the Status table in the database to include the various workflow states.
I fully second this feature request. We have only been trying out the system for a week or so now, and already I am spending a lot of time assigning cases en-masse to QA, as often the cases have arisen outside of QA.
Given that Joel himself heavily evangelises on the benefits of a test team I am surprised that the Fogbugz process doesn't support such an obvious step in the flow.
I love the product in general and am keen to use it, but I am finding during our eval that I am spending time defending it from several complaints, all of which appear trivial to address.
Having a default assignee for Resolved cases for a project would be a great improvement.
Friday, December 2, 2005
This topic is archived. No further replies will be accepted.Other recent topics