I think the excitement for the Visual Studio 2010 (formerly known Rosario) has grown dramatically. With the announcement on October 19th, the Beta 2 was released, and now that we have a launch date (March 22nd 2010 for those of you not on the tubes of the internet) – I really could not be more excited. I’ve always loved the tools, but now – love may turn into something greater.
One of the things many of my clients have found limiting/frustration is the manual testing & test case management story with the current set of tools. My answer has been for a little while – wait until you see Rosario/2010. Even with that, sometimes we needed something in place for a little bit of effort. Here was my implementation of a rudimentary test management suite using 2008.
The solution must meet the following requirements: somehow test cases should be linked to requirements, we should be able to know how many test cases have been identified, authored, and executed, as well as some statistics about how many passed/failed. Without spending a lot of time on the details on Work Item Type customizations, here was my high level solution.
Create a new Work Item Type called Test Case.
For minimal effort, a work item type can have a few text boxes to handle the steps of a manual test case, it’s state, and pass/fail nature. We also created a Custom User Control here to handle the steps because sometimes that grid-like functionality just is irresistible to testers. Let your end users link those test cases to requirements.
Create a Report [Test Cases by Requirement]
You can get more complicated, but this report can be used to identify gaps. In this, you’d need to look at all Test Cases Work Items, and group them by their related Requirement Work Item ID. Now – just a few implementation details here: Use the TfsWarehouse relational database. It is your friend. It contains work item relationships without requiring MDX. Some have asked – can I use a query if we’re just getting a list of Work Items. Nope – any time you need to deal in terms of work item relationships, crack open the SSRS/SQL skills. You can now get for each requirement, the number and details of any test cases. You can get fancy by putting coverage % there if you want, too. Some teams need this.
Create a Windows Forms App – Test Case Copier
Testers do not run all tests just once. Tests are meant to be re-executed in every test iteration, or cycle. If you can get comfortable with the TFS API – you can have it iterate through Test Cases that perhaps meet a criteria (you can get arbitrarily complex depending on how your team breaks down their test cases), take that work item [one for each test case] – and copy some of the basic details (test description, author), but do *not* copy the state or the results. You can then create a brand new Test Case for a new iteration. A key point here – is have in your Test Case Work Item type have some indicator [a text field perhaps] for your test iteration.
Create a Report [Test Results by Test Iteration]
Now – back to SSRS – let’s create a report for our management that perhaps lists all the test cases that have been executed (that’s a TFS Work Item State you should have) – and the % that have passed / failed. You can take [because we now know how to relate those test cases back to requirements from the earlier report] those %’s and tie them directly to your requirements. You now can calculate how many of your requirements 1.) have tests written for them 2.) and the percentage of tests that are passing.
So – that’s your basic test case management solution in VSTS 2008. Let me be clear, it’s some customization, but not a lot. If you can wait until 2010 – you should because this customization – while probably will work in 2010, you will not want to when you see the features that are coming there!
Good luck, if you need any more details on this solution – http://twitter.com/cbkadel
