So you’ve done what the case before you demands of you. Congratulations!
FogBugz provides a few different options for Resolving and Closing cases, and they mean different things for your workflow.
Resolved (Won’t Fix)
Maybe your team has reconsidered the value of that new feature. Maybe you just don’t have time. Regardless, you’ve decided that you’re not going to fix this bug. Resolve (Won’t Fix) and move on.
Resolved (Fixed) is for when you fix an issue, and it then gets assigned back to the opener of the bug for verification. This is because you’ll find that about 20%-25% of the time the bug that the developer “fixed” was not the bug that the original reporter saw. It’s important that the original reporter of a bug gets a chance to find out it’s fixed and double check that it really was fixed.
An important distinction between Resolved (Won’t Fix) and Resolved (Fixed) is that Resolved (Won’t Fix) cases don’t count toward an estimators history in Evidence Based Scheduling.
This essentially functions as a way to merge two cases. If you resolve Case 1248 as a duplicate of Case 1093, the events from both cases will appear in Case 1093, and there will be a note at the top of case 1248 that it’s been resolved as a duplicate of 1093 (with a handy link to 1093).
Resolved (Waiting for Info)
This option lets you set a case aside until one of two things happens. If you choose a date for reactivation, it’ll pop back into your active cases on that date. If you set it to reactivate on another case, it’ll pop back into your active cases when the other case is resolved.
Resolved (By Design)
Sometimes a tester or support engineer who reports the bug has misunderstood a spec, and the behavior they’ve reported is actually as intended. In these cases, you can Resolve (By Design).
A closed case is meant to be forgotten about. It won’t appear in your “My Cases” filter (or any filter searching by “AssignedTo:”).
Send & Close
When we reply to a customer, we almost always do so using ‘Send & Close,’ which sends the email and then closes the case. This behavior implies that we consider our work done until the customer responds, either because we’ve solved their problem (hopefully) or because the customer needs to provide additional information in order for us to continue troubleshooting. (If you use Send & Close, be sure to make this workflow modification to help things stay in line).
Elinor opens a bug and assigns it to Isaiah.
Isaiah fixes the bug and marks it as “Resolved (Fixed)”, which automatically assigns it back to Elinor.
Elinor sees that Isaiah has fixed an ancillary problem, but not the one she was trying to get fixed. She reactivates the case, clarifies her bug report, and assigns it back to Isaiah.
Isaiah now realizes that this report is actually for a bug that’s already a known issue opened by Antonio and which is assigned to Marlene. He resolves the case as a duplicate of Marlene’s case.
Marlene fixes the bug and Resolves (Fixed) the case. The case is reassigned to Anthony.
Anthony is happy with the result and closes the case.