Xray v3.0 introduces hierarchical Tests organization both at the project level, with the Test Repository, and also at Test Plan level, with the Test Plan Board.

While the Test Repository concern is related with the organization of Tests in the scope of a given project during the specification phase, the Test Plan Board concern is on organization at planning level (and as consequence, at execution).

A Test Plan contains a group of Tests that you wish to validate in some version, and aggregates the results from multiple iterations (e.g. Test Executions).

For a given Test Plan that is tracking some group of Tests (e.g. regression testing related test plan or new features related test plan) you may wish to group Tests 

the Test Repository concept which allows hierarchical Tests organization at project level, by allowing users to organize Tests in folders.

organize the Tests by component or by sub-system or by functional/non-functional or by any other criteria.

The (Test Plan) Board gives you the possibility to organize the Tests that are part of your Test Plan in multiple folders and sub-folders. Implicitly, you can also define the order of the Tests and the relevance of those grouped Tests (i.e. folders) by ranking them within the tree presented within the Board.

By providing you the ability to define groups and sub-groups (i.e. folders and sub-folders) for the Test Plan's Tests, you're able to track them independently and see right way their current status, even if the scope of the Test Plan is broader. You can also more easily do operations for those subset of Tests, such as creating Test Executions .

This hierarchical approach is different from the traditional, flat way of organizing Tests inside the Test PlanThis is a different approach from the traditional way of organizing Tests in flat lists by using Test Sets, which was the only available before Xray v3.0.

Users coming from legacy Test Management tools may find this way more natural and more intuitive. Other organizations may prefer to not enable this feature at all and choose the Test Set approach instead.

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

Key concepts

Within the Test Repository Plan Board 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.

• All: all Test issues within the current project (independently if they're organized or not)that are part of the Test Plan, ordered by their Test Plan rank
• Orphans: all non-organized Test issues (i.e. Tests that are not part of the Test RepositoryBoard), in the context of the current projectTest Plan
  

Besides these folders, you can also see the Test Repository Board itself that contains the hierarchically organized tests for this Test Plan.

• Test RepositoryBoard: the actual Test RepositoryPlan Board, composed of multiple folders and sub-folders along with Tests, in the context of the current projectTest Plan. It corresponds to the root folder.

Within the Test Repository root Board root folder, multiple folders can be created and Tests can be added to them.   The root folder may only contain folders. Similar to traditional operating systems (e.g. Windows, OSX, Linux), Tests may only be part of one folder.

Tests can be added (i.e. "moved") from the All or from the Orphans meta-folders to the destination Test Repository Board's folder, by selecting and moving them using drag-and-drop. Besides this, Tests can also be moved between folders. The user can also choose the Tests to add to a given folder, by selecting the folder and choose the "Add Tests" context action for adding Tests using filters or JQL.

Folders can be created at the root of the Test Repository Plan Board or in any (sub)folder within it.

...

• 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

...

Plan Board vs Test

...

Repository

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.

The Test Repository concept is a bit different; you have to think a bit similarly to the way you would organize your documents and files in your computer.

Thus, the two approaches offer advantages and have some possible drawbacks.

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

What are the differences between Test Plan Board and the Test Repository?

They are two completely different things because their scope is different.

The Test Repository is a project level organization of all the Tests contained within a given project. Thus, it's something with a more broader scope, where one or more authorized users organize the Tests in multiple folders, in some logical way, without being concerned with execution related aspects. Thus, the Test Repository can be used as basis for creating any other entity, such as Test Sets, Test Plans, Test Executions.

The Test Plan Board is a Test Plan level organization; it allows users responsible for dealing with some Test Plans, to structure their plans more effectively, so they can give priority to the execution of someTests first and also have clear visibility on how different sets and subsets of tests are within the Test Plan.

So, independently on the way you organize the Tests in the project, by using the Test Repository, you may choose how to organize Tests within each Test Plan by using the respective Test Plan Board, in order go gain finer visibility of the current status of different subsets of Tests and also to schedule executions for them, as an example.

Pros and Cons

The following table summarizes some pros and cons of using the Test Plan Board.