Microsoft Test Manager is a great tool for executing manual tests over a set of known paths through an application. It allows you to create and action test scripts and record to minimise duplication of effort. At first glance, this seems to be the extent of functional support for testing within the tool – however if we dig a little deeper there’s some real nuggets of gold hidden in there. In this article we’ll talk about how the practice of exploratory testing is supported by the tool and how you can turn an unplanned edge case test into a formalised, repeatable test in a matter of clicks.
Setting the scene for exploration
The test manager interface is primarily geared around the creation and organisation of test cases. Even though we’re not going to be executing a formalised test case in this instance, we’ll still need to have a test case to serve as an aggregation point for our results and collector data. So let’s start by creating a new generic test case. To do this, follow the normal steps for creating a test case up until you’d normally start filling out your steps.
Setting up a test case for exploratory testing
At this point enter a single step describing what you’d like to explore. While this isn’t entirely necessary, it serves as a result indicator for the exploration which we can then use in the manager interface and our reports.
Once you’re happy with your test case let’s put on our safari hats and get to exploring…
Dr Livingstone, I presume?
The scenario from here is elegantly simple. We move into the test runner by running the test case we created and start exploring the application. When you kick off the test, ensure you choose to create an action recording so that you’re capturing the paths through the application you’re exploring.
Remember to check the action recording box
If you happen to come across a bug during the exploration you can mark the test step as failed and raise a bug against it.
This will capture the action log, and any other data from the collectors you’re running and associate it with the bug for the developer to help diagnose the issue. In this particular scenario, the action log serves a second purpose which we’ll get to shortly.
What was once random, is now repeatable
Once we’ve completed the test execution and are back in the test manager, we can navigate to the Verify Bugs screen of the Test tab.
Click the link to the verify bugs page
On this screen we’ll see a list of bugs based on a filter. The filter is adjustable but starts with an ‘assigned to me’ criteria.
Change the filter to capture the bugs you require
If we click on one of these bugs the ‘Create Test Case from Bug’ button will activate.
The 'Create test case' button should activate
If we click this button a new test case will pop up with a set of steps derived from our action recording pre-filled and ready to go. The steps are editable as a normal set, so we can remove any we feel are irrelevant or even apply parameters and generate a set of shared steps if we like.
The test case should be largely pre-populated
Once you’re done editing the steps, save the test case and voila! There is a formal test case that can now be used to verify the path you’ve discovered a bug in. From here you can bring the new test case into the appropriate suite and ensure that as the application evolves this now known path is tested effectively.
Exploratory testing support in Microsoft Test Manager makes dynamically discovering new paths and bugs in your application more effective by enabling you to record your steps and generate formal test cases from them. This helps to eliminate those hard to reproduce edge cases where you can never quite remember what you’ve done to get to the bug, and will help you on your path to a higher level of software quality.