Creating new Test Plan per Iteration or editing the existing?

Question

We use Microsoft Test Manager to test out applications. We had initially created Test Plans for each Application we wanted to test. So our test plans have this structure:

Application A
Application B
Application C

Now, in each Iteration, we are getting new Builds for testing.

So, should we keep the same Test Plans and editing their appropriate fields (Build in use, Iteration, Configuration, ...) or is it better to create new ones for each iteration? Something like this:

Application A - Iteration 1
Application A - Iteration 2
Application B - Iteration 1
Application B - Iteration 2
Application C - Iteration 1
Application C - Iteration 2

Answer 1

And does it make sense to create a new Test Plan for every new build?

Test Plans are usually created for feature in general. And updated accordingly when the feature (Functional Spec) changes as well. But that's in in ideal world.

From this I can tell "Build in use, Iteration, Configuration, ..." that you are talking about the Test Reports rather than plans. Why not having a document with a Test Plan. And a separate
e.g. table in this document where you would update (add one line) of the configurations, build, evironment used for testing?

Answer 2

Taking into consideration definition and its a small workaround of the test plan:

The test planning process and the plan itself serve as vehicles for communicating with other members of the project team, testers, peers, managers and other stakeholders. This communication allows the test plan to influence the project team and the project team to influence the test plan, especially in the areas of organization-wide testing policies and motivations; test scope, objectives and critical areas to test; project and product risks, resource considerations and constraints; and the testability of the item under test. You can accomplish this communication through circulation of one or two test plan drafts and through review meetings. Such a draft will include many notes such as the following:

[To Be Determined: Jennifer: Please tell me what the plan is for releasing the test items into the test lab for each cycle of system test execution?]

[Dave - please let me know which version of the test tool will be used for the regression tests of the previous increments.]

As you document the answers to these kinds of questions, the test plan becomes a record of previous discussions and agreements between the testers and the rest of the project team. The test plan also helps us manage change. During early phases of the project, as we gather more information, we revise our plans. As the project evolves and situations change, we adapt our plans. Written test plans give us a baseline against which to measure such revisions and changes. Furthermore, updating the plan at major milestones helps keep testing aligned with project needs. As we run the tests, we make final adjustments to our plans based on the results. You might not have the time - or the energy - to update your test plans every time a variance occurs, as some projects can be quite dynamic. In Chapter 6 [Black, 2001], we describe a simple approach for documenting variances from the test plan that you can implement using a database or spreadsheet. You can include these change records in a periodic test plan update, as part of a test status report, or as part as an end-of-project test summary (c) ISTQB Foundation book

I recommend you to update your existing test plan in order it was possible to see any amendments or corrections made through the whole application development life cycle.