Exploratory Testing in Visual Studio 2012

  • Article

With the recent release of Visual Studio 2012, there are many new features and updates to explore. One of the new features is Exploratory Testing, which allows you to test your software without a pre-defined test or script. It’s perfect for simply “exploring” your application to see what issues you may encounter. Exploratory Testing comes with the Test Professional, Premium, and Ultimate editions of VS 2012.

Technically, Exploratory Testing is part of Microsoft Test Manager (MTM). In VS2010, one could achieve exploratory testing by filing an exploratory bug in Test Runner. From there, users/testers could execute unscripted actions until a bug was found. But in VS2012, exploratory testing is pulled into MTM along with your other tests, plans, suites, tracks, work items, etc. You can learn about some of the other new features in MTM 2012 in MSDN Magazine. In order to use Exploratory Testing in MTM, you must be connected to Team Foundation Server (TFS) 2012. If you don’t have access to a TFS 2012 instance, you can try out TFS in the cloud free, for a limited time, at https://tfspreview.com. The instructions at that site are simple and include everything you need to create an account, project, upload source, automate builds, etc. 

NOTE: At the time of this writing, no information was available as to how long tfspreview.com would be available (or at least, available for free). While the end goal of TFS Azure is to have all the features of TFS, you may find that not all features of TFS - such as Reporting Services, AD Federation, etc. - are available at tfspreview.com.

 

With exploratory testing, you can literally browse through your application at your leisure, until you find a bug or some other part of the software that should be considered for change – editing text in a label, background color change, adding or removing a feature, etc. And the whole time you’re “exploring” the application, MTM records your actions. By default, actions you execute in MTM or Office applications are not recorded, though you can change this in your test plan properties (Testing Center, Plan, Properties). Exploratory testing in MTM allows you to do the following:

  • Pause and resume recording of your exploratory test case
  • Enter comments and screenshots for your exploratory test. This can help clarify recorded activities in your test.
  • Create a bug
  • Generate a Test Case for the bug you just created

 

Exploratory testing can be used on web applications, windows applications, and if it’s a client/server application, some steps on the server side can also be recorded. More details on this, as well as the steps to run an exploratory test can be found at https://msdn.microsoft.com/en-us/library/tfs/hh191621(v=vs.110).aspx. While I have no desire to copy what can already be found on MSDN, I also know that sometimes links change, content is moved, etc. Therefore, I’ll repeat some of those steps in this blog entry.

  1. Open MTM.
    1. You can perform exploratory testing with no existing work items. To do this, simply right-click a Test Plan or Test Suite and select Explore.

b. If you do have an existing Work Item, you can perform exploratory testing on a specific work item by going to Test, Do Exploratory Testing. Then right-click on your work item of choice and select Explore.

 

2. When you select Explore, the Exploratory Testing window opens, waiting for you to Start your test. Once clicked, MTM records your actions.

 

3. You can pause or end the test, and this pauses or ends recording of your actions. At any time you can enter comments and/or add screen captures in the Exploratory Testing window. Additionally, if you run into a bug you can click the Create Bug button during recording, and fill out details of your newfound bug. When you save your new bug, you’ll have the option to create a Test Case for the bug you just created.

 

These are just the steps to get you started, and there are many other options for saving Test Cases, assigning & editing bugs, and more. Exploratory testing is a great option when you don’t have a defined test, a defined script as to how to navigate directly to a specific bug, or even when you don’t have a specific idea of what problem you seek to uncover in your application.