[The following is a guest blog entry from a Microsoft internal user]
At our team, we use Microsoft Test Manager 2010 to manage our automated test cases. It provides great flexibility to compose test suites based on a static set of tests (static suite) or based on a TFS query (query-based suite). However, after using the system for a while, we find ourselves hoping for even more flexibility to compose query-based suites based on test categories or test suite membership. The default “Test Case” work item template does not have fields to capture these information, so they are not available for query out of the box. With some work item template customization and custom tools written using TFS API, it could all be implemented with a few hours of work! In this blog post, we would like to share with you our customizations, so you can extend them to further enhance your test management experience with Microsoft Test Manager.
Here is what we are trying to accomplish:
Enable creation of query based suites based on a combination of static test suite membership and other work item attributes
Enable creation of tracking query or query based suites based on automation test execution statistics
Here is the elements of our solution:
Let’s first look at how the “Test Case” work item customization looks like. Below is a screenshot of our custom fields in the “Process Editor” power tool.
And with “Process Editor”, we also customized the form to show these new fields on the UI. Here is how they look like in our template:
We wrote a tool using the TFS and TCM API to enumerate through the test plans and test suites and update the information in the test cases if they have changed. Only static suite membership is collected, otherwise the results might be unpredictable. The tool also looks for test assemblies in the latest build drop folder and reads the metadata in the assembly to get a list of test categories. If the test categories have changed, the tool will update the test case custom fields. Finally, the tool queries and computes the automation execution statics and write them to the test case so you can easily query for them. This is an area that you might want to further customize from the sample code. For example, you might want to be more selective about what tests you want to count as part of your average test run time. A test may run into failures very quickly and results in a much shorter test runtime that would skew the results.
We use a Windows scheduled task to run this tool every 30 minutes. You can determine what would be an appropriate interval for your team. The TFS connectivity information and custom field information is configured in the app.config file, and you would need to run the tool with a credential with appropriate TFS access.
The sample code is attached with this blog post. They are provided as is and for illustrative purpose only.
Here is a glance of what you can do with the added fields. We hope this information would help you get some ideas on how to better organize and tracking your tests. We hope you could see that TFS offers a very flexible platform and a robust set of APIs that gives you the freedom to implement a process that works best for your team. I would like to thank the VS ALM Team for giving me access to this forum to share this with the community.
Software Design Engineer in Test, Interactive Entertainment Business