So this week, we had a little bit of fun, by which I mean a day that started with panic and scrambling when someone accidentally deleted a Test Plan (yes, a whole test plan) in MTM in production. A well established test plan with dozens of test suites and over a hundred test cases with a month’s worth of result data no less... Some important things of note:

• test plans are not work items, they are just a “shell” and so are a bit easier to delete than they should be (in my opinion)
• there is no super secret command-line only undelete like there is for some artifacts in TFS, so recreate from scratch or TPC recovery are your only options here to get it back
• when you delete a test plan, you lose every test suite you had created.  Thankfully, not test cases themselves, those are safe in this situation.  Worst case, a plan can be created, although it is tedious and can be time consuming.
• when you delete a test plan, test results associated with that test plan will be deleted*. Let that sink in – ALL OF THE TEST RESULTS FOR THAT TEST PLAN, EVER, WILL ALSO BE DELETED.  ::this is why there were flailing arms and sweaty brows when it happened::

So at this point, you may be thinking it’s time to update your resume and change your phone number, but hold up. You may have some options to recover that data, so buy some donuts for your TFS admin(I like cinnamon sugar, BTW).  I should mention, there may be a lot of other options but these are the three I was weighing, and due to some things beyond my control we had to go with #2.

1) Best Case Scenario: restore your DETACHED (this is required) team project collection database from a backup, cause you’re totally taking nightly backups and using the TFS Power Tool right? You lose a little data depending on how old that backup is, but it may be more important to get back your test runs than have to redo a few hours of work.

2) Second Best Case Scenario: If you cannot lose other data, and are willing to sacrifice some test run data, then restore the TFS instance from a traditional SQL backup to a separate TFS instance (so, NOT your production instance), open up your test plan in that secondary environment, and recreate your test plan in production.  Not ideal, but if you didn’t have a ton of test runs this may be faster and you don’t sacrifice anything in SCM or WIT that was changed since the backup was taken.

3) Worst Case Scenario: if your backups were not detached when you did your last backup, cry a little, then use the recover command to re-attach them. The gist is to use the TFSConfig Recover command on the collection to make it “attachable” again, then attach it to your collection. I have written a separate post on this because it can be complicated…

Once you are back up and running, make sure rights to managing test plans is locked down!  It might not be obvious that you can even do this, or where to find it, since it is an “Areas and Iterations” level permission. But do it, do it now!  This permission controls the ability to create and delete Test Plans, so be aware of that. But for the most part, anyone with authority and knowledge to delete entire Test Plans, considering what they contain, should be the only person creating them.  If everyone needs the ability to create/delete these willy-nilly, then you are doing it wrong, in my opinion anyway.

I am still in the midst of getting this back up and running so will update once we’re finished. There is an MSDN forum post out there regarding one bug I seem to have uncovered, if anyone wants to look at it and maybe fix my world by answering it I am sure I’ll be able to add some more tips and tricks by then.

Now, I am no @ZainNab, the guru of “Tips and Tricks”, but I occasionally run across features that have been staring me in the face for YEARS and yet somehow went completely unappreciated, sometimes unnoticed.  And then one day it hits me and OMG my life is easier, and I want to tell everyone.  Sure, it’s a bit embarrassing to admit sometimes given that I worked at Microsoft for 5.5 years focusing on the Visual Studio tools, but who hasn’t done that?  Not you? Really?  I am skeptical…  There are after all, a bajillion commands to try and remember. For real, if you don’t believe me, look at the entire book that Sara Ford and Zain wrote about it. It’s worth every penny and Amazon has a great deal on it, pick up a copy!

So, back to my point. I was sitting in MTM, looking at a fairly daunting list of PBI based test suites, thinking “now which PBI’s were the ones where I had test cases to run again?”  I started thinking about writing a query, but that only helps is YOU are assigned to the test case, it doesn’t really help with test RUN assignment. Then it all came flooding back.  Wait, there’s this FILTER button to sort that out.  And conveniently it’s right there in front of my face ::face palm::  I felt a little better when no one else admitted to noticing it was there either. Maybe they were just being nice to me.  Either way, in case you didn’t notice it, check it out. Before:

After, I have MUCH fewer test suites that I have to look at:

That’s my Microsoft Test Manager tip o’ the day!  I won’t be posting them every day like Zain has been doing on his blog around Visual Studio 2010 for the past couple of years, of course I also don’t mainline 5 hour energy like he does   I will do them whenever I can.  Hope this was helpful! Feel free to post any tips of your own or shoot me a note if you have other questions or comments.