How do I prevent defects from automatically creating "Affected by Defect" links to other stories?
Our process is to leverage existing test cases as much as possible. When we leverage existing test cases in later releases, and write up a defect to the test case. ALL stories that use that test case are given an "Affected By Defect" link which is not a true statement.
For example (using the example we're adding a grid to a new web page) Release 1) create the Story: "Create a new webpage with a grid" create the new Test Case: "Grid Validation" Create a link "tested by test case" between the Test Case and Story. (assume all testing went smoothly) Release 2) create the Story: "Add column X to the grid " EDIT the Test Case: "Grid Validation" so it has an extra step for the new column Create a link "tested by test case" between the Grid Validation case and this new story. So now you have a Test Case with two Development links to each of the stories that used it for validation. Now say the test case was executed and a defect was found. If the defect was entered from the Test Case Execution Record BOTH Stories passively get a link of "Affected by Defect" to the new defect. Our problem is that the first story is completed and closed, but ended up with a link implying it was affected by a defect. In addition, as the old story is getting an edit. Emails are getting generated which are causing confusion. The owner of the old story are being informed that a closed story has a defect. How are we able to fully leverage the reuse if RQM is making the assumption that any defect will retroactively affect any previous story? I'm looking for advice in not linking old stories as being affected by defect. Removing the development link between a Story and a Test Case would not be an option because we do need to historically look to see what Test Case tested what Story. Thanks in advance! (This is RTC/RQM v. 4.0.6) |
3 answers
Check out this post and see if you can get some ideas. Basically you should be able to use a precondition (built-in or custom) to prevent the close work item from being updated.
https://jazz.net/forum/questions/123942/prevent-associating-a-change-set-to-a-work-item-that-already-has-delivered-change-sets-associated-to-it |
Stephane Leroy (1.4k●1●4●9)
| answered Sep 17 '14, 11:23 a.m.
JAZZ DEVELOPER edited Sep 17 '14, 11:37 a.m.
Hi Alexander,
seems to me there are TWO aspects to distinguish in your post:
You wrote: "Release 2)Why editing ? By doing so, you affect (in a retrospective way but no matter) the test case for the Release 1 as well. Which, by definition, will never include a "column X" feature, right ? This is where there is a flaw in your approach I believe. The best practice in this area (AFAIK) is to: - reuse test cases from Release n-1 to Release n: - if you have a Test Plan and duplicate it within the project area, you will still find that all the original test cases are referenced, not copied. - this is fine... UNTIL some modifications are required. - once a modifications are required (to adapt the test to some new feature, e.g. like the new "column X" of your example), you'd need to duplicate the test case and have the new test plan to use this copy instead of the original test case. Actually the tool provides you such capability through a single click: it's the "Copy and Replace Test Case" action (introduced in RQM 4.0.5 AFAIK). It performs this combined set of actions for you. Plus creates a link between the derived and the original test case through a "Copied From" relationship. Stéphane Note: I considered currently available features in RQM (5.0.1 as for today). As such, I did not mention VVC / PLE (which will appear some time later) strategies. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.