Azure DevOps, Scrum, & .NET Software Leadership and Consulting Services

Free course! Predicting the Future, Estimating, and Running Your Projects with Flow Metrics

Microsoft Test Manager is pretty much done. What’s missing and what do we do now?


Ok.  Microsoft Test Manager (MTM) isn’t going away but you might have noticed that it’s kind of been put out to pasture.  There were some good features – some core features – in MTM that were kind of helpful.  So what do you we do now?  If you’re on Team Foundation Server 2015 (TFS2015) what’s missing?  What’s your strategy for the future?

How did we get here?

Microsoft Test Manager (MTM) is the “rich client” for QA and Manual Testing that hooks in to TFS.  It’s been around for a long time and while it’s a great tool, it’s infamous for having a difficult and confusing user interface mostly because it had two missions that were only loosely related.  Mission #1: test case planning, management, & execution.  Mission #2: virtual test lab management.  The world has changed a lot since MTM came out – TFS is no longer laser-focused on Windows-only development and cloud computing is huge.  Test case management is pretty much still the same but what we’re testing is a lot more varied and cross-platform.  How we manage our virtual test labs is vastly different now.  MTM was written before Microsoft Azure or Amazon took off in the cloud space.  Put those two huge changes together and it’s a no-brainer that Microsoft had to take their QA/Manual testing tools in a different direction.

What’s changed?

Before we start discussing what’s changed and what’s gone/going away, I just want to say that life is better now and the tooling is so MUCH better now.  The biggest change is that pretty much everything’s moved to the web and you no longer have to fight your way through MTM’s nonsensical user interface design.  [insert the sound of rejoicing crowds here]  The web interface makes sense. There’s no longer an artificial separation between planning your tests, running your tests, and tracking the results – everything is in one, unified interface.  Want to plan a test?  Create one or just start editing an existing one.  Want to run a test?  Click the Run button.  Want to see the status of a test case?  It’s right there in the user interface.

The second biggest change is that Lab Management is done.  The build system that was at the core of Lab Management has changed.  (NOTE: those XAML-based builds are still there but there’s a new build system that’s a lot easier to use.)  The deployment features of Lab Management have been moved in to TFS Release Management.  TFS Build vNext and TFS Release Management work in concert to get stuff deployed on to servers and the integration with the QA tools are now entirely optional.  Trust me…you won’t miss Lab Management.

You’ve now got two options for running tests: 1) run test cases using the web interface and 2) run test cases using the MTM client.  At this point you’re thinking, “didn’t you just say that we’re pretty much done with MTM?”  Short answer: yes.  Longer answer: you’re done with using MTM to plan and track your tests but you still have the option to run tests using the MTM rich test client.  This makes sense because the really handy stuff from the MTM Test Runner was the ability to create really descriptive bugs that contained screenshots and video recordings.  Microsoft split that test execution functionality into its own EXE so you can still do all that great stuff.

Using the MTM Test Runner also lets you continue to do lightweight test automations using MTM Action Recordings.  The idea with Action Recordings is that a non-technical QA person would be able to create automated tests that help speed up the QA testing process and eliminate QA testing tedium.  That Action Recordings feature makes for some jaw-droppingly awesome demos.  In real life, it’s still pretty limiting and brittle.  It only works with certain types of Windows application technologies and for web apps it only works with Internet Explorer.

If you want to do more free-form exploratory testing, there’s a new Exploratory Testing client for Chrome.  It’s pretty good and it gives you the ability to do screenshots and video recording, too.  Last time that I checked, it was still in beta and as such it still had some sharp edges.  Microsoft is definitely going in a good direction with that plugin though.

What’s missing?

The biggest thing that’s missing from the web interface is Test Configurations.  Go ahead and try this out.  Go into the test hub and create a couple of Test Cases and then look in the Configuration column.  The Configuration column says “Windows 8”, right?  Why the heck does it say Windows 8?  I’m not testing on Windows 8…so how do I change that? Well, through the web interface, you can’t.  If you want to edit Test Configurations, you need to open Microsoft Test Manager.  (Grrrr.)

Test Hub Test Configurations always say Windows 8

Do you really even care about this?  The answer is a definitely maybe.  If you’re just testing your application and you don’t really care about what browser or operating system or whatever miscellaneous details about the environment, then you don’t care about Test Configurations and you can completely ignore that “Windows 8” thing.  If you’re more thorough in your QA testing and you need to track behaviors of the application on various operating systems and browsers, then you care a lot.

The ability to edit Test Configurations via the web appears to be coming in the next version of the product.  For now, you’ll still need to pop into Microsoft Test Manager for that.

If you’re doing video recordings of yourself running your tests using the MTM test runner client, you’ll need to configure those settings in Microsoft Test Manager, too.

Another thing that’s missing (more like deprecated) is the Associated Automation feature.  That used to let you hook a Visual Studio Coded UI test directly to a Test Case and then have it run as part of a Lab Management build.  Since Lab Management is pretty much done, this means that Associated Automations are just about done.  I wouldn’t sweat this too badly though because running just one Coded UI test is kind of a weird choice in the first place and it makes a lot more sense to just hook your entire Coded UI Test suite in to your vNext Build or Release Management flow.  If you do that, the results of those tests aren’t tied to a specific Test Case but you still get to see the results in the Test Hub’s “Runs” tab.

Summary

In summary, just relax.  Everything’s going to be fine.  In fact, everything’s already fine and life is already so much better by not having to live in Microsoft Test Manager anymore.  Plus, in the next version of the product, Microsoft’s goal is to bring us even closer to “feature parity” between MTM and the web.  You have pretty much all the same features that you know and love from MTM but they’ve just been cleaned up and organized.  If you’re looking for something, the answer is that it’s probably moved to the web.

-Ben

 

— Got questions about where to take your TFS QA testing strategy?  Need help getting going with Agile Testing with TFS?  Want to better join your QA testing effort into your overall DevOps pipeline?  We can help.  Drop us a line at info@benday.com.

SUBSCRIBE TO THE BLOG


5 responses to “Microsoft Test Manager is pretty much done. What’s missing and what do we do now?”

  1. Donovan Woods Avatar
    Donovan Woods

    Hi Ben,

    I wrote a test automation framework that extends Coded UI (and spent the better part of 3 years doing so). It’s pretty nifty, but I’m hearing “rumors” that Coded UI is going away. We’re now using TFS 2017, and the Associate Automation feature is still present. Thought this article was interesting, but that point did not seem to be right. Any credence to the notion that MS is depreciating Coded UI?

    1. Ben Day Avatar

      Hi Donovan — I’m not sure about whether Coded UI is officially being deprecated but it’s not getting all that much “love” lately especially for web-based testing. For example, Coded UI still doesn’t support the Edge browser. My thinking on it is that if you’re testing a web application then Selenium is the way to go. If you’re testing a Windows application, then Coded UI is still a pretty good option.

      -Ben

  2. Brecht Avatar
    Brecht

    Coded UI documentation now shows a notice confirming Visual Studio 2019 will be the last version of Visual Studio supporting Coded UI. So it’s official now. It’s suggested Appium with WinAppDriver should be used instead.

    See https://docs.microsoft.com/en-us/visualstudio/test/extending-coded-ui-tests-and-action-recordings-to-support-microsoft-excel?view=vs-2017 or other documentation about Coded UI Tests.

  3. Amine Avatar
    Amine

    Hello,
    Currently, we use Microsoft Test Manager 2017 (Version 15.129.27701.7) on premise to manage our test plans, it is impossible for us to export the different test cases. We did not find the Export feature

    Can you please tell us how to do this with this version of MTM 2017?

    Thank you in advance for your return

    Best regards,
    Amine

  4. Vidya Avatar
    Vidya

    When I view the Test Plan in the Web Interface I see the Test Case count multiplied by the Browser count. Configuration column shows all the Browser options set which is 5. Even if there are only 15 Test Case in Test Manager, the Web View shows 75 (15 Test Cases multiplied by 5 Browsers). Is there a way I can view Test Cases only for a single Configuration – Chrome Browser in Web View so that my test case count would be 15 and not 75.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.