Jira is an issue and project tracing software from Atlassian. The following article describes integrating Ranorex Test Cases into Jira. That way you will empower Ranorex to submit or modify testing issues within Jira in an automated way.

As Jira offers a REST web service (API description available here), it becomes possible to submit issues automatically. This is achieved using the JiraRestClient  and RestSharp.

These libraries are wrapped with Ranorex functionality, forming re-usable modules, available within this library (use this library for Ranorex 5x). The integration of these Jira testing modules into Ranorex Test Automation is described subsequently.

The provided library is not an official part of Ranorex and is therefore not covered by the Ranorex support services!

The following steps need to be done:

Step 1 – Adding the Libraries to Ranorex for Jira Automation:

Predefined modules for Ranorex 6.x (for x86 architecture and .NET 4.0) are available here and modules for Ranorex 5.x (for x86 architecture and .NET 3.5) are available here. The assemblies in this zip-file just need to get added to the Ranorex project. In succession the modules (as shown below) will appear in the module browser under “JiraReporter” (demonstrated on the Ranorex KeePass sample):

AddReference

Step 2 – Using the Modules in the Ranorex Test Suite

Individual modules are available within the “JiraReporter” project. These modules merely need to get used within the Ranorex Test Suite, as shown below:

Modules_TestSuite

The modules are interacting with Jira, based on the results of the related test cases. Except the initialization module, it is recommended placing the modules in the test case’s teardown.

Available modules for Jira automation:

  • InitializeJiraReporter — This module establishes the connection to the Jira server. It is mandatory for the following modules to be functional.
  • AutoCreateNewIssueIfTestCaseFails — If the test case fails, an issue is automatically created on the server, which is defined in “InitializeJiraReporter”. An issue number is automatically created by the server.
    A compressed Ranorex report is uploaded automatically as well.
  • ReOpenExistingIssueIfTestCaseFails — If the test case fails, an existing and already closed issue gets re-opened.
  • ResolveIssueIfTestCaseSuccessful — If the test case is successful, an existing and already open issue is set to “resolved”.
  • UpdateExistingIssueIfTestCaseFails — If a test case fails, attributes of an existing issue are updated.

 

Step 3 – Configure Parameters for the Modules

The modules expose different variables for configuration. Each module accepts different parameters, but they’re all used in the same way among the modules. Which module accepts which parameters can be seen when using the modules in the Ranorex project.

  • JiraUserName: The username to connect to the Jira server.
  • JiraPassword: The password for the specified user.
  • JiraServerURL: The URL for the Jira server.
  • JiraProjectKey: The project key as specified in Jira (e.g. MYP).
  • JiraIssueType: An issue type, as available in Jira (e.g., Bug)
  • JiraSummary: Some free summary text for the issue.
  • JiraDescription: Some free description text for the issue.
  • JiraLabels: Labels for the issue separated by “;” (e.g., Mobile; USB; Connection)
  • JiraIssueKey: The key for the respective issue (e.g., MYP-25).

 

The configuration of the modules is then done with common Ranorex data binding:

DataBinding

… and you’re done:

In succession, Ranorex will automatically interact with Jira when one of the modules is executed. The issues can then get processed in Jira. The following figure shows an automatically created issue together with its attached report:

JiraPic

 

Advanced usage:

The JiraReporter project offers two more modules; (i) the module “OnDemandCreateNewIssueIfTestCaseFails” and (ii) the module groupProcessExistingIssue”. These modules offer further convenience functionality and are explained in more detail in succession.

Module Group – ProcessExistingIssue

This module group groups the following modules in the given order:

  • ReOpenExistingIssueIfTestCaseFails
  • UpdateExistingIssueIfTestCaseFails
  • ResolveIssueIfTestCaseSuccessful

It might be useful to process an existing issue, as it reopens and updates the issue automatically in case of a failure. Otherwise, if the test case is successful, it closes the issue.
Thus, it can be used to monitor an already known and fixed issue. To use this module group, the whole Ranorex  “JiraReporter”project, available on GitHub needs to get added to the solution.

OnDemandCreateNewIssueIfTestCaseFails

This module provides functionality, creating a new issue out of the Ranorex Report. A new issue only gets created when the link, provided within the report is clicked. So the user or tester can decide whether an issue is create or not.

The compressed Ranorex report is uploaded to the newly created issue as well.

rxReport

Note: This functionality relies on a batch file created by Ranorex in the output folder and the execution of the Jira Command Line interface (CLI). It does not depend on a prior initialization from “InitializeJiraReporter”.

The module exposes the same variables as the modules mentioned above. One additional parameter is essential for this module:

  • JiraCLIFileLocation: The full path to the “jira-cli-<version>.jar” file, provided by the Jira CLI.

Following requirements need to be met to use this module:

  • Remote API must be enabled in your JIRA installation
  • The mentioned batch file needs to be accessible over the same file path, where the file was initially created. If the file is moved to a new location, the link is not working anymore.
    In this case the batch-file needs to be started manually.

 

JiraReporter Source Code:

The whole project which contains the code for the JiraReporter is available on GitHub under the following link:

https://github.com/ranorex/Ranorex-Jira-Integration

Please feel free to modify the code according to individual needs and/or upload new modules.

 

Troubleshooting:

  • Assembly can’t get loaded
    If an error similar to the following one happens, loading from “RemoteSources needs to get enabled
    Error messsage: Could not load file or assembly ‘file:///C:RanorexJiraOldTestJiraOldTestbinDebugJiraReporter.dll’ or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
    An attempt was made to load an assembly from a network location which would have caused …

    • Add the following lines to the app.conf of the Ranorex project:
      <runtime>
        <loadFromRemoteSources enabled="true" />
      </runtime>

      Jira_AssemblyNotLoaded

    • “Unblock” all the .dlls files
      (property of each of them and click “unblock”) — an example how this is done is available here.
  •  Exception — “JIRA returned wrong status
    If you’re encountering an error like
    ‘{“errorMessages”:[], “errors”:{“summary”:”Field ‘summary’ cannot be set. It is not on the appropriate screen, or unknown.”, …}}‘,
    it is very likely that your Jira installation is customized in some way. This message tells, that the library wants to set a field, which is not available when performing the desired action. Please check your Jira installation and the respective action for all necessary and available fields. To overcome this issue, the underlying library needs to get extended and compiled by yourself. A potential starting point for modifications would be the JiraReporter class.