Spira Migration And Integration Guide Plan Team External Bug Tracking

User Manual:

Open the PDF directly: View PDF .
Page Count: 158 [warning: Documents this large are best viewed by clicking the View PDF Link!]

Date: February 22nd, 2017

t c/

SpiraTeam® | External Bug-Tracking Integration Guide

Inflectra Corporation

Page 1 of 158

This document contains Inflectra proprietary information

Contents

Introduction ........................................... 1

1. Setting up Data Synchronization ...... 2

2. Using SpiraTeam with JIRA 5+ ........ 9

3. Using SpiraTeam with JIRA 3 / 4 .... 29

4. Using SpiraTest with Bugzilla ......... 43

5. Using SpiraTest with MS-TFS ........ 55

6. Using SpiraTest with FogBugz ....... 79

7. Using SpiraTeam with Mantis ......... 92

8. Using SpiraTeam with ClearQuest 103

9. Using SpiraTeam with IBM RTC ... 115

10. Using Spira with Axosoft 14+ ..... 123

11. Using SpiraTeam with Redmine . 133

12. Using Spira with OnTime 11 ....... 144

Introduction

SpiraTeam® is an integrated Application

Lifecycle Management (ALM) system that

manages your project's requirements, releases,

test cases, issues and tasks in one unified

environment:

SpiraTeam® contains all of the features

provided by SpiraTest® - our highly acclaimed

quality assurance system and SpiraPlan® - our

agile-enabled project management solution.

With integrated customizable dashboards of key

project information, SpiraTeam® allows you to

take control of your entire project lifecycle and

synchronize the hitherto separate worlds of

development and testing.

However many organizations may be already

using other bug-tracking systems and not want

to have to migrate all their users over to

SpiraTeam. Therefore SpiraPlan, SpiraTest and

SpiraTeam are capable of integrating with a

variety of commercial and open-source bug-

tracking systems.

This guide outlines how to integrate and use

SpiraTest, SpiraPlan and SpiraTeam in

conjunction with other external Bug/Issue

Tracking systems.

This guide assumes that the reader is familiar

with both SpiraTeam and the appropriate tool

being discussed. For information regarding how

to use SpiraTeam, please refer to the

SpiraTeam User Manual.

Each of the sections covers a different tool so

we recommend using the table of contents on

the left to locate the tool you’re looking to either

integrate or migrate from, then read the

installation and usage instructions.

Page 2 of 158

This document contains Inflectra proprietary information

1. Setting up Data Synchronization

This section outlines the general data synchronization configuration to use any of the supported bug

trackers with SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as Spira).

► Please read this section first, before performing the configuration steps specific to your bug-tracker.

The built-in data-synchronization service that comes with Spira, allows the quality assurance team to

manage their requirements and test cases in Spira, execute their test runs, and then have the new

defects/bugs generated during the run be automatically loaded into an external bug-tracker. Once the

incidents are loaded into the external bug-tracker, the development team can then manage the lifecycle of

these defects/bugs in their chosen tool, and have the status changes be reflected back in Spira.

In addition, any issues logged directly into the external bug-tracker will get imported into Spira as either

new incidents or new requirements (depending on their type) so that they can be used as part of the

planning and testing lifecycle.

There are three possible deployment options for the Spira data synchronization:

1. You have both Spira and the External Bug Tracker cloud-hosted

2. You have Spira installed on-premise (External Bug Tracker can be either)

3. You have Spira cloud-hosted, but the External Bug Tracker installed on-premise

We shall provide the configuration steps for each option:

1.1. Spira & External Tool Cloud Hosted

When you sign up for Spira as a cloud-hosted subscription, you have the option of including the Spira

DataSync service as an add-on feature to the subscription:

Make sure you include the ‘Spira DataSync’ add-on with your subscription. Once your subscription is

provisioned, you will be able to configure the connection to Spira by going to your secure Customer Area

on our website:

Click on the ‘Configure’ button associated with the Spira-DataSync addon row:

Page 3 of 158

This document contains Inflectra proprietary information

Enter a login and password that can connect to your Spira instance. This user needs to be a member of

the project(s) that will be synchronized with the external bug-tracker and needs to have at least Incident

create/modify/view permissions and Release create/modify/view permissions in these projects.

Click on the ‘Test’ button to verify the credentials, and once they validate, make sure the ‘Active’ flag is

checked and then click ‘Save’. You have now configured the synchronization.

You should now see a list of the plugins currently configured in your Spira instance:

If you click on any of the ‘Manage’ buttons you will be taken to your Spira instance where you can

complete the plugin configuration:

The steps for configuring each plugin are specific to each external bug-tracking tool. Please refer to the

appropriate section in this document for the tool you are using.

Page 4 of 158

This document contains Inflectra proprietary information

1.2. Spira Installed On-Premise

With Spira installed on-premise, there is a built-in Windows® service that is installed with Spira that is not

running by default, but is available for data-synchronization.

The steps that need to be performed to configure integration are as follows:

 Download appropriate plug-in for Spira from our website

 Configure the DataSync Service

 Start the service and proceed to the plugin specific section of this manual

1.2.1. Download the Data-Sync Plug-In

Go to the Inflectra website and open up the page that lists the various downloads available for Spira

(http://www.inflectra.com/SpiraTeam/Downloads.aspx). Listed on this page will be the data-

synchronization plug-In for your desired bug-tracking tool. Right-click on this link and save the Zip

compressed folder to the hard-drive of the server where Spira is installed.

Open up the compressed folder and extract the DLL assembly files and place them in the C:\Program

Files (x86)\SpiraTeam\Bin folder (it may be SpiraTest or SpiraPlan depending on which product you’re

running). This folder should already contain the DataSyncService.exe and DataSyncService.exe.config

files that are the primary files used for managing the data synchronization between Spira and other

systems.

1.2.2. Configuring the Synchronization Service

To configure the integration service, please open up the DataSyncService.exe.config file located in

C:\Program Files (x86)\SpiraTeam\Bin with a text editor such as Notepad. Once open, it should look like:

<?xml version="1.0" encoding="utf-8"?>

<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup,

System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >

<section name="Inflectra.SpiraTest.DataSyncService.Properties.Settings"

type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral,

PublicKeyToken=b77a5c561934e089" requirePermission="false" />

</sectionGroup>

</configSections>

<Inflectra.SpiraTest.DataSyncService.Properties.Settings>

</setting>

<value>http://localhost/SpiraTeam</value>

</setting>

<value>fredbloggs</value>

</setting>

<value>fredbloggs</value>

</setting>

<value>SpiraTeam Data Sync Service</value>

</setting>

<value>False</value>

</setting>

</Inflectra.SpiraTest.DataSyncService.Properties.Settings>

</applicationSettings>

</configuration>

Page 5 of 158

This document contains Inflectra proprietary information

The sections that need to be verified and possibly changed are marked in yellow above. You need to

check the following information:

 The polling interval allows you to specify how frequently the data-synchronization service will ask

Spira and the external system for new data updates. The value is specified in milliseconds and

we recommend a value no smaller than 5 minutes (i.e. 300,000ms). The larger the number, the

longer it will take for data to be synchronized, but the lower the network and server overhead.

 The base URL to your instance Spira. It is typically of the form http://<server

name>/SpiraTeam. Make sure that when you enter this URL on a browser on the server itself,

the application login page appears.

 A valid login name and password to your instance of Spira. This user needs to be a member of

the project(s) that will be synchronized with the external bug-tracker and needs to have at least

Incident create/modify/view permissions and Release create/modify/view permissions in

these projects.

Once you have made these changes, please refer to the section in this document that covers the specific

bug-tracking tool you will be integrating with.

Note: If you are using the MS-TFS plugin on premise, you will also need to switch over your IIS

application pool running Spira to “Enable 32-bit Applications. You will also need to download the

recompiled 32-bit version of the DataSyncService.exe application from our support knowledge base -

KB14 - Using SpiraTeam Data Synchronization with TFS on a 64-bit system.

1.2.3. Starting the Data-Synchronization Service

When Spira is installed, a Windows Service – SpiraTeam Data Sync Service – is installed along with the

web application. However to avoid wasting system resources, this service is initially set to run manually.

To ensure continued synchronization of SpiraTeam with the external tool, we recommend starting the

service and setting its startup-type to Automatic.

To make these changes, open up the Windows Control Panel, click on the “Administrative Tools” link, and

then choose the Services option. This will bring up the Windows Service control panel:

Click on the ‘SpiraTeam Data Sync Service’ entry and click on the link to start the service. Then right-click

the service entry and choose the option to set the startup type to ‘Automatic’. This will ensure that

synchronization continues after a reboot of the server.

Page 6 of 158

This document contains Inflectra proprietary information

1.3. Spira Cloud Hosted, External Tool On-Premise

The Desktop Data Synchronization utility (hereafter referred to as the “Desktop DataSync”) is a

standalone utility than can be used to run the various Data Synchronization PlugIns without a server

installation of Spira.

This is useful where you have your SpiraTeam instance cloud hosted, but the external tool is locally

installed behind your firewall.

1.3.1. Installation

To obtain the Desktop DataSync, go to the Inflectra website and under the “Downloads and Add-Ons”

section you will find a Windows Installation (MSI) package that will install the Desktop DataSync onto your

computer. The installer will install both a 64-bit version of the Desktop Data Sync and a 32-bit version.

You should use the 64-bit version for all plugins except the Microsoft TFS plugin which will require the 32-

bit version.

Next you need to download the appropriate plug-in(s) for the various bug-trackers (as described in the

appropriate section of this document) and place the assemblies (DLL files) into the same folder that

contains the DesktopDataSync.exe application.

1.3.2. Usage

Once you have downloaded and installed the application and appropriate plug-ins, go to Start > Programs

> Inflectra > Desktop DataSync to launch the application.

This will bring up the main options window of the application:

Page 7 of 158

This document contains Inflectra proprietary information

You should then enter the URL, login and password to your Spira installation and click [Test]. Assuming

that this information is correct, you will see a confirmation message:

Now you should complete the configuation by setting the Polling Interval (how often the utility will

synchronize data between Spira and the external system) and whether Trace Logging is enabled (useful

when verifying your data mapping, but will fill up the application log, so leave unchecked for production

use). Then click the [Update] button to save your settings or [Start] to save your settings and start

synchronization immediately.

Once the Options window closes, the application will remain active in the system tray of your computer:

Page 8 of 158

This document contains Inflectra proprietary information

You can then use the right-click context menu to start synchronization, stop synchronization, view the

status (if synchronization is running) or exit the application altogether.

During synchronization, any errors will be logged to the Windows Application Event Log and you can use

those logs to diagnose any issues connecting to the external bug-tracker or any data mapping

configuration changes that need to be made.

Page 9 of 158

This document contains Inflectra proprietary information

2. Using SpiraTeam with JIRA 5+

This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam)

in conjunction with the JIRA issue/bug tracking system version 5.0 and later. The built-in integration

service allows the quality assurance team to manage their requirements and test cases in SpiraTeam,

execute test runs in SpiraTest, and then have the new incidents generated during the run be

automatically loaded into JIRA. Once the incidents are loaded into JIRA as issues, the development team

can then manage the lifecycle of these issues in JIRA, and have the status changes in JIRA be reflected

back in SpiraTeam.

In addition, any issues logged directly into JIRA will get imported into SpiraTeam as either new incidents

or new requirements (depending on their type) so that they can be used as part of the planning and

testing lifecycle.

► STOP! Please make sure you have first read the Instructions in Section 1 before proceeding!

2.1. Configuring the Plug-In

This section outlines how to configure the integration service to export incidents into JIRA, import new

issues from JIRA and pick up subsequent status changes in JIRA and have them update SpiraTeam. It

assumes that you already have a working installation of SpiraTest, SpiraPlan or SpiraTeam and a

working installation of JIRA.

The following versions of SpiraTeam and JIRA are supported:

 The JIRA 5.x plugin supports JIRA 5.0 or later and SpiraTeam v4.0 or later

 The JIRA 4.x plugin supports JIRA 4.0 or later and SpiraTeam v3.0 or later (see section 3)

 The JIRA 3.x plugin supports JIRA 3.0 or later and SpiraTeam v2.3 or later (see section 3)

If you have an earlier version of SpiraTeam, you will need to upgrade to at least v2.3 before trying to

integrate with JIRA.

The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the

JIRA server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid

account that has System-Administration level privileges and click on the System > Data Synchronization

administration option from the left-hand navigation:

This screen lists all the plug-ins already configured in the system. Depending on whether you chose the

option to include sample data in your installation or not, you will see either an empty screen or a list of

sample data-synchronization plug-ins.

If you already see an entry for JiraDataSync you should click on its “Edit” link. If you don’t see such an

entry in the list, please click on the [Add] button instead. In either case you will be taken to the following

screen where you can enter or modify the JIRA Data-Synchronization plug-in:

Page 10 of 158

This document contains Inflectra proprietary information

You need to fill out the following fields for the JIRA Plug-in to operate correctly:

 Name – this needs to be set to JiraDataSync.

 Caption – this is the display name of the plugin. Normally you can use something generic such

as “Jira”, however if you have multiple JIRA instances you might want to name it something

specific such as “Jira External”. If you don’t enter a value, the display name will be “JiraDataSync”

 Description – this should be set to a description of the plug-in. This is an optional field that is

used for documentation purposes and is not actually used by the system.

 Connection Info – this should the full URL to the JIRA installation being connected to (including

any custom port numbers). Entering this URL into a web browser should bring up the JIRA login

page.

 For JIRA cloud customers, it is typically of the form:

https://mycompany.atlassian.net

 For JIRA server customers, it is typically of the form:

http://myserver:8080

 Login – this should be set to a valid login to the JIRA installation. The login needs to have

permissions to create and view issues and versions within JIRA.

 Password – this should be set to the password of the login specified above.

 Time Offset – normally this should be set to zero, but if you find that issues being changed in

JIRA are not being updated in SpiraTeam, try increasing the value as this will tell the data-

synchronization plug-in to add on the time offset (in hours) when comparing date-time stamps.

Page 11 of 158

This document contains Inflectra proprietary information

Also if your JIRA installation is running on a server set to a different time-zone, then you should

add in the number of hours difference between the servers’ time-zones here.

 Auto-Map Users – This changes the way that the plugin maps users in SpiraTeam to those in

JIRA:

 Auto-Map = True

With this setting, all users in SpiraTeam need to have the same username as those in

JIRA. If this is the case then you do not need to perform the user-mapping task outlined

in section 2.2.2. This is a big time-saver if you can guarantee that all usernames are the

same in both systems.

 Auto-Map = False

With this setting, users in SpiraTeam and JIRA are free to have different usernames

because you specify the corresponding JIRA name for each user as outlined in section

2.2.2.

 Custom 01 – This is used to specify a JIRA custom property that should be mapped to the built-

in SpiraTeam Incident Severity field (which does not exist in JIRA). This can be left empty for now

and will be discussed below in section 2.2.

 Custom 02 – This should be set to the word “True” if you want to have the new issues submitted

to JIRA be submitted using a specified SecurityLevel. If you’re not using the security level feature

of JIRA, leave the field blank.

 Custom 03 – This should be set to the word “True” if you want to have the plugin restrict

synchronization to only loading new incidents from SpiraTeam > JIRA and updating existing

items. This is useful if you want to prevent existing issues in JIRA from being loaded into

SpiraTeam. Leave blank if you want the plugin to synchronize normally.

 Custom 04 – This should be set to a comma-separated list of IDs of any JIRA issue types that

you want to be synchronized with SpiraTeam requirements instead of incidents. If you leave this

blank, all JIRA issue types will be synchronized with incidents.

 Custom 05 – This should be set to the name of the JIRA issue link type that you want SpiraTeam

incident associations to use. If you leave this blank, incident associations in SpiraTeam will not be

imported into JIRA. You can get the list of issue link types from the following screen in JIRA:

Note: For most users, we recommend leaving Custom 01 – Custom 04 blank.

2.2. Configuring the Data Mapping

Next, you need to configure the data mapping between SpiraTeam and JIRA. This allows the various

projects, users, releases, incident types, statuses, priorities and custom property values used in the two

applications to be related to each other. This is important, as without a correct mapping, there is no way

for the integration service to know that an “Enhancement” in SpiraTeam is the same as a “New Feature”

in JIRA (for example).

Page 12 of 158

This document contains Inflectra proprietary information

The following mapping information needs to be setup in SpiraTeam:

 The mapping of the project identifiers for the projects that need to be synchronized

 The mapping of users in the system

 The mapping of releases (equivalent to JIRA versions) in the system

 The mapping of the various standard fields in the system

 The mapping of the various custom properties in the system

Each of these is explained in turn below:

2.2.1. Configuring the Project Mapping

From the data synchronization administration page, you need to click on the “View Project Mappings”

hyperlink next to the JIRA plug-in name. This will take you to the data-mapping home page for the

currently selected project:

If the project name does not match the name of the project you want to configure the data-mapping for,

click on the “(Change Project)” hyperlink to change the current project.

To enable this project for data-synchronization with JIRA, you need to enter:

 External Key – This should be set to the name of the project Key in JIRA. Typically this is a short

acronym for the project:

Active Flag – Set this to ‘Yes’ so that SpiraTeam knows that you want to synchronize data for

this project. Once the project has been completed, setting the value to “No” will stop data

synchronization, reducing network utilization.

Click [Update] to confirm these settings. Once you have enabled the project for data-synchronization, you

can now enter the other data mapping values outlined below.

Note: Once you have successfully configured the project, when creating a new project, you

should choose the option to “Create Project from Existing Project” rather than “Use Default

Template” so that all the project mappings get copied across to the new project.

Page 13 of 158

This document contains Inflectra proprietary information

2.2.2. Configuring the User Mapping

To configure the mapping of users in the two systems, you need to go to Administration > Users > View

Edit Users, which will bring up the list of users in the system. Then click on the “Edit” button for a

particular user that will be editing issues in JIRA:

Click on the ‘Data Mapping’ tab to list all the configured data-synchronization plug-ins for this user. In the

text box next to the JIRA Data-Sync plug-in you need to enter the login for this username in JIRA. This

will allow the data-synchronization plug-in to know which user in SpiraTeam match which equivalent user

in JIRA. Click [Save] once you’ve entered the appropriate login name. You should now repeat for the

other users who will be active in both systems.

If you have set the “Auto-Map Users” option in the JIRA plugin, you can skip this section completely.

2.2.3. Configuring the Release Mapping

When the data-synchronization service runs, when it comes across a release/iteration in SpiraTeam that it

has not seen before, it will create a corresponding “Version” in JIRA. Similarly, if it comes across a new

Version in JIRA that it has not seen before, it will create a new Release in SpiraTeam. Therefore, when

using both systems together, it is recommended that you only enter new Releases/Versions in one

system and let the data-synchronization service add them to the other system.

However, you may start out with the situation where you already have pre-existing Releases/Version in

both systems that you need to associate in the data-mapping. If you don’t do this, you may find that

duplicates get created when you first enable the data-synchronization service. Therefore, for any

Releases/Iterations that already exist in BOTH systems please navigate to Planning > Releases and click

on the Release/Iteration in question. Make sure you have the ‘Overview’ tab visible and expand the

“Details” section of the release/iteration:

Page 14 of 158

This document contains Inflectra proprietary information

In addition to the standard fields and custom properties, you will see an additional text property called

“Jira ID” that is used to store the mapped external identifier for the equivalent Version in JIRA. You need

to locate the ID of the equivalent version in JIRA, enter it into this text-box and click [Save]. You should

now repeat for all the other pre-existing releases.

The JIRA ID can be found by looking at the URL inside JIRA when choosing to Edit the version’s “Build

and Release”. The URL will include the numeric ID of the version inside JIRA in the URL (in the example

below, the ID would be 10001.

2.2.4. Configuring the Standard Field Mapping

Now that the projects, user and releases have been mapped correctly, we need to configure the standard

incident and requirement fields. To do this, go to Administration > System > Data Synchronization and

click on the “View Project Mappings” for the JiraDataSync plug-in entry:

Page 15 of 158

This document contains Inflectra proprietary information

From this screen, you need to click on Priority, Severity, Component, Status and Type in turn to configure

the incident field mappings. If you’re using the option to have JIRA also synchronize some issue types as

requirements, then you’ll need to also configure the Requirement Importance, Type, Component and

Status fields.

a) Incident Type

Click on the “Type” hyperlink under Incident Standard Fields to bring up the Incident type mapping

configuration screen:

The table lists each of the incident types available in SpiraTeam and provides you with the ability to enter

the matching JIRA issue type ID for each one. You can map multiple SpiraTeam fields to the same JIRA

fields (e.g. Bug and Incident in SpiraTeam are both equivalent to Bug in JIRA), in which case only one of

Page 16 of 158

This document contains Inflectra proprietary information

the two values can be listed as Primary = Yes as that’s the value that’s used on the reverse

synchronization (from JIRA > SpiraTeam).

The JIRA ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Issue Type.

The URL will include the section: id=X where X is the numeric ID of the Issue Type inside JIRA.

b) Incident Status

Click on the “Status” hyperlink under Incident Standard Fields to bring up the Incident status mapping

configuration screen:

The table lists each of the incident statuses available in SpiraTeam and provides you with the ability to

enter the matching JIRA issue status ID for each one. You can map multiple SpiraTeam fields to the

same JIRA fields (e.g. New and Open in SpiraTeam are both equivalent to Open in JIRA), in which case

only one of the two values can be listed as Primary = Yes as that’s the value that’s used on the reverse

synchronization (from JIRA > SpiraTeam).

We recommend that you always point the New and Open statuses inside SpiraTeam to point to the ID for

“Open” inside JIRA and make Open in SpiraTeam the Primary status of the two. This is recommended so

that as new incidents in SpiraTeam get synched over to JIRA, they will get switched to the Open status in

Page 17 of 158

This document contains Inflectra proprietary information

JIRA which will then be synched back to “Open” in SpiraTeam. That way you’ll be able to see at a glance

which incidents have been synched with JIRA and those that haven’t.

The JIRA ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Issue

Status. The URL will include the section: id=X where X is the numeric ID of the Issue Status inside JIRA.

c) Incident Priority

Click on the “Priority” hyperlink under Incident Standard Fields to bring up the Incident Priority mapping

configuration screen:

The table lists each of the incident priorities available in SpiraTeam and provides you with the ability to

enter the matching JIRA priority ID for each one. You can map multiple SpiraTeam fields to the same

JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that’s the value

that’s used on the reverse synchronization (from JIRA > SpiraTeam).

The JIRA ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Priority. The

URL will include the section: id=X where X is the numeric ID of the Priority inside JIRA:

Page 18 of 158

This document contains Inflectra proprietary information

d) Incident Component (Optional)

Click on the “Component” hyperlink under Incident Standard Fields to bring up the Incident component

mapping configuration screen:

The table lists each of the components available in SpiraTeam and provides you with the ability to enter

the matching JIRA component ID for each one. You can map multiple SpiraTeam fields to the same JIRA

fields, in which case only one of the two values can be listed as Primary = Yes as that’s the value that’s

used on the reverse synchronization (from JIRA > SpiraTeam).

The JIRA ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Component.

The URL will include the section: id=X where X is the numeric ID of the Component inside JIRA:

e) Incident Severity (Optional)

Click on the “Severity” hyperlink under Incident Standard Fields to bring up the Incident severity mapping

configuration screen:

Unlike the other incident standard fields, JIRA doesn’t actually have a built-in field for storing the severity

of an issue, so if you want to be able to see the SpiraTeam incident severity in JIRA, you’ll need to create

Page 19 of 158

This document contains Inflectra proprietary information

a JIRA custom list field to store the different severity values. If you don’t want to synchronize severity

values with JIRA, you can skip the rest of this section.

Once you have created a custom field in JIRA to contain the list of severity values, you need to now

populate the above table with the name (Not the ID) of the severity custom property values inside JIRA

and click Update. Secondly you need to go to the Plug-in configuration screen:

On this screen you need to enter the ID of the custom field that you’re using to store severities in JIRA

and populate the Custom 01 property with this value (see above). The ID can be found by looking at

the URL inside JIRA when choosing to View/Edit the Custom Field. The URL will include the section:

id=X where X is the numeric ID of the Custom Field inside JIRA:

e) Requirement Status (Optional)

Click on the “Status” hyperlink under Requirement Standard Fields to bring up the Requirement status

mapping configuration screen:

The table lists each of the requirement statuses available in SpiraTeam and provides you with the ability

to enter the matching JIRA issue status ID for each one. You can map multiple SpiraTeam fields to the

same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that’s the

value that’s used on the reverse synchronization (from JIRA > SpiraTeam).

The JIRA ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Issue

Status. The URL will include the section: id=X where X is the numeric ID of the Issue Status inside JIRA.

Page 20 of 158

This document contains Inflectra proprietary information

f) Requirement Importance (Optional)

Click on the “Importance” hyperlink under Requirement Standard Fields to bring up the Requirement

Importance mapping configuration screen:

The table lists each of the requirement importances available in SpiraTeam and provides you with the

ability to enter the matching JIRA priority ID for each one. You can map multiple SpiraTeam fields to the

same JIRA fields, in which case only one of the two values can be listed as Primary = Yes as that’s the

value that’s used on the reverse synchronization (from JIRA > SpiraTeam).

The JIRA ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Priority. The

URL will include the section: id=X where X is the numeric ID of the Priority inside JIRA:

g) Requirement Type (Optional)

Click on the “Type” hyperlink under Requirement Standard Fields to bring up the Requirement type

mapping configuration screen:

Page 21 of 158

This document contains Inflectra proprietary information

The table lists each of the requirement types available in SpiraTeam and provides you with the ability to

enter the matching JIRA issue type ID for each one. You can map multiple SpiraTeam fields to the same

JIRA fields (e.g. Use Case and User Story in SpiraTeam are both equivalent to User Story in JIRA), in

which case only one of the two values can be listed as Primary = Yes as that’s the value that’s used on

the reverse synchronization (from JIRA > SpiraTeam).

The JIRA ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Issue Type.

The URL will include the section: id=X where X is the numeric ID of the Issue Type inside JIRA.

h) Requirement Component (Optional)

Click on the “Component” hyperlink under Requirement Standard Fields to bring up the Requirement

component mapping configuration screen:

Page 22 of 158

This document contains Inflectra proprietary information

The table lists each of the components available in SpiraTeam and provides you with the ability to enter

the matching JIRA component ID for each one. You can map multiple SpiraTeam fields to the same JIRA

fields, in which case only one of the two values can be listed as Primary = Yes as that’s the value that’s

used on the reverse synchronization (from JIRA > SpiraTeam).

The JIRA ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Component.

The URL will include the section: id=X where X is the numeric ID of the Component inside JIRA:

2.2.5. Configuring the Custom Property Mapping

Now that the various SpiraTeam standard fields have been mapped correctly, we need to configure the

custom property mappings. This is used for both custom properties in SpiraTeam that map to custom

fields in JIRA and also for custom properties in SpiraTeam that are used to map to standard fields in JIRA

(Environment, Resolution and SecurityLevel) that don’t exist in SpiraTeam.

From the View/Edit Project Data Mapping screen, you need to click on the name of the Incident or

Requirement Custom Property that you want to add data-mapping information for. We will consider the

four different types of mapping that you might want to enter:

Page 23 of 158

This document contains Inflectra proprietary information

a) Scalar Custom Properties

This refers to custom properties that have a simple user-entered value and don’t need to have their

specific options mapped between SpiraTeam and JIRA. All of the custom property types except List and

Multi-List fall into this category (e.g. Text, Date, User, Boolean, Decimal, Integer, etc.)

Click on the hyperlink of the scalar custom property under Incident/Requirement Custom Properties to

bring up the custom property mapping configuration screen. For scalar custom properties, there will be no

values listed in the lower half of the screen.

You need to lookup the ID of the custom field in JIRA that matches this custom property in SpiraTeam.

Once you have entered the id of the custom field, click [Update].

The ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Custom Field.

The URL will include the section: id=X where X is the numeric ID of the Custom Field inside JIRA:

Page 24 of 158

This document contains Inflectra proprietary information

b) List Custom Properties

This refers to custom properties that are either of type List or Multi-List. Click on the hyperlink of the list

custom property under Incident/Requirement Custom Properties to bring up the custom property mapping

configuration screen. For list custom properties there will be a textbox for both the custom field itself and

a mapping table for each of the custom property values that need to be mapped:

First you need to lookup the ID of the custom field in JIRA that matches this custom property in

SpiraTeam. This should be entered in the ‘External Key’ field below the name of the custom property. The

ID can be found by looking at the URL inside JIRA when choosing to View/Edit the Custom Field. The

URL will include the section: id=X where X is the numeric ID of the Custom Field inside JIRA.

Page 25 of 158

This document contains Inflectra proprietary information

Next for each of the Property Values in the table (in the lower half of the page) you need to enter the full

name (not the id this time) of the custom field value as specified in JIRA:

c) JIRA’s Resolution Field

If you would like the values of the JIRA ‘Resolution’ field to be synchronized back to SpiraTeam, then

you will need to fill out this section. You first need to create an incident custom property in SpiraTeam of

type ‘LIST’ that contains the various resolution names that exist inside JIRA.

Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up

the custom property mapping configuration screen:

Page 26 of 158

This document contains Inflectra proprietary information

First you need to enter the word “Resolution” as the External Key of the custom property. This tells the

data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Resolution field in

JIRA.

Next for each of the Property Values in the table (in the lower half of the page) you need to enter the JIRA

ID of the various Resolutions that are configured in JIRA. The external ID can be found by looking at the

URL inside JIRA which choosing to View/Edit the resolution name/description.

d) JIRA’s Environment Field

If your instance of JIRA requires that all new issues are submitted with an ‘Environment’ description

specified, then you will need to fill out this section. You first need to create an incident custom property in

SpiraTeam of type ‘TEXT’ that will be used to store the environment description within SpiraTeam.

Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up

the custom property mapping configuration screen:

All you need to do on this screen is enter the word “Environment” in the External Key textbox and the

data-sync plug-in will know that this custom property is mapped to the built-in Environment field in JIRA.

e) JIRA’s Security Level Field

Page 27 of 158

This document contains Inflectra proprietary information

If your instance of JIRA requires that all new issues are submitted with a ‘Security Level’ then you will

need to fill out this section. You first need to create an incident custom property in SpiraTeam of type

‘LIST’ that contains the various security levels that exist inside JIRA.

Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up

the custom property mapping configuration screen.

First you need to enter the word “SecurityLevel” as the External Key of the custom property. This tells

the data-sync plug-in that the custom property in SpiraTeam should be mapped to built-in Security Level

field in JIRA.

Next for each of the Property Values in the table (in the lower half of the page) you need to enter the JIRA

ID of the various Security Levels that are configured in JIRA. The external ID can be found by looking at

the URL inside JIRA which choosing to View/Edit the security level name/description.

f) JIRA’s Issue Key Field

It can be convenient to create a SpiraTeam custom property to store the JIRA Issue Key (the ID used to

identify an issue in JIRA). This allows you to display a list of incients in SpiraTest and see the

corresponding JIRA ID in the same list. You first need to create an incident custom property in SpiraTeam

of type ‘TEXT’ that will be used to store the JIRA issue key within SpiraTeam.

Then click on the hyperlink of this new list custom property under Incident Custom Properties to bring up

the custom property mapping configuration screen:

All you need to do on this screen is enter the word “JiraIssueKey” in the External Key textbox and the

data-sync plug-in will know that this custom property is mapped to the built-in Issue Key field in JIRA.

Once you have updated the various mapping sections, you are now ready to use the integration.

2.3. Using SpiraTeam with JIRA

Now that the integration service has been configured and the service started, initially any incidents

created in SpiraTeam for the specified projects will be imported into JIRA and any existing issues in JIRA

will get loaded into SpiraTeam as either incidents or requirements (depending on your configuration).

At this point we recommend opening the Windows Event Viewer and choosing the Application Log. In this

log any error messages raised by the SpiraTeam Data Sync Service will be displayed. If you see any

error messages at this point, we recommend immediately stopping the SpiraTeam service and checking

the various mapping entries. If you cannot see any issues with the mapping information, we recommend

sending a copy of the event log message(s) to Inflectra customer services (support@inflectra.com) who

will help you troubleshoot the problem.

Page 28 of 158

This document contains Inflectra proprietary information

To use SpiraTeam with JIRA on an ongoing basis, we recommend the following general processes be

followed:

 When running tests in SpiraTest or SpiraTeam, defects found should be logged through the Test

Execution Wizard as normal.

 Developers can log new defects into either SpiraTeam or JIRA. In either case they will get loaded

into the other system.

 Once created in one of the systems and successfully replicated to the other system, the incident

should not be modified again inside SpiraTeam

 At this point, the incident should not be acted upon inside SpiraTeam and all data changes to the

issue should be made inside JIRA. To enforce this, you should modify the workflows set up in

SpiraTeam so that the various fields are marked as inactive for all the incident statuses other than

the “New” status. This will allow someone to submit an incident in SpiraTeam, but will prevent

them making changes in conflict with JIRA after that point.

 As the issue progresses through the customized JIRA workflow, changes to the type of issue,

changes to its status, priority, description and resolution will be updated automatically in

SpiraTeam. In essence, SpiraTeam acts as a read-only viewer of these incidents.

 You are now able to perform test coverage and incident reporting inside SpiraTest/SpiraTeam

using the test cases managed by SpiraTest/SpiraTeam and the incidents managed on behalf of

SpiraTest/SpiraTeam inside JIRA.

Page 29 of 158

This document contains Inflectra proprietary information

3. Using SpiraTeam with JIRA 3 / 4

This section outlines how to use SpiraTest, SpiraPlan or SpiraTeam (hereafter referred to as SpiraTeam)

in conjunction with the JIRA issue/bug tracking system versions 3.0 – 4.0. The built-in integration service

allows the quality assurance team to manage their requirements and test cases in SpiraTeam, execute

test runs in SpiraTest, and then have the new incidents generated during the run be automatically loaded

into JIRA. Once the incidents are loaded into JIRA as issues, the development team can then manage

the lifecycle of these issues in JIRA, and have the status changes in JIRA be reflected back in

SpiraTeam.

In addition, if you are using JIRA 4.x or higher, any issues logged directly into JIRA will get imported into

SpiraTeam so that they can be linked to test cases and requirements.

► STOP! Please make sure you have first read the Instructions in Section 1 before proceeding!

3.1. Configuring the Plug-In

The next step is to configure the plug-in within SpiraTeam so that the system knows how to access the

JIRA server. To start the configuration, please open up SpiraTeam in a web browser, log in using a valid

account that has System-Administration level privileges and click on the System > Data Synchronization

administration option from the left-hand navigation:

This screen lists all the plug-ins already configured in the system. Depending on whether you chose the

option to include sample data in your installation or not, you will see either an empty screen or a list of

sample data-synchronization plug-ins.

If you already see an entry for JiraDataSync you should click on its “Edit” link. If you don’t see such an

entry in the list, please click on the [Add] button instead. In either case you will be taken to the following

screen where you can enter or modify the JIRA Data-Synchronization plug-in:

Page 30 of 158

This document contains Inflectra proprietary information

You need to fill out the following fields for the JIRA Plug-in to operate correctly:

 Name – this needs to be set to JiraDataSync. This needs to match the name of the plug-in DLL

assembly that was copied into the C:\Program Files\SpiraTeam\Bin folder (minus the .dll file

extension). If you renamed the JiraDataSync.dll file for any reason, then you need to change the

name here to match.

 Description – this should be set to a description of the plug-in. This is an optional field that is

used for documentation purposes and is not actually used by the system.

 Connection Info – this should the full URL to the JIRA installation’s web-service API. This is

typically http://<jira server name>/rpc/soap/jirasoapservice-v2.