Complete Test Planning in Microsoft Test Managers 2015 and Organization of artifacts

Management of testing efforts involves planning the execution of tests, tracking the test execution and then controlling the testing efforts so that either they are according to plan or the plan is modified to suite reality of environment. Before we can plan the testing efforts, it is necessary to have artifacts which are used as building blocks for the plan. One of the major artifacts is test cases. In the earlier session we have studied the definition of test case as work item type. In this article we will view the details of other artifacts and also the way to create them using the ‘Organize’ section of Microsoft Test Manager 2012.

Organize section of MTM has four subsections to manage Test Plan, Test Configuration, Test Cases and Shared Steps.

Test Plan

It is an artifact which works as a container for number of other artifacts like test cases, configuration etc. It is possible to create multiple test plans for a team project. Each of the test plans may reflect different conditions encountered for test planning. My suggestion is to keep the number of test plans in a team project to minimum and only one if possible.

Test Plan has a section for providing Run Settings. That is further split into three parts. These parts manage Test Settings, Test Environment and Test Configuration.

Test Settings:

These are collection of properties that are assigned to test plan. It gives a direction to tester to do manual testing or an automated testing, use specific role and matching environment that may be virtual or physical and to use specified diagnostic data adaptors to collect diagnostic data during test execution. We can provide separate test settings for manual test runs and automated test runs. Although Default Settings are provided, we can override those by providing a named collection of settings which are customised.

Diagnostic Data Adaptors: These adaptors collect data during the execution of test. Data collected and recorded by them is part of the evidence for the test and if necessary a bug. It can throw light upon the facts of the application execution and provide clarity to developers while doing bug fixing. There are various such adaptors that collect data of different aspect of the application execution while testing.

These diagnostic data adopters take space on hard disk to store data and other resources while collecting the data. This can slow down the computer where we are running the tests. While enabling these adopters consideration should be given to this fact and then if necessary only the data should be collected. If we are running any exploratory testing then al the data adopters can be disabled and when running the targeted test only some of them should be enabled. If we encounter a bug which is hard to visualize as well as reproduce, then we should enable more number of diagnostic data adopters and run the test. We may have different named collections of test settings to achieve different combinations.

In this article we have seen Test Plan and Test Run Settings as different artifacts that are used to define the testing efforts. In the next article we will cover other artifacts like Test Configuration, Shared Steps etc.