While evaluating ClearQuest to JIRA migration, I noticed there are some major differences in their default defect tracking workflows. They have different approach to even the most basic issues such as assigning or reopening a defect. In this post I would like to focus on some of the key differences, and suggest my opinion about them.
Before I start, you may ask why do I care about the default workflows? Every modern issue tracking tool is very customizable, after all. But the way I see it, the default workflow say something about the tool developers and their vision of defect tracking, so it may be something interesting to look at.
The default JIRA workflow is described here, with details about the statuses here. The default ClearQuest workflow is shown here, although without much details (I refer to the DefectTracking default schema).
In ClearQuest, you first submit the defect, and in a separate step assign it to someone. In JIRA, when you create a bug, the assignee is set automatically (you can change it of course at any time).
My thoughts: I tend to side with ClearQuest here. When you find a bug and want to record it, you don’t necessarily want to assign it to someone immediately. The way I see it, every new bug should undergo some sort of review before deciding if it’s needs to be handled, when (priority and/or targeted release), and by whom. This does not necessarily have to be a CCB review; it could be performed by the corresponding team leader or senior developer, or perhaps even the assignee themselves.
In ClearQuest, The Re-Open actions moves the defect from Resolved or Closed to Opened. In JIRA, the Re-Open transition moves the bug from Resolved or Closed to a separate state called ‘Reopened’.
My thoughts: I think both tools got it wrong. I believe a re-opened bug needs to be treated exactly like a new bug which has undergone a review. In that sense, the logical thing to do is to assign the defect to the person who resolved it, and move its state to ‘Assigned’ (ClearQuest) or ‘Open’ (JIRA).
In ClearQuest, there is a special pair of action types called Duplicate/Unduplicate. Once you duplicate a defect, you can use the unduplicate action to return it to its previous state.Otherwise it stays in the ‘Duplicated’ state forever. In JIRA, duplication is just one of the several possible issue links. In order to duplicate a bug, you resolve it with ‘duplicated’ as the resolution type, adding a ‘duplicate’-type link to the original one.
My thoughts: I’m with JIRA here. If a developer marks a bug as duplicate of another bug, a tester should validate this duplication, and close the bug. After all, tracking it is no longer interesting since we can settle for tracking the original bug.
Severity and Priority
In ClearQuest, you have two fields to define the defect’s importance. Severity refers to how big is the effect on the system, and Priority refers to the developer’s work queue. In JIRA, you have one field – priority – which is the equivalent of ClearQuest’s Severity field (confusing, I know…).
My thoughts: It depends. In every issue-tracking system you must have a way to describe the relative importance of a defect. Is it enough to define the work priority for the developers? I think it is mostly based on the organizational approach.
In ClearQuest, there is no built-in way for the developer to specify that it requires additional information in order to work on the defect. in JIRA, the developer can resolve the bug with ‘Incomplete’ resolution type.
My thoughts: Both tools got it wrong. The way I see it, the developer should assign the bug to its reporter, asking to provide the missing information. This can be done without changing the defect’s state, but in my experience, any change in the assignee should imply a state transition. So my suggestion for this case is to move the bug to a ‘Need Info’ state, and once the information is provided, return to the originating state.