Skip to content

Syndicate content
Updated: 2 hours 53 min ago

Integrating Ranorex Test Cases into Jira

Tue, 06/27/2017 - 10:20

Jira is an issue and project tracking software from Atlassian. The following article describes how you can integrate 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. Please note that the libraries provided are not part of Ranorex and, therefore, not covered by Ranorex support services. These libraries are wrapped with Ranorex functionality, forming re-usable modules. Starting with Ranorex 7.0, these libraries are, however, already included in the Ranorex Jira NuGet package. The integration of these Jira testing modules into Ranorex test automation is described in the following article.

The following steps need to be performed:

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

A NuGet package with predefined Ranorex modules is available from the “Manage Packages” dialog for Ranorex 7.x and higher. To add the NuGet package to your Ranorex project

  • right-click on “References” in the Ranorex project view,
  • select “Manage Packages…”,
  • search for “Ranorex” and add the “Ranorex Jira Reporter ” package

Add NuGet Package

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 be added to the Ranorex project. In succession the modules (as shown below) will appear in the module browser under “JiraReporter” (demonstrated in the Ranorex KeePass sample):


Step 2 – Using the Modules in the Ranorex Test Suite

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


The modules are interacting with Jira, based on the results of the related test cases. Except for the initialization module, which should be part of the Ranorex set up region, it is recommended to place 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 automatically uploaded 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.
  • AutoHandleJiraIntegration — This module combines the modules AutoCreateNewIssueIfTestCaseFail, ReOpenExistingIssueIfTestCaseFails and ResolveIssueIfTestCaseSuccessful.


Step 3 – Configure Parameters for the Modules

The modules has different configurable variables. Each module accepts different parameters, but they’re all used in the same way in 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).
  • StateClosed: The state which will be set when an issue will be closed (e.g., Done).
  • StateReopened: The state which will be set when an issue will be reopened (e.g., In Progress).
  • RxAutomationFieldName: The name of the custom field, the test case name will be stored. This field will be taken to identify one or more issues.
  • jqlQueryToConnectIssue: Alternatively to the parameter RxAutomationFieldName, a jql query can be taken to identify one or more issues.

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


… and you’re done:

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



Advanced usage: OnDemandCreateNewIssueIfTestCaseFails

This module enables you to create a new Jira issue directly out of the Ranorex report. A new issue will only be created when the link, that is provided within the report, is clicked. So the user or tester can decide whether an issue is create or not.

The compressed Ranorex report will also be automatically uploaded to the newly created issue..


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. An additional parameter is essential for this module:

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

Please note that the 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:

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


  • Assembly can’t get loaded
    If an error similar to the following one happens, you have to enable loading from “RemoteSources”.
    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:
        <loadFromRemoteSources enabled="true" />


    • “Unblock” all .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 says that the library wants to set a field, which is not available when performing the desired action. Please check your Jira installation as well as the respective action for all necessary and available fields. To overcome this issue, you have to extend and compile the underlying library. A potential starting point for modifications would be the JiraReporter class.

Please note that this blog was originally published November 26, 2014, but has been revised to reflect recent technical developments.

Download free trial

The post Integrating Ranorex Test Cases into Jira appeared first on Ranorex Blog.

Categories: Companies

Integrate Automated Testing into Jenkins

Tue, 06/06/2017 - 10:00

In software engineering, continuous integration means the continuous application of quality control processes — small units of effort, applied frequently.

In this blog we’ll show you how to set up a CI job with Hudson/Jenkins that automatically builds and executes your Ranorex automation as well as automatically sends out the generated test reports for every committed change in a Subversion repository.

Advantages of Continuous Integration Testing

Continuous integration has many advantages:

  • When tests fail or bugs emerge, developers can revert the codebase to a bug-free state without wasting time for debugging
  • Developers detect and fix integration problems continuously – and thus avoid last-minute chaos at release dates
  • Early warning of broken/incompatible code
  • Early warning of conflicting changes
  • Immediate testing of all changes
  • Constant availability of a “current” build for testing, demo, or release purposes
  • Immediate feedback to developers on the quality, functionality, or system-wide impact of their written code
  • Frequent code check-ins push developers to create modular, less complex code
Infrastructure Continuous Integration Tool

You can find a download link and installation description for Hudson and Jenkins here:

In this blog post we are going to use Jenkins as CI tool. There shouldn’t be much of a difference when using Hudson.

As Jenkins or the nodes executing the CI jobs normally are started as Windows services, they do not have sufficient rights to start UI-applications.

Please make sure that Jenkins as master and its slave nodes, where the Ranorex automation should be triggered, are not started as a service.

For the Jenkins master, open the “Services” tool (which is part of the “Administrative Tools” in the control panel), choose “Jenkins” service, stop the service, and set the “Startup type” to disabled:

disable start as service

Use the following command to start Jenkins manually from the installation folder:

java -jar jenkins.war

manually start jenkins

After starting Jenkins, use this address to access the web interface:


To configure your Jenkins server, navigate to the Jenkins menu and select “Manage Jenkins” -> “Configure System”:

Configure System

Note: It is necessary to have the Ranorex main components – and a valid Ranorex license – installed on each machine you want to build and execute Ranorex code.

Source Code Management

As mentioned before, we are going to use a Subversion repository as base of our continuous integration process.

In this sample, we have two solutions in our repository: the application under test and as the automated Ranorex tests.


To start the application under test from your test project, simply add a new “Run Application” action to your action table in Ranorex Studio, which starts the application under test, using a relative path to the repository root:

Run Application Action


As we want to build our code for each committed change within our SVN repository, we need a Subversion as well as a MS Build plugin for Jenkins. An additional mail plugin will make sure that a mail is sent with each build.

Install Plugins

Open the “Manage Plugins” section (“Manage Jenkins” -> “Manage Plugins”), choose the following plugins from the list of available plugins and install them if they are not installed already:

Configure Plugins

The installed plugins also need to be configured. To do so

  • open the “Configure System” and configure the “Extended E-Mail Notification” plugin. To do so, set the recipients and alter the subject and content (adding the environment variable $BUILD_LOG to the content will add the whole console output of the build and the test to the sent mail),
    Configure Mails
  • configure the “E-mail Notification” plugin by setting the SMTP server.
  • and navigate to “Global Tool Configuraiton” and configure your “MSBuild” plugin by choosing the “msbuild.exe” installed on your machine.
    Configure MSBuild
Add New Job

Now, as the system is configured, we can add a new Jenkins job, which will update the checked out files from a SVN repository, build both the application under test and the Ranorex automation project, execute the application under test as well as the automation code and send a mail with the report file attached.

Start by creating a new item. Choose “Build free-style software project” as job type and enter a job name:

Add New Item

Configure Source Code Management

Next, we have to check out the source of both the application under test and our test automation project. Start with choosing Subversion as source code management tool. Then, enter the repository holding your application under test as well as your test automation project. Finally, choose “Use ‘svn update’ as much as possible” as check out strategy:

Configure SVN

With this configuration, the application under test as well as the test automation project will be checked out and updated locally.

Add Build Steps

Now, as the source code management is configured, we can start with processing the updated files.
First of all, let’s add MSBuild steps for both projects:

Add MSBuild Buildstep

Choose your configured MSBuild version and enter the path of the solution file relative to the repository root (which is the workspace folder of the Jenkins job) for both the automated and the automating project:

Added MSBuild Buildsteps

Add “Run a Ranorex Test Suite” Step

By adding these two build steps, the executables will be automatically built. Now the newly built application should be tested.

This can be accomplished by adding a new “Run a Ranorex test suite” build step that starts the test suite executable:

How to set up the „Run a Ranorex test suite” build step

  • Ranorex test suite file: Enter the path to the test suite file (*.rxtst) located in the output folder of your solution.
  • Ranorex run configuration: Enter the exact name of the run configuration you want to use. By default, the run configuration currently selected in the test suite is used. If you want to create or edit run configurations, please use Ranorex Studio or the Ranorex Test Suite Runner.
  • Ranorex report directory: Specify the directory that your report (and accordingly the JUnit report file) will be saved to. If you don’t specify a path, the directory where your test executable is located will be used.
  • Ranorex report file name: Specify the file name of the generated report. By default, the file name specified in the test suite settings is used.
  • JUnit-compatible report: If checked, Ranorex will create both a JUnit-compatible report and a Ranorex report.
  • Compressed copy of Ranorex report: Compresses the report and the associated files into a single archive with the extension .rxzlog. The following additional input fields will appear when this option is enabled:
    • Compressed report directory: Allows you to specify the directory that your compressed report will be saved to. If you don’t specify a path, the directory where your test executable is located will be used.
    • Compressed report file: Allows you to specify the file name of the compressed report file. By default, the file name specified in the test suite settings is used.
  • Global parameters: Allows you to create or override values for global parameters set in the test suite. Enter parameters according to the following pattern: “ParameterName=Value”. Separate parameters with semicolons or newlines.
  • Command line arguments: Allows you to add additional test suite command line arguments. Please refer to our user guide to get a list of all available command line arguments.

The test suite executable returns “0” on success and “-1” on failure. Based on this return value, Jenkins will mark the build as successful or failed.

Add Post-Build Action

After executing the automated tests, we will publish a JUnit test result report to the Jenkins build. For this reason, we have created a JUnit compatible copy of the report file, by checking the corresponding option. Now, we can add a “Publish Junit test result report” post-build action to the build job and define the test report xml, representing your JUnit report file.

Added JUnit Action

Additionally, we will send an email which informs us about the success of the triggered build.
This email should include the zipped report file, mentioned before, as attachment.
To do so, add the new post-build action “Editable Email Notification”, choose the report file location defined before as attachment, and add triggers for each job status you want to be informed about. In this sample, an email will be sent if a job has failed or succeeded.

Added Mail Action

Run Job

Once you’ve completed these steps and saved your changes, check if everything works as expected by clicking “Build now”:

Build Now

After running the generated job, you will see all finished builds within the build history. Icons indicate the status of the individual builds. If you click on a specific build, you will see the detailed JUnit test results. You can view the zipped report files of all builds by opening them in the local workspace (“Workspace/Reports”):

Build History

As configured before, an email will be sent to the specified email address(es), including the console output in the email text as well as the generated zipped report file as attachment.

Add Repository Hook

Now we can manually trigger a build. As we are working with Subversion, it would be beneficial to trigger the script for each commit.
To do so, you can add a server side repository hook, which automatically triggers Jenkins to start a new build for each change committed, as described in the subversion plugin documentation.

Alternatively, you can activate polling of the source code management system as build trigger in your Jenkins job configuration.

As shown in following picture, you can define the interval, after which the source code management will be invoked (e.g. 5 minutes after every full hour):

Added Build Trigger


Following the steps above you will be able to easily setup a continuous integration process performing the automated test of the application you develop. Each commit will now trigger an automated test run. Once the test run has finished, you’ll instantly receive a mail with the Ranorex test report.

Note: This blog was originally published in July 2012 and has been revised to reflect recent technical developments.

Download Free 30-Day Trial

The post Integrate Automated Testing into Jenkins appeared first on Ranorex Blog.

Categories: Companies

Beta 1

Thu, 05/11/2017 - 16:43

The post Beta 1 appeared first on Ranorex Blog.

Categories: Companies

5 Common Challenges When Using Selenium

Wed, 05/10/2017 - 14:10

There’s no denying the importance of Selenium when it comes to web browser automation. While its many automation benefits are obvious, there are common challenges both testers and developers alike encounter when using Selenium. In this blog post, I want to address five common challenges and show you how you can solve them with the Selenium WebDriver integration in Ranorex Studio.

Identifying dynamic content The challenge

It can be tricky to identify content with dynamically generated attributes using Selenium. Dynamic content is based on dynamic identifiers (IDs). These IDs are generated anew every time an element is displayed, which makes it difficult to address the web element based on this attribute. For example, the IDs in web applications based on the “Yahoo User Interface Library” look something like “yui_3_8_1_1_13679224741219_543”. This ID changes every time the webpage reloads. In this case, you cannot use the ID locator to identify the element.

How to solve it

Ranorex comes with a set of RanoreXPath weight rules that automatically decide which attribute to use to identify objects based on particular web libraries. If you want to resolve a specific problem when identifying web elements, you can add a rule to this set. Please have a look at the blog post “Automated Testing and Dynamic IDs” for detailed instructions. Once added to the rule set, you can create your script-free or code-based test scenarios and run them on your WebDriver endpoints. As a result, the object repository will be automatically filled with robust repository items.

RanoreXPathWeight Editor

Dealing with timing issues The challenge

Another challenge, especially when testing dynamic web applications, is handling timing issues – for example, when a query takes longer to provide the desired output. In Selenium, you have to manually implement a wait mechanism in code to overcome this issue.

How to solve it

Ranorex automatically creates search time-outs for each item in the object repository, providing a built-in safety net for possible timing issues. You can edit the search time-out of a repository item in Ranorex Studio (context menu item Properties). For further details about repository time-outs, please have a look at the chapter Waiting for UI Elements – Repository Timeouts in our user guide. In addition to the automatically added search time-outs, you can explicitly wait for a specific element to appear or disappear using a Wait For Exist or a Wait For NotExist action in the actions table. You can get an overview of all possible actions as well as detailed information about specific actions in the section Types of Action Items in our user guide.

Wait For Action

Maintaining web elements The challenge

Test maintenance is dreary and, unfortunately, unavoidable. Especially in complex test scenarios, it can be difficult to maintain web elements addressed in your automated tests. When using a pure Selenium WebDriver implementation to automate your test scenarios, the same web element may be used multiple times. If this element changes, you then have to alter every occurrence of it manually. Even if you have used the page object pattern to manage web elements, you have to find the element that has changed and fix it in code.

How to solve it

In Ranorex, you can use the central object repository to manage your web elements. Every time an element in your application under test changes, you only have to edit it once and all changes will be automatically applied to all occurrences of this web element. To do so, select the desired element in the repository and open its RanoreXPath. Simply re-track the element using Ranorex Spy to successfully identify the element for future test runs. Implementing data-driven testing The challenge

Selenium WebDriver doesn’t have a built-in data-driven testing mechanism. This means you have to manually connect your automated tests to external data sources, read the data out of these sources and execute your test scenario with the added data if you want to data drive your tests.

How to solve it

Data-driven testing is already an integral aspect of Ranorex. Without any additional preparations, you can choose between several types of data connectors (simple data table, CSV file, SQL database and Excel file). Simply use the data from these external sources, to automatically execute your test cases with different data sets. You can find detailed instructions on how to perform data-driven testing in the dedicated user guide chapter.

Data-Driven Testing

Reporting The challenge

An important aspect of any test automation environment is getting a detailed and easily understandable report for each test execution. When you use Selenium WebDriver, there are several possibilities to achieve a reporting mechanism. All of which, however, have to be implemented in code using third-party integrations.

How to solve it

Using the Ranorex Selenium WebDriver integration, you don’t have to worry about reporting. When you execute a website test on a WebDriver endpoint, a detailed Ranorex report will be automatically generated. This report provides you with a comprehensive overview of the entire test execution flow. As it is a JUnit compatible report, you can easily integrate it into any CI process.


As you can see, the matchless Selenium WebDriver integration in Ranorex Studio 7 allows you to finally use the best of both frameworks to your advantage and address common Selenium WebDriver pain points.

How the Selenium integration works Download Trial

The post 5 Common Challenges When Using Selenium appeared first on Ranorex Blog.

Categories: Companies