Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Thus, a general setting enables users to globaly opt-in or opt-out of this hierarchical way of organizing Tests.


Table of Contents

Key concepts


Within the Test Repository screen you can see some meta-folders that provide you quick ways to see or filter some relevant Tests. These folders are read-only and will be used mainly as basis to select the proper Tests before adding them to folders within the Test Repository itself.

...

In a given parent folder, it is not allowed to have folders with similar names. For this, Xray does a case-insentive check of the trimmed folder name whenever you create or rename folder in order to evaluate if a similar folder already exists within its parent. This means that these folder names would all be considered to be the same: "  phanTom", "phantom", "PHANTOM". Please note that it is not allowed to use the "/" in the folder name.

Recommendations

  • Think well how to structure the hierarchy of folders, having in mind that a Test may only be in folder; how would you organize them in your laptop if you were dealing with documents? Start by identifying the  folders that you want to put at the root and then try to drill-down on them, by creating sub-folders that are relevant to you
  • If you're already using Test Sets, don't try to replicate the Test Sets model in the Test Repository because most probably it won't work. Have in mind that a Test can only be part of a Test Repository's folder, while with Test Sets a Test may belong to several Test Sets  
  • Avoid putting semantic related with the execution phase in the Test Repository or else your Test Repository will end messed up; Use the proper entities, such as Test Plans (and respective Boards) to make planning/execution related organization 


Test Repository vs Test Sets

Test Sets are simple, flat lists of Tests that you can use as basis for creating Test Executions or Test Plans. Tests can be part of different lists (i.e. Test Sets), each one grouping Tests in some logical way, such as grouping all Tests related with regression testing or with a component or with security or with performance or with some high-level feature/business case. Test Sets can also be used as a dynamic way to cover requirements.

...

They can also work in a complementary way, if used properly in more advanced usage scenarios. Such a scenario could be using Test Sets as a way to cover complex requirements and use the Test Repository as the place to organize the Tests.

Pros and Cons

ProsCons
  • Hierarchical concept, similar to computer folders, may be more easy to understand specialy for users coming from legacy Test Management tools
  • Can live side by side with the existing Test Set concept (think first if you want this additional "complexity")
  • A Test can only by in one folder… so it cannot be categorized in multiple ways simultaneously (as you can do by using labels)
  • A folder cannot be used as a way to cover requirements; Test Sets can
  • Test Sets can also be used as a dynamic way to cover requirements; Test Repostory folder's can't

...