Test suite
A named grouping of test cases, usually by feature, component or type of testing, forming the structure a team browses and selects from. Suites organise the library; runs execute from it. Keeping that distinction is what stops a suite from becoming a record of one release's execution and losing its reusability.
Also called: test folder, test collection
Organise by what the product does
The structure that lasts follows the product: one suite per feature area, nested groups for sub-features. Structures built around something else age badly. Suites named after sprints or releases stop making sense two releases later. Suites named after testers fall apart when people change teams. Suites named after test type (smoke, regression) collide with the feature structure, because the same login case belongs to both.
Suites and tags do different jobs
A case can sit in one place in the tree but carry many tags. Use the tree for where a case lives and tags for the ways you slice it: smoke, regression, mobile, high risk. A smoke run then becomes "every case tagged smoke" across all suites, and nobody has to maintain a separate smoke suite full of copies that drift from the originals.
How deep to nest
Two or three levels cover most products. Deeper trees look tidy on day one and make every case harder to find, because the person searching has to guess the same path the author chose. If a group holds two cases, it probably should not be a group.
A suite is not a run
Marking statuses on cases inside a suite, release after release, overwrites the previous release's results. Execution belongs in a test run created from the suite, which keeps the library clean and the history comparable.
In QAM Hub
Suites hold nested groups up to six levels deep, and cases carry tags for filtering across suites. Setup is in creating test suites and cases and tags and organization.