first of all, welcome to the club… I had the same issue in the past.
I don’t think there is a 100% correct answer for you. The next lines should explain my point of view.
Obviously having one project in each is the easiest way, and then…
- Then it usually starts in Jira to separate by project (for a team, a product, a group of processes etc. - or squads) because of different ways to handle things… Depending on the need to separate based on access privs the projects still can work together although there might be limitations or ‘missing comfort’ compared to one big project. Usually accepted.
- Separating the test activities in TestRail starts with the wish to follow different test strategies by using different fields or field values (there aren’t processes you can customize like in JIRA) or for the need of different privs OR because JIRA is separated, TestRail should simply follow. WIth the correct privileges you can work across projects and probably copy/move artifacts between the projects, but you can’t share them, which hits the execution of test (especially regression tests) dramatically.
That beeing said:
I would try to keep a 1 project solution in TestRail as long as possible. By this you can share everything between the squads. Using a suite per squad (or a squad is having multiple suites). Using milestones, sub-milestones, testplans and runs need a good definition can can help a lot.
If you really have the need to separate because
- the repository is getting to complex,
- stakeholders want to hide info between each other (my beloved one), or
- stakeholders want to have other fields and/or values.
You have to consider the fact, that you can’t use cases in test runs across projects (even not across suites). Each project having it’s own version of the (same) case leads into a an update hell. You can try to solve this with a common project, offering cases for every project. But this leads into trouble with reporting and is a disaster for those having the idea to implement sequences.
If this is less important you can separate, but the squad needs to be aware of the clear limitation by using different projects. If this is not the big deal it gives you the freedom to optimize on squad level.
Functional overlapping between the squads is already a big challenge for the defect/bug/ticket management between separate projects in JIRA, especially if you move them frequently between the projects. The external link to TestRail makes it even harder. Although Jira handles the move of issues (old issue-id is redirected to the new one), TestRail still has the old one. What is a mess for reporting. Updating TestRail is nasty and even not possible one a run is finally closed. Usually not a problem for high prio issues, but for the backlog of minor ones.
No real answer, but probaly something to thing about for you.
Finally I came up with separated projects in TestRail to Jira (to ProductUnit) by giving the advice to the limitation/separation of projects and having a numb ear, if the project is complaining about sharing cases.