A customized coherent workflow set-up between Testlio Platform and clients Jira  via statuses mapping is the biggest benefit of the integration because it links two teams (Testlio's testers and client developers) to work as one and communicate on the same issues from their own native work environments.

Workflows in Jira are highly customizable. While syncing with Testlio we try to make our integration as flexible as possible so we have two ways of mapping issue status change in Testlio to transitions in Jira and vice versa as following:

1. Normal transitions: 

  • used with a simple Jira workflow.
  • status changes can be mapped with a single transition in Jira.

Below is an example of a simple workflow and how we map it: 

In this workflow, each Testlio status can be reached with one Jira transition only, so the mapper would be something like the following:

2. Jumping statuses with multiple transitions

  •  Workflow is more complex.
  •  Status change in the Jira side requires jumping over multiple statuses in order to transition to the mapped one.

For example, once creating an issue 'Open' status, if there is no direct transition to 'Closed' status and the tester/client needs to close the issue in Testlio, then the integration configuration needs to learn the transitions required to reach the 'Closed' status.

What are the Testlio's Statuses?

  • Open: Tester reports issue (needs approval)
  • Open & Approved: open bug/issue is approved by Test Lead or QA Engagement Manager to be synced to the client's Jira.
  • Open, label: "Fixed" added: Bug fix to verification. When the developer from client-side picks up an issue from Jira, implements a fix and submits it back to Testlio for verification.
  •  Open, "Fixed" label removed: Bug fix rejected. Whenever a tester rejects the fix made by the developer and sends it back for debugging.
  • Closed, with a "Fixed" label: Fix verified. When Tester validates and approves the fix made by the developers.
  • Closed without "Fixed" label: Bug rejected. Client or QA Engagement Manager wishes to ignore this bug or close it without a fix.
  • Reopen: Fix rejected. When the issue is reproducible after closing it.

What are the main objects we sync by default to Jira? 

By enabling the integration we sync by default issues:

  • Summary
  • Description
  • Comments
  • Attachments
  • Comments' attachments

Testlio --> Jira, one-way sync. Optional add-on fields/features?

We have some fields that can be switched on/off in integration configuration:

  • Sync Components from Testlio to Jira only.
  • Sync Environment field like devices/OS from Testlio to Jira only.
  • Sync Build version from Testlio to Jira only.
  • Add Prefix to issue title in Jira that was created by Testlio e.g. [Testlio].

Testlio <-- Jira. How to import bugs from Jira to Testlio?

All issues created to Jira via Testlio integration will be added to the label value "Testlio". Removing/adding a label in Jira will stop/initiate issue sync. 

Syncing Jira bugs to Testlio project can help Testlio's testers to avoid reporting duplicates.

Testlio <--> Jira, synchronous features, two-way sync?

  • Sync Severity from Testlio to Jira Priority.
  • Sync Testlio’s “Closing reason” to JIRA “Resolution”. We support the possibility to map these Testlio “Closing reasons” to a corresponding or similar meaning JIRA “Resolutions”.

How does the issue closed reason is mapped to Testlio?

We map the closed reasons as rules in our integrations, for example, if 'Closed' status has too many reasons that need to be mapped to Testlio along with steps of transitions, we create rules that are ordered by priority like below:

Teslio status: Closed
    closeReason: 'Duplicate'
  1: Jira Status: 'Closed', Jira Resolution:'Duplicate'

Testlio status: Closed,
    closeReason: 'Rejected'
  1: Jira Status: 'Triage'
  2: Jira Status: 'Closed', Jira Resolution:'Rejected'

How issue priority is mapped from Testlio to Jira and vice versa?

There are three severities in Testlio platform, and each of these severities can be mapped to one or more priorities in Jira based on clients' choice:

However, the first Jira Priority is the default when creating and syncing an issue from Testlio to Jira.

What is a Mindmap in Testlio, what can it be used for?

Mindmap can be created to categorize issues created with different branches in Testlio for easy sorting and task assignment or eventually mapping different group of issues to a different Jira components as required by the user.

Each feature can be mapped to one component, there can be a default component for all the features you have in one project. However, this is working only from Testlio to Jira.

How can I sync issues from Jira to Testlio that were not created by Testlio?

In our Integration, you have the full control to add issues created in Jira to Testlio bug stack so that testers in test cycles would know that these bugs are reported before and no need to re-create them. In order to do that you just need to add 'testlio' label to the issue in Jira and let the magic happen.

What is the other custom configuration for Jira integration?

Testlio integration gives you the flexibility to create and sync your own customized fields in Jira whether you want them to be static for all the issues or dynamic per issue.

So you can add any field name you want to sync in Testlio's Jira integration configuration, specify if it's a static field that wouldn't change per issue, or make it dynamic that can be set by tester per issue, with the option of a default value in case no value is entered.

Did this answer your question?