The Micro Focus ALM integration plugin provides an out-of-the-box integration of step with ALM.
With the ALM integration plugin you create, design and manage your automated test cases in ALM, run them on step’s Execution Engine, and evaluate the run results and test reports at the same place in ALM. This plugins is therefore the perfect solution for users requiring the best of the 2 worlds: the unique power of the step Execution Engine with the test management and reporting features of ALM.
The test case design relies on the standard plain text syntax of STEP (The same as used by the other integration plugins like Azure DevOps and Jira).
The field “Step Name” of the ALM Test Plan is used to described your steps. It is used in both the test execution reports in step and in the Test Runs reports in ALM. It is therefore a good practice to use short and expressive step names.
The field “Description” of the ALM Test Plan is used to specify the flow of your Test Plan. For the simplest Test Plans it is a simple sequence of keywords with key-values as parameters. More complex Test Plans make use of the step Controls in Plain text syntax and are documented here.
You could for example, call the keyword “Keyword1” with 2 parameters using below syntax :
The second step of the installation is to configure the controller so it will be able to communicate with ALM in order to retrieve the tests from ALM and publish the results of the test runs back into ALM.
First, you will need to register the ALM DLLs used for accessing the ALM API. You will need admin right on the Controller.
Open Internet explorer as an administrator and go to ALM, then click on tool:
Then go to HP ALM Client Registration:
Finally, click on Register HP ALM to trigger the registration:
The following message should appears at the end of the installation:
Adding 64 bit support for ALM connections
The ALM OTA DLLs are only available in 32 bits and can therefore only be integrated with 32 bits processes by default. In case you want to use our ALM daemon with a 64 bit JVM you must apply following workaround. This workaround adds registry entries ensuring that the OTA client dll will be called through a surrogate process.
Download and execute the attached registry script with administrative privilege.
Below configuration entries are mandatory and needs to be set to the file …\step-controller-X.Y.Z\conf\step.properties.
Other ALM related configuration entries are documented directly in the step.properties file.
Connect on your project and go to the “Test Plan” tab. A new “stepRunnerTP” button should be available
Create the following demo test, using basic logic blocks that can be used with step for ALM:
Select it and click on the new “stepRunnerTP” button. A new Internet Explorer with your step Controller should popup:
Log into the controller, you should get the following error. This is normal as the step Controller has yet to know how to communicate to the ALM instance:
You can then do the same validation on the “Test Lab” tab. The button will be called stepRunnerTL:
You can try to execute again from the test lab (so that we can also check the reporting of the execution back to ALM) the small demo test created before:
Contrary to previously, the controller is now able to query ALM about test information and you should be able to start the execution from the controller GUI:
You should then be able to see in step the result of the execution:
If you go back to ALM, you should now see the summary of this execution in the “Execution Grid” of the “Test Lab” (a refresh of the view may be needed):
And also the execution details in the “Test Runs”:
If the execution is reported as “Not completed”, check if the following exception is present in the controller’s log. If so, check that the formats specified in almrepository.reporting.dateFormat and almrepository.reporting.timeFormat match the date format displayed in ALM