Page History

Purpose of Test Plans

A Test Plan defines, first of all, the testing scope (i.e. the testing that you aim to perform in some context). Test planning can occur in the context of a release, in the context of a sprint or in the context of "testing cycle" (i.e. some timeframe that you allocate to perform some testing).

The Test Plan is used as a basis to schedule Test Executions for all, or a subset of the Tests being tracked within it. 

As you may have multiple "iterations" (i.e. scheduling of multiple runs for the Tests by creating multiple Test Executions), you'll need a way to see the consolidated progress for all those "iterations." ; the The Test Plan provides you exactly that this by showing you the latest status for each Test being tracked within the Test Plan.

How many Test Plans?

In the simplest scenario, you can have just one Test Plan with all the tests that you aim to perform (no matter their nature, neither their type nor if they're regression related or not).

Eventually, you may have multiple active Test Plans at the same time. The main reason would be if you want to manage & track test progress independently.

Although being totally it's up to you to decide, you may want to have more than one Test Plan,

• if overall you want to manage each Test Plan independently
• If if each Test Plan lifecycle is independent
• if you want to assign each plan to different teams
• if you want to clearly distinguish the results from different tests, because they, for example, bring different value (e.g. automated testing vs manual testing, regression testing vs non-regression testing, integration vs E2E tests, functional vs non-functional testing)

Coverage Analysis

You can analyze your coverage (i.e. how your "requirements"/user stories are) from the release perspective, and for that, the number of Test Plans you have is irrelevant; what matters are is the Test Executions assigned to that release and the respective Test Runs.

If you want, you may eventually perform coverage analysis just by considering explicitely  only the Tests and related results performed in the context of some given Test Plan, so you can assess what requirements are being "covered" by that Test Plan and what is their status if we just consider the results performed in the scope of that plan.