3

Most issue tracking systems have only single status field.

Typical Status: New -> Fixed

When code is pushed to repository with commit message "Fixed issue #1234", the issue #1234 is automatically mark as "Fixed".

I have the below idea but no system can fulfill.

The question is: Am I right or just not finding the suitable tool?

  1. Programming status

    I think this is problematic because only the programmer says he has fixed an issue.

  2. QA / release status

    It is not possible to know if QA team has verified or not. There is no place for QA team to mark the status.

    Also, even for open source projects, the end-user may not want to compile from source.

    The end-user is only interested in whether he can get a release version.

    If the new release is not ready to ship, from the point of view of the user, it is nothing "Fixed".

  3. Feedback status

    It is also useful if the user can set the "feedback status" to "Fixed" after testing the released version or source code, rather than leaving a comment "Thanks, it works!".

Status fields are searchable.

Kilian Foth
  • 109,273
linquize
  • 1,160
  • What about something like http://trac.edgewall.org/wiki/WorkFlow/Examples#Enterpriseenterprise-workflow.ini ? – Tobias Kienzler Mar 04 '13 at 10:26
  • 3
    The QA and release status changes can only happen after the developer has declared that the issue is fixed, so there is no harm in encoding these as addiotional values in the single status field (i.e. Fixed -> Tested -> Released -> Solved). – Simon Richter Mar 04 '13 at 13:58
  • So your status values would be: New -> Fixed -> Verified -> Confirmed [dev] [QA] [User] right? – Useless Mar 04 '13 at 08:21
  • Can you give an example of a issue tracking system which doesn't allow you to do what you want? I know that both trac and jira both support QA intergration. – Mark Booth Mar 06 '13 at 13:21

4 Answers4

8

Trackers have only one status field because a bug can only be fixed or not. There is no in between. If there are multiple fields, that would be the same as when a developer says "it works for me", where obviously it doesn't.

This enforce the fact that only one person/dept decide if a bug is fixed or not, be it the dev team, the QA or the reporter. In some tracker, like FogBugz, only the reporter can mark a bug as fixed.

The "progress" indicator is another field, which aim is to know where on the "path to the holy fix" is the bug. However (and especially in the software development), it's often a poor indicator, as raw debugging can be really long in the case of a Hindenbug. Also there can be some travel forth and back between QA and dev teams meaning that, like a tennis match, the score goes on and on, until one of the team leads by 2 points.

Clement Herreman
  • 778
  • 6
  • 12
  • If you look at something like VersionOne, which is a task tracker, you can define statuses for a defect has a status which goes from (none)->Assigned->InProgress->ReadyToTest->Tested->Accepted . However, it's not normally the job of a bug tracking system to track the work to fix the bug - like you say, that would only become fixed when the user accepts it. – Pete Kirkham Mar 04 '13 at 09:34
  • @PeteKirkham yes, fix and progress are 2 different values. A wontfix or works for me doesn't really fit the "progress" paradigm. A bug's life isn't really linear, it can be rejected, invalided, and most likely it can come back. – Clement Herreman Mar 04 '13 at 09:40
  • Sure, but you can draw a flow chart of all the transitions, and then a single state suffices to describe which node you're on. IMO it's more useful to inspect the history of a ticket to see how it reached that node, and the comments to see why. – Useless Mar 04 '13 at 14:38
  • 1
    @Useless Makes totally sense. Maybe I spent too much time using the simplistic Github tracker. I guess it only works when people have discipline and explain their actions through comments. – Clement Herreman Mar 04 '13 at 14:40
3

Don't confuse having more than two values in a field (active / fixed) with having multiple fields. Of course QA gets a say as to whether the bug is fixed or not. And perhaps the end user can accept a feature. But that info can still all be in a single field with values like:

proposed / approved / active / coded / tested / deployed / acccepted

With multiple fields (one for the business decision to do it, one for the developer's opinion, one for QA's opinion, etc) you could end up with a situation where the developer status is still "working on it" and the QA status is "tested and ready to deploy". Then you would need process or code to make sure one status was never out of sync with the others. Having a single field makes conflicts like that impossible.

Kate Gregory
  • 17,455
2

In my opinion: The first one of your distinctions is sensible, the second isn't.

Obviously programmers must be able to bump the status of an issue, because they are the only ones who can actually do something about the root cause. But you are quite right that making a code change and actually solving the user's problem can be very different things, so it's useful to have a distinction between "fix proposed/implemented/hypothesized" and "fix accepted/verified/confirmed", and to have the second one available to QA. This is usually done (and in fact I would consider it a strong disincentive to work any where this distinction isn't made).

The second one is problematic. Obviously the actual user is the only one who can confirm with finality that a problem is indeed solved; but waiting for the actual user to confirm anything can get horribly slow and tedious. Customers can decline to answer, be unwilling to talk to tech people, etc. etc. Also, as you point out, customers can only see fixes that have made it to a public release. All this can make it impossible to maintain a scalable workflow. Therefore verifying that fixes are in the hands of customers is an issue of release management as much as of development work, and an issue tracker on its own isn't the right tool to solve this.

In short: the different status values that an issue can have are rather more complicated than just "open" vs. "closed", but I think that the ones you should use form a nice one-dimensional succession of states. Therefore adding multiple fields just to express "reported but not reproduced" or "fixed but not shipped" is unnecessary complexity.

Kilian Foth
  • 109,273
  • If you are making product for specific customers, verifying fixes by customer works well, because after each upgrade they will report what open problems they have, so you know what to close. If you are making product for the public, it usually does not work, so you close when it gets to a release and give the reporter option to reopen it if they disagree. – Jan Hudec Mar 04 '13 at 08:41
  • @JanHudec Yes, I am asking "making product for specific customers" – linquize Mar 04 '13 at 08:51
  • @Kilian an issue tracker on its own isn't the right tool to solve release management problems. Then how? Could you suggest some tools / workflow for this? I want to link up everything. – linquize Mar 04 '13 at 08:57
  • I think issue tracker is the right tool to solve this, even on it's own. Just don't view it as development tool but project management tool; the project manager does much more work with it than developers. And don't expect it to do work for you; the project manager has to maintain it based on customer feedback. – Jan Hudec Mar 04 '13 at 09:04
  • It's my experience that PMs never touched the bug tracking tool except to create reports from it – James Mar 04 '13 at 09:37
0

Kilian has a good point that 3. is unnecessary in that it is a release management / deployment aspect, rather than the software development one. Usually there is a field like Fix Version which can be amended by the release team later when it is decided which release to include the fix in. Also he is right that the DEV team should not have the final say whether an issue is fixed or not.

For the back-and-forth communication between the DEV and the QA team the right field to use is the Assigned To. When the QA team finally confirms that the issue is fixed, they can set the status to fixed.

This workflow should be supported by most issue tracking tools (I use JIRA these days).

Community
  • 1
Daniel Dinnyes
  • 530
  • 4
  • 10