MTM needs a feature that allows testers to describe what an individual test case iteration is testing.
Right now I add a parameter to the last steps expected results "@Notes" and for each iteration of a test case I add to the Notes what I am testing in each iteration. Example would be testing a address site. My test case will go through all the address fields so any testing I would need can be done with parameters and iterations even boundary. But I need a easy way to identify what is being tested by an iteration.
Vote for this feature “Identifier that describes what each test case iteration is testing”
An update is available that includes the following:
Support for multi-line test steps in Microsoft Test Manager
Changes to the 2010 client to allow it to work with a TFS 11 Server
KB2522890 – Team Explorer Crashes when opening build from TFS 2008
KB2552300 - Gated Check-ins fail with the “Preserve local Changes” option
KB2561827 – DiffMerge closes with unhandled exception when comparing two files.
Here is the update: http://go.microsoft.com/fwlink/?LinkID=212065&clcid=0x409
If you are using Microsoft Test Manager you will notice that the work item Test Case does not contain the field Reason. This statement really isn’t true, there is a reason and it is being set for you but not displayed.
The field Reason indicates why a work item is in a particular state. By default the reason field is being set. States Active and Ready only have one reason which get sets by default for you. The state Closed has three options however since it is not displayed by default reason is be set to “Obsolete”. The other reasons available for the closed state are “Deferred” and “Duplicate”.
There maybe other reasons that you are closing a Test Case or setting the state to ready. One example is Test Case reviews. For this scenario you may want to add a reason that indicates the Test Case is in the state of ready “For Review” then a second “Review Done.
We can customize the available reasons but that is for another blog. Below are instructions on how to add the field Reason to display in your work item Test Case.
How do I get the field Reason to display:
1. In the main toolbar of Visual Studio select Tools > Work Item Types > Open WIT from Server
2. Connect to Team Project Collection window opens where you select the collection then click the Connect button.
3. Select Work Item Type window opens where you select a Team Project and the work item Test Case. Click Ok
4. The Work Item Type editor opens as displayed below and you can scroll through to see all the fields available. Reason’s reference name is System.Reason and it is a string data type.
5. Click on the Layout tab where we will add the field Reason to the Test Case.
6. You are looking at a preview of the form layout. Find Group > Column > Group-State > Column. Right click on the second Column and select New Control.
7. The window pane to the right displays. Find Field Name in the adjoining cell click the dropdown arrow and select System.Reason from the listing. Find Label in it’s adjoining cell enter the label you want to display on the Test Case, likely Reason.
Under Column you will see Control – Reason added to the bottom of the listing you can move it up under Control-&State if you want. Where it is in this view is where it will display in the work item.
8. Save your changes and refresh TFS depending on how often TFS is being updated the field Reason will display as below in your Test Case work item.
A MSDN Blogger, Gautam Goenka is giving away the code to enable you to do bulk action recording edits. Click here
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.
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.
Check out this MSDN blog about a company that is using Test Manager for their automated testing. They have customized the Test Case work item to capture information about what test suite the test belongs too, added test categories like Smoke Test, and test execution statistics. They have added a command line program that updates the TFS TCM periodically updating the information in these new fields.
At the end of the blog is TfsTestcaseUpdaterSample that you can download.
Share you idea’s by adding comments on other ways to customize the Test Case work item to help gather information that can be queried.
I will post any idea’s so stay tuned.
I am seeing people talking about having a test case with up to 50 and even 100 steps. I might be mad but isn’t that a lot of steps in one test case? When I talk to test teams my recommendation is no more then 10 steps per test case.
Make usage of Shared Steps that can be used to navigate through an application. Make usage of other test cases that will get your test case to the right spot in the application. Use the MTM ordered test feature to organize test cases to run in a specific sequence when needed.
I like to tell testers about the KISS principle of design.
Keep it simple and straightforward.
Keep it simple and short.
The KISS principle states that simplicity should be a key goal in design, and that unnecessary complexity should be avoided. This applies to code design as well.
Test Cases you’ve kissed will be easy to understand, maintain and report on.
Shai has done it again. In my last blog I explained a tool that lets you copy test cases & shared steps from one Team Project to another. We had a need to copy test cases from one team project to another where the project resided on different Team Foundation servers.
Shai in no time revised the tool to enable copy of test cases between projects residing in different TF servers.
If you have a need for this tool email me.
Great tool – thanks again Shai
In Test Manager you can copy existing Test Suites into Test Plans but only when they are both in the same Team Project. You can also create a copy of a test case adding it to a different team project but only one at a time in Visual Studio or MTM. So what happens if I have test cases that are in other Team Projects that I want to add to a new Team Project?
Shai Raiten who is a VS ALM MVP & Microsoft Regional Specialist has created a tool for this function.
The tool is a wizard that walks you through the:
||Connection to the Team Foundation Server |
||Selection of the Source Team Project (where test case to be copied reside)|
||Selection of the Target Team Project (where you are coping test cases too)|
||Selection of migrating existing test case links, attachments, areas, iterations and even the duplication of existing Shared Steps.|
||Addition of a Configuration File that saves the migration results|
||Field mapping – the wizard checks that the target test case work item has all the same fields as the source|
||If you selected to copy area and/or iteration the wizard checks that the same data exists in the new project, if it does not you shown what is missing and expected to add into the target team project.|
||Then you get to select the query from the source team project that contains the test cases you want to copy or it may just be all test cases from the source team project. Either way the test cases from your query are displayed with a checkbox. You are required for each test case displayed to check the one’s you want copied.|
||All that is left is to click Start|
If your source test case has:
|Parameter’s they are copied |
|Shared Steps they are duplicated but not the action recordings|
|Parameter data it is all copied|
|Action recording they are not copied|
|History it is not copied, the new tests case will show the date and time the create was done and all the data that was copied.|
If you include the coping of links from your source to your target and the link is another work item from your source team project it does not get copied into the target team project.
If you would like to use this tool email me.
Shai great tool and thanks for providing me a copy.