Set up UFT One integration

This topic explains how to integrate ALM Octane with UFT One via Jenkins or Bamboo. This integration enables ALM Octane to reflect the UFT One tests from your Source Code Management (SCM) repository as executable automated tests. You can then include and run these UFT One tests in test suites.

ALM Octane-UFT One integration flow

Once the UFT One integration is set up, the CI server and the SCM system are transparent and you can work with UFT One and ALM Octane directly: 

  • Create and edit your tests and their data tables in UFT One and save them in a Git or SVN repository.
  • Run the tests and track their results in ALM Octane.

The ALM Octane-UFT One integration flow includes the following:

Action Description
Set up To set up the integration, create a CI server and a testing tool connection in the ALM Octane settings. This process is described in the sections below.
ALM Octane discovers UFT One tests and data tables

ALM Octane creates automated test entities to represent the GUI and API UFT One tests stored in your repository.

ALM Octane periodically checks for changes in the repository.
Associate tests with ALM Octane entities

Associate the tests with your backlog and application modules. This helps you use the test run results in ALM Octane to track your product and release quality.
Run tests

Include the tests in test suites to plan and run them from ALM Octane. ALM Octane triggers the test runs via the CI server. The tests run on UFT One machines configured as Jenkins execution nodes.
Analyze release and product quality Track the UFT One test results as part of the overall data in the backlog, quality, and dashboard modules.

The image below summarizes the architecture of this integration (with Jenkins):

Back to top

Before you set up the integration

Set up UFT One to store tests and data tables in a Git or SVN repository. For details, see the UFT One Help Center.

Follow these integration guidelines:

  • UFT One-SCM integration is supported for UFT One 12.50 and later.

  • For ALM Octane to locate the data tables in your repository, store them in an entirely separate folder from your tests.

Tip: If you don't have a dedicated CI server, and you only need a lightweight CI to be used primarily for triggering UFT One test runs from ALM Octane, refer to the Minimal Jenkins Installation for ALM Octane quick start guide.

Back to top

Set up connection to ALM Octane

In your CI server, set up the connection to ALM Octane.

  1. Set up a Bamboo server configured with the App Delivery Management Bamboo CI Plugin. This enables Bamboo to integrate with UFT One.

  2. Install and configure the ALM Octane CI Plugin to integrate between Bamboo and ALM Octane.

    In the Client ID and Client secret fields, enter the API access key and secret obtained from ALM Octane Settings. The access key must be assigned the CI/CD Integration role in all relevant workspaces. For details see Install and configure the ALM Octane CI plugin on your CI server.

  1. Set up a Jenkins server configured with an SCM plugin:

    1. Install a Jenkins server. You do not need to configure a full CI system for this integration. Configure only the area described below.

      For a list of plugins that must be installed on the Jenkins server to enable ALM Octane integration, as well as plugins that are supported by the ALM Octane integration but not required, see Application Automation Tools wiki page.

    2. Install the Jenkins Git plugin (version 2.4.4 or later) or the Subversion plugin (version 2.5 or later) to create the Jenkins-SCM integration.

  2. Install the Application Automation Tools plugin.

    This plugin supports ALM Octane-Jenkins integration and enables Jenkins to run UFT One tests.

    If your tests are stored in ... Use this version of the plugin

    Git

    		 5.2 or later
    SVN 5.3.5 (beta) or later

  3. Configure the plugin to connect to ALM Octane. For details, see Install and configure the ALM Octane CI plugin on your CI server.

    Tip: Before configuring the plugin, obtain an API access Client ID and Client secret from your space admin. For details, see Set up API access.

You do not need to create pipelines in ALM Octane or create any jobs in Jenkins.

However, if you manually create a job to execute tests, and tests are located outside of the job workspace, define a parameter UFT_CHECKOUT_FOLDER with the path to the repository root in the file system. This enables ALM Octane to display the test name, rather than the full path to your test. This is supported with plugin version 6.7 and later.

Back to top

Add the CI server in ALM Octane

In ALM Octane, add your CI server.

To add the server:

  1. In ALM Octane, click Settings > Spaces and select a workspace.

  2. Select the DevOps > CI Server tab.

  3. Add a CI server and select your CI server's URL.

For details, see Add CI/CD servers on ALM Octane.

Back to top

Create a UFT One test runner

This section describes how to create a UFT One test runner in ALM Octane.

Note: The test runner framework only supports external data tables on UFT One tests of GUI type (and not API type).

To create a UFT One test runner:

  1. In ALM Octane, click Settings >  Spaces and select a workspace.

  2. Select the DevOps > Test Runners tab.

  3. Click + Test Runner.

  4. Name the test runner entity that ALM Octane will use to run the UFT One tests, and select the UFT framework.

  5. Select your CI server.

    The list displays all servers that meet the following conditions:

    • The server has the ALM Octane CI plugin installed and configured to access your ALM Octane.

    • The API Access keys that the plugin is using are assigned the CI/CD Integration role in the current workspace.

  6. Specify the type and URL of the SCM repository that contains your UFT One tests and data tables.

    You can create multiple UFT One test runners in a workspace, but each test runner must have a separate repository.

  7. If required, provide the authentication details for your repository.

  8. Click Test Connection to make sure the configuration is correct.

  9. Click Save and Connect to complete the connection.

  • If you are integrating via Bamboo, ALM Octane creates two plans: UFT One test discovery that connects to the repository and discovers the UFT One tests and data tables, and UFT One test executor that runs the tests.

  • If you are integrating via Jenkins, ALM Octane creates a Jenkins job that connects to the repository and discovers the UFT One tests and data tables.

Tip: If necessary for troubleshooting, you can find this job on your CI server based on the connection ID.

To enable test execution, see Enable the CI server to trigger UFT One test runs.

The test scripts and the data table content are available in UFT One only.

Tests tab

In the automated test entities in ALM Octane, the following fields are set:

  • Testing tool type = UFT One

  • Test type = API or UI

  • Executable = Yes. These tests can be added to test suites and run from ALM Octane.

If you do not see all of the expected tests in the Tests tab in ALM Octane, try refreshing the list of tests.

What happens when a test is changed in UFT One

ALM Octane continues to periodically check the repository and updates its entities as follows:

  • If you add a new test in UFT One or change an existing one, the changes are reflected in ALM Octane.

  • If you delete a test from UFT One, the relevant test in ALM Octane is not deleted but is marked as not executable. This way, the test and its history, runs, and reports remain available.

  • If you rename a UFT One test in GIT, the test is renamed in ALM Octane if your ALM Octane version is 12.60.3 or later, and the test was committed without additional changes.

  • If you rename a UFT One test in SVN, or if you rename in GIT and do not fill the above conditions, a new test is created in ALM Octane and the original test is marked as not executable

Back to top

Link from ALM Octane to a UFT One automated test

ValueEdge and ALM Octane can create links that you can use to drill from your UFT One automated test, directly to the corresponding test in the SCM.

To enable SCM test links:

  1. Create a UFT One test runner as described above.

  2. Define a File in branch template pointing to your SCM repository, as described in Enable linking to your repository viewer (Git or SVN only).

  3. When a UFT One automated test is discovered by the test runner, the test details in ALM Octane will include an SCM test link field. Click the link to navigate to the UFT test in the repository, based on the template you set in the File in branch template.

Back to top

Enable the CI server to trigger UFT One test runs

This section describes how to enable the CI server to trigger UFT One test runs for Bamboo and Jenkins.

Enable Bamboo to execute UFT One tests

To enable executing UFT One tests:

  1. In the Security and Permission options for the server, clear the Enable XSRF protection option before running tests on your Bamboo server.

  2. Enable the Agent as described in the plugin's User Guide > Installation section.

    Note that the UFT One test executor plan in Bamboo contains the parameter testsToRun, which receives the list of tests from ALM Octane that Bamboo will trigger. (This is created automatically by the integration.)

Make sure UFT One can run your tests

  • When UFT One opens, it must load all of the add-ins required for your tests.

  • The UFT One machine must be able to access the application under test.

Make sure UFT One can run your tests

  • When UFT One opens, it must load all of the add-ins required for your tests.

  • The UFT One machine must be able to access the application under test.

Configure UFT One to enable running tests over a disconnected remote connection

This configuration is required if you are using execution nodes to run the UFT One tests. Without this configuration, test runs triggered by ALM Octane will remain Pending on Jenkins until someone logs in to the execution node either directly or with a remote desktop connection.

To configure:

  1. In the UFT One Options dialog box, open the Run Sessions pane (Tools > Options > General tab > Run Sessions node).

  2. Select Allow UFT One to continue running GUI or business process tests after disconnection from an RDP computer.

  3. Enter a user name and password of a user who can log in to the UFT One machine.

Connect Jenkins to your UFT One machines

To connect Jenkins:

  1. On your Jenkins server, define your UFT One machines as execution nodes. Jenkins will use these nodes to run UFT One tests that ALM Octane triggers.

    Make sure the names of your execution nodes include the string uft.

  2. On the UFT One machine, connect the execution node to the Jenkins server:

    Open the Jenkins server URL in a browser, go to Manage Jenkins > Manage Nodes.

    Select the node, click Launch to download an agent program from the server to the execution node, and then run that program on the UFT One machine.

For details, see the section on execution nodes in the Application Automation Tools wiki page.

Note: If your Jenkins server is installed on a Windows machine, you can install UFT One on the same machine instead of creating execution nodes.

Set up Jenkins to enable running UFT One API tests

Relevant for UFT One versions earlier than 14.01.

To run API tests, ALM Octane needs the Script.dll and Script.pdb files that UFT One generates when it first runs the test.

By default, these files are not stored in the SCM repository.

To make these files available to ALM Octane:

  1. Run the API test in UFT One to generate the files.

  2. Adjust your SCM definitions so Script.dll and Script.pdb are not ignored.

  3. Push (Git) or commit (SVN) the tests from UFT One to save the files in the repository.

  4. Verify that the Script.dll and Script.pdp files are now in the repository.

Set up Jenkins to enable opening the UFT One tests result from ALM Octane

By default, Jenkins' Content-Security-Policy header prevents viewing UFT One test results reports remotely.

To enable opening UFT One reports from ALM Octane using the Show in Jenkins button in an automated test, you must clear the CSP property.

Implement one of the following workarounds:

  • Clear the property temporarily, until the next time the Jenkins server restarts:

    In Jenkins, open Manage Jenkins > Script Console, and run:

    System.setProperty("hudson.model.DirectoryBrowserSupport.CSP", "")

  • Clear the property permanently:

    Run Jenkins with JAVA_OPTS option and add the following option: 

    -Dhudson.model.DirectoryBrowserSupport.CSP=

Back to top

Next steps: