Wednesday, October 1, 2014

10 Reasons Microsoft Test Manager rocks!

Because I have some insane super power to break stuff, my role on recent projects has been quality and testing (or as I like to call it, driving my developers insane). One of the most popular tools for testing and writing test scripts is currently Microsoft Excel or Microsoft Word.

However, I have been using Microsoft Test Manager for the past 3 years and I absolutely LOVE it! I think anyone that has developers that use TFS for work management should use Microsoft Test Manager, and here’s why:

1. Traceability.

  • Test Cases can be traced to User Stories (Requirements) which can be traced to Tasks. Which means you can make sure that all of your tasks that meet your requirements have been tested.  You can also make sure that your system is thoroughly tested with Configurations, where you can set different browser and operating system configurations, but use the same steps to ensure that users are doing exactly what they are supposed to be doing in a consistent way across browsers.

2. Better Communication from tester to developer.

  • Bugs entered from a test run are detailed with each step a tester took up to the moment he entered the bug, and copied automatically to the bug from the test script. These bugs are linked to the test scripts so that you can easily re-test once the bug has been resolved.
  • Let’s face it, end users aren’t the most detailed when something breaks. But with Test Manager, you can see the steps the tester took, what applications they’re running on their machine, what browser they are using and what operating system. Plus they have the ability to add notes and print screens!

Bug Created Printscreen

3. Tests can be recorded.

  • Visual proof of what the tester did! How can it get any better than that? Now you can see exactly what the tester typed or clicked (or didn’t click).
  • The Action log details every mouse movement the user took, what Search term he entered and what he “actually” clicked.

Action Log Printscreen1

4. System Information is attached to tests.

  • When you run the tests through Test Manager, you get a nice little xml file with the testers system information that shows you what browser the user is in, what operating system, etc.  This can be a great tool if your developer is unable to reproduce the bug on his machine.


5. Shared Steps RULE!

  • On my current project, we have over 200 test cases, with a lot of similar steps, but with different security requirements. As with most projects, we had a couple (hundred) requirements changes, which means test cases had to change. Shared steps means that you only have to make that change in one place and it will automatically be reflected in all the test cases that use that shared step.

6. Create End User Test Script Document with Export to Excel

  • If you don’t have licenses to allow your testers to test in Test Manager, you can still write the scripts in Test Manager and export them to a format end users love…Excel
  • Thanks to the brilliance of my coworker, Jonathan Rupp, I am able to export all my test scripts into a beautiful format on my Windows 8.1 that includes formatting and shared scripts.  He has taken the Export to Excel  tool I found on codeplex for my Windows 7 machine and improved it a quite bit in order to include shared steps and html formatting and be compatible for Visual Studio 2012/2013 and Windows 8/8.1.
  • I could never use Shared Steps in the past because I knew that I had to export my test scripts to Excel for end users that did not have the licensing to use Test Manager, but thanks to the upgrades in the Export to Excel tool, I can.
  • You can find that awesome tool here: Export Test Cases to Excel


7.  Create a Detailed Test Plan by Exporting to Word

  • You can also export all of your test scripts to provide you’re a very user-friendly Test Plan with Test Scribe.   It details all the important information about your test plan including configurations, your Suite Hierarchy, Test Case Steps, etc.  It’s a Visual Studio add-on that you can get here.


8. There are two options to run tests in Test Manager

  • On the desktop application – which is my preferred way because it is the only way to turn on the recording while testing.
  • Via the browser – which gives you less functionality, but is easier for an end user to test without having to download test manager on their machine.

9. Organizing Testing Sessions is a snap

  • You can use Suites to create a folder and use the “Add” button to search for test scripts to add to that folder, or create a Query Based Suite based that automatically puts all test scripts that meet a certain query in a suite.
  • For Example, for Round 1 of testing, we had testers testing certain components, so we created Suites (much like a folder), that were called that component. For Round 2 we are testing based on User Role, so we named the Suites with the user role. Users don’t have to search through all the test scripts, they just go to their Suite, or if you’re printing, you just print that suite for them.
  • For manually created Suites, you can set the order of the test scripts, to allow a user to test steps in a specific order, and you can change the order at any time.

10. Test scripts can be automated

  • I haven’t personally done this yet, but I hear that it’s true. If you record a user walking through the test script, you do some sort of magic mumbo jumbo (coders call it programming) to turn it into an automatic test. You can find more information about that here: Creating Automated Tests