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

How to import JIRA bug to Testrail?


Our project wants to use Testrail as the QA management tool. I’m very happy with its reporting function, which supports TM to generate milestone report, and QA effort report, etc. However, after a while I realized the report only reflects part of the QA work. Let’s take milestone report as an example. The QA work in a milestone always consists of (at least) two parts: case execution, and bug verification. Some of the bugs may not link to any case. And in agile project, due to the time limit, QA cannot create case for every bug.
This means part of QA’s work cannot be logged in the report, and TM has to create a report somewhere else, to put both JIRA report and Testrail report in that.
So I want to ask, is there any way that we can import JIRA bug into Testrail independently? If not, do we have any workaround for the report instead of making information scattered everywhere?


Hi @Elaine

We use the References field to capture Jira references. It does need to be configured but once it is, you can have multiple references within a test ticket / case. These are comma separated values.

Once the configuration has been sorted, whatever naming convention you use, you just need to enter the value after the ‘…/browse’ i.e. ticket-number-123, ticket-number-456

That will then link to Jira but also when hovering over the hyperlink, will display the information from the Jira ticket. Those values will then pull into all the reports if you add the column ‘References’ in when creating the report. Unfortunately, this column is not a default column and has to be specified every time you need it.

Hope that makes sense.



Hi Bryane,

Thanks for your quick reply! Actually my project has already configured the “reference” field correctly. However, that means we still need a test case. Otherwise there will be no way to only input bug/reference into Testrail. So for instance, QA verified 30 bugs (for old functions) and executed 50 cases (for new functions) for a release. If we have no cases could link to the 30 bugs, there will be no way for QA to generate a report containing all of the effort and result.
I’m thinking we can create a fake case, just copying paste the name from the bug, and log the result there. But I feel like it’s not the best way, and want to know if there is any good practice from the others.

Thanks again for your help and support,


Hi @Elaine,

Glad to help. We’ve all been in this position and having the forum is great.

I’ve implemented TestRail in three organisations now and in all instances, we had to just accept that there would be an embedding in period where there was an overlap between new and old process i.e. other tools and TestRail. During this time, the business accepted that reporting might not reflect 100% of the picture but they were given a deadline of when everything might move over. In addition, they were also given the choice of retrospectively aligning Jira and TestRail but were provided with high level estimates of how much extra work was required to achieve this.

However, in one organisation Jira and TestRail matching was required. What did was to raise the individual high level tickets with specific notes that they were raised in retrospect of the work being completed, and therefore might not contain all the relevant detail. We then imported the test cases via Excel CSV files and had the ticket reference linked within the CSV file.

Process we followed when business required the aligning of TestRail and Jira:

  1. Raised tickets in TestRail retrospectively
  2. Created TestRail import CSV file with all test cases (you can break it down per ticket or have one file for test cases for all tickets)
  3. Created relevant test runs
  4. Added test results for all test runs
  5. Closed all test runs
  6. Ran all required reports

To summarise:

  • The above process might work for you if you only a few tickets or if you have several testers who can share the load.
  • It might be better to accept that there will be a period of overlap where results don’t match 100% which will require a conversation with the business.

You need to choose the process that will work best for you. I’ve done both depending on organisational requirements and time / resource availability.

Hope that helps.

Thanks and Good luck,