Last week I saw another example of the most common mistake done when defining the bug lifecycle, the over-use (or plain abuse) of unnecessary bug states.
The team I visited had 3 different states for a bug that was open and waiting for development work. They used OPEN as their “normal” state when assigning a bug to a developer for fixing, REOPENED was used in cases when the bug was sent to QA and then returned to the developer for additional fixing, and they used REASIGNED when a developer though a bug should be fixed by another member of the team.
After evaluating their complete process we eliminated 2 of the 3 states above (and another 2 unrelated states) and improved their process, making it less bureaucratic and easier for all to get the complete picture of project and product status.
The case above is not out of the ordinary, I am fairly certain that if you look at your Bug Lifecycle today you will find at least one state you could take out to improve the process.
There are two main reasons organizations “invent” unneeded states for their bugs:
1. Use of states as a means of communication. Like in the case above where all 3 states meant that the bug was waiting for development work, but each one differed in the message sent to the developer in charge of the work. In this case they should’ve used one state and use comments in order to communicate.
2. Organizations that use the same lifecycle states for 3 different types of issues: Bugs, Enhancement Requests and Tasks; trying to use a one-size fits all approach for 3 related but different items.
The first mistake is relatively easy to fix. Just look at your current lifecycle and analyze your states, merging all the states where the action required by the responsible person is the same.
Here is an additional common example: think of organizations that have the following two states: “NOT-A-BUG” and “UNABLE-TO-REPRODUCE”. Both states reject the bug and send it back to QA for reassessment and/or closure, the difference between them is the reason why the bug is rejected. Why not having only one state “REJECTED” and compliment it by adding a comment that explains the rejection? You can even add a new field called Rejected Reason and make it mandatory when the bug is set this state.
The second mistake is not hard to fix since it only means that you should define separate lifecycles for each type of issue, reflecting the gates or stages it needs to pass throughout the organization.
The real problem with this one is that I don’t know of any available Bug Management System that let’s customize the lifecycle easily for more than one type of issue (without writing code via its API).
There are workarounds, like using different instances of the system for each issue type, or adding prefixes to the states to differentiate for which entity they are intended, etc; each with its own pluses and minuses so I will let you decide which to use. Just make sure you are aware of this and handle it accordingly.
I will close with what I believe is the most simple and complete example of the Bug Lifecycle, the one that should fit over 80% of all development organizations (this means that most probably it should also fit yours!!).
Personally, I like to think that we should give liberties to our co-workers allowing them to feel comfortable in their own spaces. This means that I tend to let people customize their environments and create fields and flows to help them do their jobs in the way they like to.
Issue States & Transitions is one of the few areas where I think that providing too much Liberty will eventually lead to Anarchy, just keep it in mind.
Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.
Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.
With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.