Set up UFT One integration

You can integrate with UFT One through your CI server. This enables you to reflect the UFT One tests from your source code management (SCM) repository as executable automated tests. You can then include and run these tests in test suites.

Integration flow

After setting up the integration, the CI server and the SCM system are transparent and you can work with UFT One directly. This enables you to:

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

The 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 OpenText Core Software Delivery Platform settings. This process is described in the sections below.
Test and data table discovery

Automated test entities are created to represent the GUI and API UFT One tests stored in your repository.

The tests are periodically checked for changes in the repository.
Associate tests with entities

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

Include the tests in test suites to plan and run them. The test runs are triggered through the CI server. The tests run on UFT One machines configured as Jenkins execution nodes.
Analyze release and product quality

Track the 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. For details on supported CI servers, see CI integrations.

OpenText Functional Testing integration flow.

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 OpenText Core SDP to locate the data tables in your repository, store them in an entirely separate folder from your tests.

Back to top

Set up the connection

In your CI server, set up the connection to OpenText Core SDP.

CI server Steps
Bamboo

  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 with Bamboo.

    In the Client ID and Client secret fields, enter the API access key and secret obtained from OpenText Core SDP Settings. The access key must be assigned the CI/CD Integration role in all relevant workspaces. For details see CI server integration.

Jenkins

  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 the integration, as well as the supported plugins, 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 the Jenkins integration and enables Jenkins to run UFT One tests.

    If your tests are stored in Git, use version 5.2 or later of the plugin.

    If your tests are stored in SVN, use version 5.3.5 (beta) or later of the plugin.

  3. Configure the plugin. For details, see CI server integration.

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

You do not need to create pipelines in OpenText Core SDP or create any jobs in Jenkins.

However, if you manually create a job to run 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 OpenText Core SDP 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

This section describes how to add your CI server.

To add the server:

  1. Open the Settings menu , click 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.

Back to top

Create a UFT One test runner

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

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. Open the Settings menu , click Spaces, and select a workspace.

  2. Select the DevOps > Test Runners tab.

  3. Click + Test Runner.

  4. Name the test runner entity to 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 Application Automation Tools plugin installed and configured to access your OpenText Core SDP.

    • 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.

    CI server Description
    Bamboo

    If you are integrating using Bamboo, two plans are created: 

    • UFT One test discovery that connects to the repository and discovers the UFT One tests and data tables.

    • UFT One test executor that runs the tests.

    Jenkins

    If you are integrating using Jenkins,  a Jenkins job is created 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 runs, see Enable the CI server to trigger test runs.

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

Tests tab

In the automated test entities, the following fields are set.

Field Value
Testing tool type UFT One
Test type API or UI
Executable Yes. These tests can be added to test suites and run from OpenText Core SDP.

If you do not see all of the expected tests in the Tests tab, click the Refresh button to refresh the list of tests.

What happens when a test is changed in UFT One

OpenText Core SDP continues to periodically check the repository and updates its entities as follows.

Change Impact
Add test

If you add a new test in UFT One or change an existing test, the changes are reflected in OpenText Core SDP.
Delete test

If you delete a test from UFT One, the relevant test in OpenText Core SDP is not deleted but is marked as not runnable. This way, the test and its history, runs, and reports remain available.
Rename test in Git

If you rename a UFT One test in GIT, the test is renamed in OpenText Core SDP if using version 12.60.3 or later, and the test was committed without additional changes.
Rename test in SVN

If you rename a UFT One test in SVN, or if you rename it in GIT and do not fill the above conditions, a new test is created in OpenText Core SDP and the original test is marked as not runnable.

Back to top

Run tests on-demand using GitLab

You can use the FTToolsLauncher tool to integrate with GitLab to run UFT One tests in GitLab on- demand. This is supported for GitLab 14.3 and later, including GitLab Cloud.

For details on how to set up this integration, see Running UFT Tests using ALM Octane testing framework (Test Runners).

Back to top

Link to an automated test

You can create links 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. For details, see Create a UFT One test runner.

  2. Define a File in branch template that points to your SCM repository. For details, see Enable links to the Git or SVN viewer.

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

Back to top

Enable the CI server to trigger test runs

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

For Bamboo integration

Action Steps
Enable Bamboo to run 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 Installation section of the plugin's User Guide.

    Note: The UFT One test executor plan in Bamboo contains the parameter testsToRun, which receives the list of tests 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.

For Jenkins integration

Action Steps
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 UFT One tests. Without this configuration, test runs triggered by OpenText Core SDP 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 uses these nodes to run UFT One tests that OpenText Core SDP triggers.

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

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

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

    2. 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, you need 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 OpenText Core SDP:

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

  2. Adjust your SCM definitions so that 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 UFT One tests result from OpenText Core SDP

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

To enable opening UFT One reports 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: