It's all about the answers!

Ask a question

How can you ensure that testers do not change the resolution code for a work item?

Erik Mats (105625) | asked Oct 28 '16, 7:18 a.m.
 How can you ensure that testers do not change the resolution code for a work item? Developers should set resolution code early and testers should not be able to change it during the work item lifecycle OTHER than resetting the value when reopening the work item if it fails test.

Setting a permission to only allow developers to edit Resolution fails because:
 1. The permission is not atomic for the Resolution code itself, but also applies to the built-in attributes Resolved By and Resolved Date.
  2. Testers need to be able to edit Resolution or they cannot reopen a closed work item.

One answer

permanent link
Erik Mats (105625) | answered Oct 28 '16, 7:18 a.m.
 I was looking at the OOTB Scrum process and noticed some things and a possible solution:

What you want to do, can be accomplished if you make Tester unable to edit Resolution in some states only.

Tester should not be totally unable to edit Resolution, or they won't be able to bounce back work items that fail to verify.

See below for example.

Note: The attribute "Resolution" did not show by default in my Eclipse so I set a different value at first and edited the XML source:

   <role id="tester">
       <operation id="">
               <precondition description="Verifies that a work item that matches the selected types or states can only be saved if the selected attributes are unchanged" id="" name="Read-Only Attributes For Type and State" xmlns="">
                   <properties workItemType="defect"/>
                   <workflowProperties stateId="" workItemType="defect">
                       <property id=""/>
                   <workflowProperties stateId="" workItemType="defect">
                       <property id=""/>

Does this solution allow you to accomplish what you need?

Another observation from the OOTB Scrum process:

The "Closed" group is not used for the final state of a defect as
in your process. Rather from "Closed" there is a transition to
"Verified", which also has all the resolution codes. This is how a
Resolution code set by a developer is managed in that process. As
discussed, as long as all resolution codes are available they should
not be changed when going between states.

Your answer

Register or to post your answer.