You want to start organizing tests from day one, right? Or, if maybe you already created have your tests created , and it's time to organize them. 

...

At Test level

Classify your Tests

• Use use labels to tag your Tests (or your Test Sets); as if you start having many testers and your project grows and you have more testers, having a well-defined list of labels will may help.
• Use use the priority field, so you can distinguish between tests.
• Assign assign the Test to the proper component.

Using Test Sets

Organize Tests in Test Sets

• Group group tests in as many Test Sets as it makes sense to you, either because they're testing the same feature or the same UI component, or if they exercise the most critical use cases.
• Classify classify your Test Sets, similar similarly to what you did for Tests.

Organize Tests for regression testing

• You you can create a Test Set for this purpose , and add a specific label to it accordingly (e.g., "regression"), and then you test for covered issues requirements of previous versions.
• You you can create a "regression Test Set" for each version by adding cloning the previous version regression test set tests plus the new tests.and add more tests

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 all tests from that specific test set and all the ones some more tests for validating v3v2.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