How organize Test Plans?
I need some advice on how to organize Test Plans within TestManager, as I am in the process of setting up a Test Management for a quite complex product.
We do not work RUP-like, so some TestManager-mechanisms do not apply. However, I do not fully understand how to organize TestManager Test Plans. I understand the strategies like to organize them by means of use cases or functionality, but need some advice how to 'generally' structure them:
Our product gets heavily extended and we have in average two full releases per year. The product exists in about 10 different configurations, that partially differ significantly in their behaviour. Furthermore we have patches for up to four different versions of our product, that need to be tested.
So as you see, there is a lot to be tested, and I am unsure, how to reflect this properly within TestManager. My current approach is to create one Test Plan only, that contains 'all test cases'. The actual test cases to execute get assembled in Test Suites. As we are just at the beginning of the introduction of TestManager, we can live with this approach, but I'm afraid, we run into problems soon. I reckon, we should use Test Plans for one project only. This implies, that we need to copy previous Test Plans as a basis for new Test Plans.
Could someone please give me an advice on how to handle Test Plans?
Re: How organize Test Plans?
"The product exists in about 10 different configurations, that partially differ significantly in their behaviour."
My advise is to create 1 testplan for all shared functionality (shared functionality)
Create for every product a seperate testplan with all deviations on the functionality.
So finally you would run suites "shared" + "product 1" suites.
As you do not use RUP, that does not matter, but make sure you have clear and understandable version numbering to use for the testlogs and all those patches and updates are nicely stored in the database.
Did it myself and it works fine for me.