We use Vs2008/2010 with TFS 2010 for our source control, because it also lets us create custom work item types that we can use for project management, such as product backlog items and sprint backlog items.
One item thats not tracked (by machine) is build regression test tasks for release candidates. Our regression testing is part automated, part manual, and the manual part can take several days. Currently we use an excel spreadsheet with a list of all the test cases, and then the testers just fill in results and notes.
I've been proposing creating a build regression test template that contains each test case, default owner, and then when we want to do regression testing on a build, we can automatically create work items for every test in the template.
My argument is that if the regression test work is mandatory for the project, and the results should be tracked, then writing additional TFS work items make sense, especially since the work items can hold estimates, giving managers an idea of how much re-test time remains.
The argument against this is that we already have high level work items to capture the overall project test requirements, and the regression testing is basically a "re-test", so new work items would be duplicate.
My question: Is anyone else doing anything like this? Is it reasonable to use TFS to track outstanding re-test tasks?
Note: we don't own Visual Studio Test Professional
I think it's reasonable to go with your suggested solution. You should have another work item type for the "test tasks", that can be linked as children to the test requirement work items. Doing that, like you said, would allow you to track results, progress, reporting, etc. You can also add other fields like build number, tested by, tested date, etc. to the work item type for history, something that cannot be done with just one test requirement work item type.
Essentially, what you proposed is done in the ITestResult object in the Microsoft.TeamFoundation.TestManagement.Client.dll.
Related
I'm currently working with Test Manager Version 2010.
When running a testcase with multiple iterations in it, a list is shown in the top left corner which has the following:
Iteration 1
Iteration 2
Iteration 3
....
My question is, is it possible to change this name to any subject so that it is easier to remember the meaning behind every iteration?
For example:
Iteration1 needs to be named Cat
Iteration2 needs to be named Dog
And so on...
Yes, and no :) I've never done this from the test manager, but here is a post that says how you change the iterations using the team explorer. You can name them whatever you want, they are nothing more than strings in a hierarchy. Even though the problem is slightly different than yours the steps should apply.
How to Add/Edit the Iteration Field in Team Foundation Server Scrum v1.0 beta Workflow
The bad news is that TFS uses loose coupling on the work items. that meens that whenever you change something like this the workitems that have used the old string will still have the old value. you will either make a script to update all work items, or manually go in and select the new value for each and every work item. If you only use the new values for new test cases (or other work item types) you're good to go.
I was reluctant to post this question at first as it seems like functionality that could be pretty fundamental to the way in which TFS manages work items, but I cannot find anything documented that covers it; how do I categorise TFS work items (more specifically, new tasks)?
I've created a bunch of tasks. Some may fall under 'solution setup', others fall under 'core development' for example. How do I represent this categorisation in TFS? Is it something I need to consider when I'm creating the new tasks? Or are the work items brought back in this way during the query?
There are a handful of ways that people typically categorize/organize their Tasks:
Group tasks by User Story. This is done by linking the WI's, and this information will show up in WI Queries, and on the Task Board (task board only available in tfs 2012 and up).
Use the Area field and Area hierarchy to categorize your Tasks. The Area hierarchy is typically used to represent a functional breakdown of your application, then applied to WI's to categorize them based on which functional area they affect.
Activity Field. There is a field on Task work items called Activity that by default that has the values: Deployment, Design, Development, Documentation, Testing, Requirements. This list can be customized by editing the Work Item Type Definition.
Surprisingly difficult to find anything on this. I was already using 'linked item' as I should, the problem was the query. I created a new query and set the type to 'Tree...' so that the hierarchical structure was pulled back in away that mimicked a tasks and sub-tasks structure.
We are using VSTS2010 for logging bugs. There are weekly builds happening and the QA/DEV updates bugs to fixed/open based on build numbers.
Since there are weekly builds happening and each build has a different number, there are chances for QA/DEV to set incorrect build numbers in fixed build/tested build number.
Questions:
Is it possible to validate the build number values based on some parameters like date of fixes?
Is it possible to show approrpiate messages for the validations?
I don't think there is a build-in way to validate the build number against parameters.
At the moment I can see two possible solutions for your problem, depending on the structure and your possibilities to change the system:
Minimize the set of build numbers to choose. You could change the source list of the build field to show a list with less entries, like only the entries of the last week/month. That would need a little script, that changes your globallist. Of course that only works, if no one else needs to select older builds.
Create an invisible custom control and add it to your bug work item. Inside the custom control you have almost any freedom to change or validate date and show them the way you want to. But you would need to develop it and install it on every PC that needs to use it.
TFS (2008) has the great feature of work item tracking where I can easily see what people are doing all day long. Now I was wondering if I could assign a work item to different people or if they could write time on an item in a trackable way.
For example: We have two developers Mr. A and Ms. B. A did 4 hours of work and 50% of the work item "Create customer screen" until he gets ill. Than B has to finish the other 50% but I do not want to lose the progress of A because it could seem that A worked 4 hours less and B 4 hours too much.
Unfortunatly it seems that I can enter only one name in "assigned to" when I am using TFS 2008 and can not store the item if I try to seperate the names by comma or semicolon. Do you know if such a feature is included in TFS 2010?
Thank you for help.
No. This is one of the few aspects that haven't changed from 2008 to 2010.
Thomas
I'm not sure about assigning one item to multiple people but you could setup groups to which multiple people belonged. I'm not sure of your other requirements but this should solve this issue here. In essence Mr A and Mr B would both belong to a group called, say, 'Developers' to which the work item is assigned. Thus the full 8 hours is logged against a single entity.
Here is an (old) article on how to do this elegantly. You may want to split up your groups to as specific a category name as possible (e.g. 'Core Developers', 'Javascript Developers')
Found this link that implies that they are aware of the need but have not implemented a resolution yet
In TFS, if you assign a work item to someone else it will maintain that in the Work Item History, which is available for reports. TFS 2010, however, only tracks 3 fields: completed work (in hours usually), remaining work, and original estimate. If A and B both update completed work, you should be able to separate that work out in reporting services.
As #DarrellNorton said, all the information is recoded in the history of the work item, so you can retrieve the completed work values for each historical entry and correlate that to the assignee at that point in time. So the information you need is already in your database, if you can work out how to extract it. (The danger is that if someone leaves the completed-work field unchanged you might record the first dev's hours against the second dev as well - you'd ideally need to add a state transition rule in your work item templates that clears the field back to 0 whenever it was assigned to a new developer)
Another approach is to add your own fields to your TFS work items. It would be very easy to add (for example) fields "HoursDoneByMrA" and "HoursDoneByMrB" and expose these onto the work item form so that each developer could have independent statistics by which you could track the information you require. As long as your team size isn't huge, this would be quick/easy to achieve, and would also give you an instant summary on the work item itself of all developers who had touched the work item and their contributed hours, so you wouldn't even need to go as far as building a specialised report. (TFS PowerTools provides editors for the work item types that make adding and displaying this information much easier than hand-editing the XML templates. This approach would work in TFS 2005, 2008, 2010 - once you know how to use the power tools to do it, it would only take about a minute per developer to put this in place).
I was thinking that I’d rather only use the Task Work Item and ignore the Bug Work Item. This is my thinking as I set things up for my team. I’m on a quest to see why I shouldn’t do this. From my perspective a Task is either a new item or a bug item. There is no need to use two distinct Work Item Types. To make this happen in TFS I’ll start with the Bug Work Item and create a custom field (“Item Type”) to distinguish the two task types: new/bug. Both new tasks and bugs will share the same fields. Anyone see any major drawbacks to this approach?
The main reason Tasks/Issue/Bugs/etc are different work items are because the individual fields of each work type can be configured differently.
For example, by default, Bugs have a Triage property, Issues have Due date, Tasks have a Discipline. The States of a Bug (Active/Closed/Resolve) are different from an issue (Active/Closed).
By merging them into a single work item type you would loose the ability to configure each one uniquely.
Also, the rules followed when a Bug and Task are closed, for example, are generally different. Segregating them into work items allows a simpler rules set.
Work item type is also a standard column in all queries.
Overall, it depends on how extensively you are using Team Foundation. If your project is small, and the above don't matter, it's not going to hurt. Though I don't see much gain either.
I would suggest keeping Bug and dropping Task if you want to merge them. By default when you check in code and Resolve with a bug, it sets the status to Resolved and assigns it to whoever created it - usually a tester, but in your case possibly a PM. That person can then test to confirm the work is done and close it. You can set up alerts on their work items so they get an email and know that progress has happened. Alternatively if you use Task, when you Resolve at check in it is just closed. No alerts, no further testing. YMMV but on some of our projects we use Bug for things like "user would like to add a new report" and it fits our process well. (For others we keep the distinction for reporting purposes.)
It all boils down to 3 things:
Creation / prioritization
Reporting / Notifications
Completion workflow
Typically creation of a Task involves different fields than a Bug. For a bug you'll want to know things like environment found in, who notified you, severity, priority, etc.
For tasks you usually want to know the requestor, reason behind it, business unit impacted and iteration it is scheduled for. Tasks might be long term goals that result in new or enhanced functionality.
Reporting and Notifications of the two are generally different as well. PM's are going to track tasks to ensure deliverables are met, your tech support area is going to track bugs.
Next, bugs will generally result in hotfixes and service packs. Depending on severity this this might involve a high priority push through QA and release as quickly as possible. Tasks are more laid back and will go through all forms of regression and regular testing with a period of acceptance by the impacted business unit.
Finally, bugs may impact previous versions of your software. Tasks will almost always be for either the version currently under development or the one after that.
In short, they are fundamentally different things. They might share most fields in common, however by combining them you are restricting yourself in both reporting and workflows. Today this might be okay; however within the next month or next year this could seriously restrict you.
Considering that maintainence of work item types is an incredibly easy thing there is almost no benefit to merging them.