Reopening a bug in Mantis Bug Tracker
Recently, we published a blog post about a possible bug life cycle for which we received a lot of questions and comments that were very interesting to consider. Among the comments was this recurring question:
Why didn’t you show a bug going into the “reopen” status?
So, we decided to write this post in response, to analyze the option of “reopening” a bug especially when working with the tool, Mantis Bug Tracker.
Here is a diagram of the incident workflow used by Mantis.
In Mantis, Reopen is Not an Incident Status
Notice that Mantis’ workflow does not include the option to mark a bug as “reopened” like other bug management tools such as Bugzilla or JIRA.
Thus, as testers, when we see that a bug hasn’t been fixed, the next step would be to change the status to “assigned” (and add an additional note) so that the developer can revisit the bug.
What Happens if We Utilize the “Reopen” Action?
When installing Mantis, the default settings of the tool make it so that clicking “reopen” puts a bug in “feedback” status, which brings some inconveniences to users. If we use this option we can’t easily distinguish the bugs that the developer is asking for more information about from those other bugs whose resolution is still pending. It can also generate communication problems within the team, complicating the project management as a whole since the Mantis reports and graphics would group the bugs in the “feedback” status without discriminating which ones have been assigned. This transition, on default, could be customized for all projects or for an individual project by a user with an administrator role.
The administrator would have to go to Manage -> Manage Configuration -> Workflow Transitions and then click “reopen” which would change the status of the reported bug to “assigned.”
Even if the option is configurable, we recommend that you take precautions when making this change. Before customizing the option “reopen,” it’s a good idea to evaluate when you would use this option. Also by analyzing how a “reopen” will affect a bug in the reports, the team can decide which bug lifecycle to use.
It is important to take into account that Mantis will not recognize if we reopen bugs in the “resolved” status or if we are opening “closed” bugs from some time ago, meaning, the tool will not know when the system version has changed.
We recommend accompanying the bugs with clear tags (or custom fields) that reflect the version of the system under test in order to not affect the management of the project.
Happy bug hunting!
Recommended for You
The Most Common Mistake in the Bug Life Cycle
How to Optimize Test Coverage in the Long-Term
Abstracta Team
Related Posts
Hoppscotch: Open source API development ecosystem
In this post I will share with you what I have been learning about Hoppscotch, its main features and its differences with other similar tools. What’s Hoppscotch? Hoppscotch is a free, open-source, and lightweight API testing tool. Its core value relies on creating and using…
Debugging in Production with OverOps
OverOps, the self-proclaimed “God mode for production code” We are happy to share a new tool that we are excited about here at Abstracta, OverOps! Why? Well, simply put, it makes it easy to see where, when, and why your code breaks in production. My…
Leave a Reply Cancel reply
Search
Contents