Versioning of Work Items
Work Items currently already have revisions saved and make them visible by looking at the history tab, however this should be a first class feature. Allow users to navigate back and forth in time, compare versions and most importantly, let work item template editors specify which attribute and state machine changes trigger a major (x.) or minor (.y) change. For example changes to the 'Description' field in our environment always causes a major change from e.g. 1.0 (or 1.1, 1.2 etc) to 2.0. Same goes for status state changes from 'In Review' to 'Released'.
Visual Studio ALM Team
shared this idea
7 comments
-
Jörg B. commented
@Eric: we basically do the same by now: create new, single Test Case copies for new 'versions' of them (each of these physical workitems undergoes a draft > review > release state machine transition) and what we also do is link them to a baseline work item (as we do a lot of Projects in parallel, each of them being at different states/milestones we can re-use these Test Case across multiple projects or, selectively create a new version dedicated for one (or more) other projects, and link these new versions/copies to those baselines).
The Baseline workitems basically help us to allow users to have a clear, concise point of entry for a project and see what test cases are included in it. These baseline work items are also used as base for test planning and therefore test execution scope.
So we don't copy Test Cases in bulk and thereby avoid unnecessary duplicates.
-
EricFields
commented
I'm not sure using the workitem-baseline extension would work when there are multiple testers. I assume that every change the testers make would update the same file. I would think maintaining this on the work item database would be a much better/safer solution.
What we have done is we added an AssociatedReleases multi-select field to the TestCase work item. When the TestCase changes due to a new Release, we create a new TestCase and update AssociatedReleases with the new release. The previous TestCase contains the value of the old release along with other previous releases in which the TestCase hadn't changed. It would be great to hear more about others' solutions for this. It would be even better if Microsoft provided a good solution. I understand the current solution advised is to create a copy of ALL TestCase work items for one Release and use the new TestCase work items for the new release. It would be better from TestCase management and efficiency levels to only make copies of work items that actually changed vs making a copy of ALL TestCase work items.
-
Chris F
commented
+100 on having rich history and compare on Workitems to visually see how they changed over time. Especially useful for Test cases and Test Suites.
-
Anonymous
commented
Would like to have a way to have rich views of the history of what a work item looked like over time, the work item form UI and fields changing values over time.
-
TFSExtensions.com
commented
TFS Work Items already have revisions that can be used as baseline. Please check out this extension that allows user to mark baseline and baselined revision later time.
-
Samatha Berns
commented
We were just google searching for how to preserve workitems in the state they were in at release. We want to have something like branching and merging so we can diff changes in workitems (great way to generate release notes). It would also be nice to have something like an export to PDF and make read only.
-
Hey, I submitted that idea originally :) We're currently implementing a rather massive workaround (in terms of customization efforts) to enable a similar functionality for end users and we'll live fine with it for the years to come. Nevertheless, having that as native functionality would certainly be nice.
What also should be added to the use case description above is the way links inbetween versioned work items are treated - are they automatically copied over if one end of the link is getting a new (major) version, or not. Should links get an indicator (e.g. 'Suspect') on such activities that responsibles for both end of the link can easily see whether something changed on the other end.
