Subscribe Join 180,000+ subscribers and receive articles from our blog about software quality, testing, QA and security. Subscribe

Using TestRail across multiple JIRA Projects

Hi all,

We currently have a single project within our TestRail setup that we use to manage our tests cases across multiple squads/projects. However, each of these squads has its own JIRA project and in some cases, they follow different release cycles than other teams.

From a reporting perspective, I’ve set it up that we report back on work done within the duration of the primary sprint (as it is a set period of time) as there will always be an overlap between longer release cycles and shorter ones. However, I feel as though this may not be the most efficient approach.

Are there any organizations that have set up their TestRail instance to map TestRail project to JIRA project? As it stands, our current set up would be:

TestRail 1:M JIRA

However, I would like it to be

TestRail 1:1 JIRA

Is this viable? Has anyone achieved this? If so, what sort of pains can you expect? My main concern would be that we don’t have a singular reporting view anymore.

Hi @AnwarParker,
I’m not sure if I got your point completely because you mix instance and project in your description therefore I try it this way.

A TestRail instance can be linked against n Jira instances (will be a config hell, but…), because you can have a setting per TestRail project.
From within TestRail a user is able to add defects to any Jira project where he has access to. There is no general way to restrict this, probably via a UI-scripting.

A JIRA instance is as far as I remember linked to one TestRail instance via the plugin config only.

So, what do you finally want to achieve?

Hi kwirth,

Apologies for the confusion.

So, with TestRail and JIRA, our organisation has 1 instance of each. In other words, we have an active subscription for TestRail and JIRA. However, as you know, you’re allowed to have multiple projects wtihin both TestRail and JIRA. As it stands, we currently a single project on TestRail linked back to multiple JIRA projects. For example,

TestRail Project (1) : JIRA Projects (M)

My questions was whether it would be easier to have a TestRail Project per JIRA Project in that we have a TestRail Project per Squad (JIRA Project) basis or maintain our current schema in that we have a single TestRail Project (1) : JIRA Projects (M). I used squad towards the end there because some squads manage 1:M apps and some squads manage 1:1 app. However, there is heavy overlap between apps and/or test coverage between functional squads and thus the lines are can sometimes be blurred between ticket ownership.

I’m not sure if I’ve clarified this a little better but I’d be happy to chat on an alternative platform.

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…

  1. 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.
  2. 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.

1 Like