What is a Test Plan?

A common question we hear is how and when to use a test plan in MTLM.

To most testers, a test plan is a document that describes the intended approach to testing for a feature, or more likely a group of features, for a specific release. It typically reviews the features to be tested, discusses the approach to testing, and it may even list some or all of the specific test cases to be run. It definitely covers timelines and deadlines.

In MTLM, we wanted to expand the concept of a test plan beyond just a document. The information in the test plan should be structured, able to be queried, and directly reference the test artifacts that eventually help define when the testing is complete.

So we start with the Test Plan Properties activity that exposes the high level values. We have a title, description, owner, state, start date, and end date. These values show up in the Test Plan picker and Test Plan Manager to help you find the right test plan you want to work in. It also holds information for running tests, like Test Settings and Test Environments for both manual and automated tests.

 

The test lead will probably set up this test plan artifact for the team. There is a lot of flexibility in defining scope and duration for a test plan. It really depends on how you want to use it. However, we can offer some guidance on when scope is too big or small, or when the duration is too short or too long.

Since we define a test plan as a test effort for an area for an iteration, it is up to you to define the area and iteration. For a product release, you could have 3 feature teams and 5 iterations… so should that be 15 test plans? 3? 1? 80?

Well, the answer to that, for me, is whatever is most convenient for you. However there are some hard requirements that we should review first. I think the biggest factor is who is driving and monitoring the test effort. If a project leader has to maintain and switch between several test plans, that ends up being tedious. So perhaps there are several feature teams working in a single test plan because there is a single owner, they’d each work out of different test suites. That way they could avoid stepping on each other, but… they could also have common areas which might be a bonus. It also means reporting can easily be scoped to the whole effort based on what is in the plan. The second most important factor has to do with test run settings. Do these efforts use the same build definition? Do they move forward to new builds at the same time? If not, it can be inconvenient for testers when they kick off test runs to have to manually select the real build they want to test with. So to sum up, the main factors for me are ownership, reporting, team affinity, and build selection.

The other activity that helps define a test plan, is the Test Plan Contents. This is where test cases are added to the plan, and optionally organized into test suites.

Both of these activities live under the Plan activity group.

Cheers,

David Williamson

Engineering Lead, MTLM