...

Example: You're working on product v3.0 and want to do regression testing to make sure you have not broken anything. If the previous version, v2.0, had already some regression tests in a specific test set, then you can clone it and add some more tests for validating v2.0. 

Using the Test Repository

The Test Repository organization follows an hierarchical, tree-like way of organizing Tests within folders. Since a Test can only be part of one folder within the Test Repository, you have to think in an hierarchical way "What is most important? How do I look for the Tests to schedule executions?"

• create top-level folders for the things that are most important (e.g., "performance", "security", "smoke tests")
• create the hierarchy from the things that are most relevant and then decompose each one; for example, if your tests are the "components" of the system, you can create a top-level "components" folder and sub-folders for each sub-component
• avoid mixing execution- or planning-related aspects in the Test Repository or you'll get messed up
• don't organize the Tests based on things that are volatile or can rapidly change