When I resolve an issue (as a dev), I do not get the reporter's name in the "assign to" drop down.
I thought this would have been standard functionality.
I could probably play around with the settings to allow this, is this true?
But perhaps I am doing something wrong, is there a prefered workflow?
We used to have a status "Target Testing" where the dev would assign back to the reporter, who would test and close.
Can somebody poease help me with the "best practices" workflow.
Thanks
Rich
Workflow: Send back to reporter for testing
Moderators: Developer, Contributor
-
tfab
Only Developers show up in the Assign To: list.
The implied workflow for the tool is as follows:
New -> (Acknowledged, Confirmed) -> Assigned -> Resolved -> Closed
where Assigned implies that the task is being worked on, and Resolved implied that a fix is available. Closed can indicate that the fix is released.
One method of dealing with this is for reporters to watch for the issues that they reported going to a resolved status. They can retest at that time. A reporter can re-open, or close an issue from the Resolved status (assuming that the appropriate flags are set). Some users even add an additional "tested" state between Resolved and Closed. This requires the reporter or tester to move the issue to this status before the issue is closed.
One disadvantage of re-assigning the issue to the reporter is that the original handler information becomes obscured, and it is more difficult to re-open the issue from a manaagement perspective.
The implied workflow for the tool is as follows:
New -> (Acknowledged, Confirmed) -> Assigned -> Resolved -> Closed
where Assigned implies that the task is being worked on, and Resolved implied that a fix is available. Closed can indicate that the fix is released.
One method of dealing with this is for reporters to watch for the issues that they reported going to a resolved status. They can retest at that time. A reporter can re-open, or close an issue from the Resolved status (assuming that the appropriate flags are set). Some users even add an additional "tested" state between Resolved and Closed. This requires the reporter or tester to move the issue to this status before the issue is closed.
One disadvantage of re-assigning the issue to the reporter is that the original handler information becomes obscured, and it is more difficult to re-open the issue from a manaagement perspective.
-
DJ Zany
Thanks for the reply.
Interesting... We ALWAYS insist that the person who raised the defect (or a member of the same team), is responsible for testing the defect once the dev believes it to be fixed.
The dev puts it into target test against a version, and this version is regression tested, and tested for each of the fixed defect, by the testing team before release. There is no way that the dev can close the defect without it going through this process.
I will play around with additional states and transitions (eg "tested" as suggested) and post back here with my experiences for tfab, and anybody else who is interested in working this way. (I hope Mantis is flexible enough)
Rich
Interesting... We ALWAYS insist that the person who raised the defect (or a member of the same team), is responsible for testing the defect once the dev believes it to be fixed.
The dev puts it into target test against a version, and this version is regression tested, and tested for each of the fixed defect, by the testing team before release. There is no way that the dev can close the defect without it going through this process.
I will play around with additional states and transitions (eg "tested" as suggested) and post back here with my experiences for tfab, and anybody else who is interested in working this way. (I hope Mantis is flexible enough)
Rich
In one of the installations I done I used the following states:
- new
- acknowledged
- in progress
- failed
- fixed
- tested
- resolved
- closed
The developers would put the defect "in progress" when they start working on it. Once they are done with the fix, they move it to "fixed". Developers usually use filters that hide issues that are higher at "fixed" or higher. That is why "failed" must be smaller than "fixed".
The test team then filters on issues that are fixed state, test them, and move them to either "tested" or "failed". If "failed", then the developer works on it again.
The manager can then move the issues from "tested" to "resolved" or "closed" as per the company process.
I hope this would be useful.
Regards,
Victor
Mantis to Go?
http://www.futureware.biz/mantisconnect
- new
- acknowledged
- in progress
- failed
- fixed
- tested
- resolved
- closed
The developers would put the defect "in progress" when they start working on it. Once they are done with the fix, they move it to "fixed". Developers usually use filters that hide issues that are higher at "fixed" or higher. That is why "failed" must be smaller than "fixed".
The test team then filters on issues that are fixed state, test them, and move them to either "tested" or "failed". If "failed", then the developer works on it again.
The manager can then move the issues from "tested" to "resolved" or "closed" as per the company process.
I hope this would be useful.
Regards,
Victor
Mantis to Go?
http://www.futureware.biz/mantisconnect
-
DJ Zany
Thanks for the tips Victor!
I had one more requirement, that is that I must be able to assign the bug back to the reporter.
I have done it, and all through the GUI, so well done Mantis!
What I did:
Changed all my testers to updater role.
Manage | Manage Configuration | Workflow Thresholds and allowed the Updater role to handle and assign bugs.
I could have created a new role, or changed the name to futher refine this.
Now I get the workflow I wanted.
Next I will probably refine the statuses as discussed above.
Happy that Mantis fits my requirements.
I had one more requirement, that is that I must be able to assign the bug back to the reporter.
I have done it, and all through the GUI, so well done Mantis!
What I did:
Changed all my testers to updater role.
Manage | Manage Configuration | Workflow Thresholds and allowed the Updater role to handle and assign bugs.
I could have created a new role, or changed the name to futher refine this.
Now I get the workflow I wanted.
Next I will probably refine the statuses as discussed above.
Happy that Mantis fits my requirements.
Hi All,
Sorry to come back monthes after the end of this post...
thraxisp said :
Some users even add an additional "tested" state between Resolved and Closed. This requires the reporter or tester to move the issue to this status before the issue is closed.
how is it possible to add a new state ? I would like to add a state "to test". This state will be set after the resolution of a bug before the end of the workflow.
This is linked to the first question of askeing the reporter to test but in my company, we do not want to ask the reporter but any reporter...
Thnaks for your help.
Greg
Mantis V101
Sorry to come back monthes after the end of this post...
thraxisp said :
Some users even add an additional "tested" state between Resolved and Closed. This requires the reporter or tester to move the issue to this status before the issue is closed.
how is it possible to add a new state ? I would like to add a state "to test". This state will be set after the resolution of a bug before the end of the workflow.
This is linked to the first question of askeing the reporter to test but in my company, we do not want to ask the reporter but any reporter...
Thnaks for your help.
Greg
Mantis V101
Hi All,
The answer to my question...
http://manual.mantisbt.org/manual.custo ... values.php
Regards,
Greg
The answer to my question...
http://manual.mantisbt.org/manual.custo ... values.php
Regards,
Greg
But you didn't get the ability to reassign to Opener..
I also have been wishing for this functionality. Although I have done the same as you, I still would like to have the issue assigned to Reporter when it's resolved.
DJ Zany wrote:Thanks for the tips Victor!
I had one more requirement, that is that I must be able to assign the bug back to the reporter.
I have done it, and all through the GUI, so well done Mantis!
What I did:
Changed all my testers to updater role.
Manage | Manage Configuration | Workflow Thresholds and allowed the Updater role to handle and assign bugs.
I could have created a new role, or changed the name to futher refine this.
Now I get the workflow I wanted.
Next I will probably refine the statuses as discussed above.
Happy that Mantis fits my requirements.
Additional information
I have exactly the same problem/request.
1) I need to return the issue back to the reporter (for testing)
2) I need to get an feedback from reporter (if he didn't report enough information)
The only way is to set testers as developers which breaks philosophy of roles in mantis.
Could anybody help me, please?
Thank you,
mirousek
1) I need to return the issue back to the reporter (for testing)
2) I need to get an feedback from reporter (if he didn't report enough information)
The only way is to set testers as developers which breaks philosophy of roles in mantis.
Could anybody help me, please?
Thank you,
mirousek
What's the best process for resolving a bug to reporter?
I've implemented some of the recommendations in this thread, specifically allowing reporters to handle issues which at least now allows me to assign the issue back to the original reporter.
Currently I have my developers first assigning the bug back to the reporter and then going back to the bug again, then changing the status to resolved and changing the information.
I don't like this, two very unnecessary steps. I would prefer that when resolving an issue its automatically assigned back to the reporter, or rather I'd prefer a dropdown for assigning the bug and the reporter is automatically selected.
Maybe this is a feature request for Mantis? Maybe there needs to be a field that tracks who originally opened the issue and a field for whoever is currently assigned the bug.
Currently I have my developers first assigning the bug back to the reporter and then going back to the bug again, then changing the status to resolved and changing the information.
I don't like this, two very unnecessary steps. I would prefer that when resolving an issue its automatically assigned back to the reporter, or rather I'd prefer a dropdown for assigning the bug and the reporter is automatically selected.
Maybe this is a feature request for Mantis? Maybe there needs to be a field that tracks who originally opened the issue and a field for whoever is currently assigned the bug.