you know that the files and data that are part of a completed build can delete?
you know that the data deleted cannot be recovered?
you know by default Test Results from any automated tests run against the build
are deleted by default?
If you have the right permissions you can right-click in Build Explorer
on a completed build and select delete. When you do that by default all the
items associated with that completed build are deleted.
Details: Information about the completed build that
is displayed in Build Explorer. This information includes build steps,
requestor, and date and time queued.
Drop: File and folders output by the build and
copied to the drop location.
Test Results: Results of any automated tests
executed during the build process or results of any test published against this
Label: The version control marker associated with
the specific file versions used by the build process.
Symbols: The debugging symbols published to a
symbol server during the build.
You can also configure the retention policy and set auto deletion rules
. Nothing wrong with that however is the person responsible for the “Build”
setup and maintenance deleting could be deleting Test Results?
There is an option that can be set to stop the deletion of your Test
Make sure your teams understands what happens when deleting completed
builds. Set that option to keep your test results, unless you don’t want them!
Check out instructions on how to create reports for your TFS2010 Test Results. There is also an example that you can follow.
Team Foundation Server (TFS) and Visual Studio(VS) excels when it comes to requirements traceability. Depending on what process you are using in TFS your stakeholders needs are documented in a work item called one of the following: requirements, user stories, use cases or backlog items. For this blog I am using the term requirement.
What is requirements traceability?
Continuous knowledge of the life of a requirement from conception to creation to design to development to verification to implementation and change. The ability to trace a requirements state and/or status at any time during a project.
First step in making requirements traceable.
In Visual Studio other work items are used to identify work that needs to be done to a requirement before it can be deemed done. There are different work item types depending on the process template you are using, however all contain the following: Task, Test Case, Shared Step, Bug. Additional work items can be added if not in your process template like Review, Issue, Change Request to name just a few. All these work items can be linked to the requirement they are helping to fulfill. Visual Studio 2010 introduced the concept of hierarchy by which a work item is linked to another work item using a linked type. The work item task is a child of a requirement, two requirements can be related, a test case tests a requirement. Work items like tasks may be linked to show predecessor or successor of another task. To learn more about choosing link types to effectively track your project click here MSDN Library.
Linked type listing:
Example of a requirement with linked work items:
What can be traced?
In Visual Studio during diagram modeling requirements and other work item types can be attached to objects in the model. During modeling you can either create or link requirements. This allows you to trace work items like requirements from a model diagram.
Example of a Use Case model with requirements linked:
Within the requirement work item I can see all other linked work items and information about them like state, assigned to. Knowing the state of work items linked to a requirement tells me the state and status of the actual requirement itself.
Development when checking in code to VS source control can be forced to associate what requirement or other work item their code relates too. Code check-ins create a Change Set that contains information about the check in and gets linked to the work item(s) associated during a check-in. When fixing bugs this is a nice feature.
In Visual Studio I can create queries to show any type of traceability report. Examples: Requirements to Tests Matrix, Requirements to Tasks, Requirements to Issues, Test Cases with Bugs to name just a few. Queries can also be exported or opened in excel, sent to someone thru email or opened in Microsoft Project. Queries exported to excel allows for adding additional excel reporting features like a Pivot Charts.
Requirements to Test Matrix – is there test cases for each requirement
Visual Studio comes with many reports that trace Requirements showing linked tasks and remaining work left, test case results state and many more scenario’s. Remember depending on what process template you are working with will determine the reports you see.
Checkout MSDN library for lots more information on Requirements Traceability in TFS & VS.
Come out to the Metro Toronto User Group on February 15th. Colin Bowern and I will be showing you how to customize your build process with TFS 2010 and use MS Deploy to automate your web app deployment.
Customizing the TFS Build process and automatically deploying your web app.
When: Wednesday February 15, 2012 at 6:00pm
Where: KPMG, 333 Bay Street, 46th Floor, Toronto
See you there.
Free tool available for exporting your test cases to excel in a nicely formatted fashion.
Click to download here
You connect to Team Foundation Server by clicking the Connect TFS button.
Pick the Team Project you want to work with as shown below.
The test plans and test suites associated to the team project you selected display.
Pick a test plan and test suite then specify where you want to save the excel file to on your system and a name for the excel file.
Here is an example of test cases export to excel. The Actual Results, Pass/Fail and Comments are not populated from Test Manager. These would be fields your tester’s would enter as they are testing! Or you could remove them and add your own columns using this for test case reviews or any other type of reporting required.
It was a great evening for ObjectSharp Consulting last night. At the Microsoft Impact awards ObjectSharp partners Dave Lloyd, Barry Gervin and Mike Green accepted the
Partner of the Year award for Application Lifecycle Management.
Congratulations to Objectsharp and the Sharpe's.
The test case work item has a tab that lists the requirements/user stories that the test case tests. However, bugs related to the test case are not part of the listing. Dave has come up with a customization that changes the test case tab to include bugs created against the test case. With this customization you will see all work items that the test case tests.
Read Dave’s blog for more details and how to do the customization.
The Test Case Work item has a tab that lists Tested Requirements or User Stories (depending on the canned process template CMMI or Agile) that this Test Case tests.
When a bug is found you should write a test case so everyone knows how to validate that Bug once it’s fixed. Therefore why have a tab that just shows Tested Requirements/User Stories.
Lets use the Agile template as an example. The Tested User Stories tab will only allow you to add User Stories. Even though you could add a Bug with the tests relationship under All Links if you wanted.
It’s very easy to change this tabs behaviour to allow for Bugs also. Here’s how.
Open up the Test Case in the WIT editor that comes with the TFS 2010 Power Tools. Under the Layout tab find the TabGroup > TabPage – Tested User Stories > Control – User Stories tested by this Test Case and select it.
Select the Control Settings property and click on the ellipsis button. Leave Work Item Type Filters as Include. However in the drop down list to the right of that change it to also include Bug, then click OK,
Now change the Label from User Stories tested by this Test Case to something more appropriate like Tested by this Test Case.
Then switch focus to the Tab Page and change it’s label to something more appropriate like Tested User Stories and Bugs or just Tests.
Save the work item type.
You should now be able to select Bug as a work item type tested by this test case.
If you do not have a profile on LinkedIn it is time to join. There are amazing groups that are sharing information, posting questions & getting answers for a lot of different topics.
On the Visual Studio ALM User Group Anna shared a blog she posted “How to integration TFS and QTP”
Other LinkedIn groups related to TFS are:
- Visual Studi0 2010 Testing
- Microsoft Visual Studio ALM + Team Foundation Server (Team System)
- Microsoft TFS/VST Customization Experts
- Microsoft Testing Visual Studio 2010
- Microsoft Coded UI
There are also Agile groups:
- Agile Testing
- Agile Toronto
This in no way is a compete list.
If your looking for a way to create
test configurations that can be used in all your team projects check out Dave Lloyds blog. Dave explains how to edit the process
template to add or change test configurations.