Scott Archer's List: Software Development

• • OPEN (first time we create it)
    ASSIGNED--> test (for qa)
    CLOSED
• • Open
    Assigned
    Test
    RESOLVED
    Closed
• OPEN (first time we create it) ---> ASSIGNED--> test (for qa) --> CLOSED (the qa will change it to close once they verify it)

• Developers (along with whomever else needs access) should have access to create, assign and resolve a bug.

  Testers have access to create, edit, assign, postpone, resolve, verify, fail and close.

  I do believe that developers need to have access to "Resolved". This means that they have resolved the issue at hand and are ready to submit it back to QA for verification. If it is verified, it is closed, by QA. If not, it is failed and sent back to development.

  QA / QC needs to verify the completion of a bug for the same reasons that developers cannot test their own code. Developers are too close to the code, too close to test their own work (including their own fixes).
• QA cannot verify the quality of a product without their own verification of the fixes. If your management is looking for a way to 'shorten' the bug cycle, this is NOT the place to do so.
• Like what Digits and the others said, developers should not be able to close.
• Open --> Assigned --> Test --> RESOLVED --> Closed
• If you sell Digit's idea to management, then they can choose to treat "Resolved" as "Closed", the main difference being that you'll be able to confirm which issues you closed, and not someone else.
• After all, that must be the bottom line they're really after, to be able to monitor what is kinda finished. If they accept that QA has a legitimate function distinct from Development, then Development should not be allowed to rubber stamp issues as closed.
• • Duplicate
    Not a bug
    User error
• A developer decides that your bug is invalid, so they kill it. What is worse is that QA doesn't have the ability to re-open it. We have to go to our manager, which is a pain.
• We have a couple of statuses for this (duplicate, notabug, user error)

• All come before closing a bug but not before it has been reallocated to the originator so that they can understand/agree/disagree/argue/whatever...

  duplicate : another bug has been raised that has the same cause. The originator of the duplicate is given the job of assimilating both tickets into one then closing the duplicate.

  Notabug : the tester was in error. usually occurrs because a spec is ambiguous or someone is workign from the wrong spec version. could be resolved either way and normally results in some spec content/version clarification. On the rare occasion that someone raises a bug without looking at the spec (and gets it wrong) we beat them savagely with an old shoe.

  user error : rare - somethings cannot be fixed/changed/rectified with commercial viability so users are instructed to avoid via their training material. Often they circumvent this so they raise this kind of bug.
• with Tester ROLES and Developer ROLES, the key is maintaining a separation.
• I also must mention that there is NO confusion about my bug database. QA owns it. The developers know that they have access to it, but ownership belongs to us.

13 more annotations...

• Hg Init:   a Mercurial tutorial  

    Mercurial is a modern, open source, distributed version control system, and   a compelling upgrade from older systems like Subversion. In this user-friendly, six-part tutorial,   Joel Spolsky teaches you the key concepts.