A hot topic in today’s QA world is continuous integration (CI), and one of the leading tools in the CI world currently is Jenkins. What is Jenkins? Jenkins is a cross platform continuous integration delivery application, which integrates with most QA software, build tools, and SCM repositories.
Perhaps the best part of Jenkins is the available integration between HPE ALM and Jenkins. The HPE Application Automation Tools add-in allows Jenkins to run builds from a specified folder in ALM or from a local location. Currently, there are eight available jobs packaged with this add-in:
- Running tests sets from HPE ALM (this method is useful for HPE Quality Center enterprise users)
- Running server side tests using HPE ALM Lab Management
- Creating/updating the AUT Environment Configuration using HPE ALM Lab Management
- Uploading test results to HPE ALM (useful for Junit, NUnit, or TestNG frameworks)
- Running functional tests from the file system
- Running functional tests of a mobile application from the file system
- Running HPE LoadRunner scenarios from the file system
- Running performance tests using HPE Performance Center
Jenkins is free, is open source, and installs in minutes. For installation, all you need is an open server. I would not recommend installing Jenkins on an existing ALM server. Instead, give the service its own separate server.
If you are not currently a continuous integration shop, you may wonder if Jenkins offers any functionality from which you can benefit. Yes it does, especially if you are currently using an HPE QC enterprise license. Without having an HPE ALM premier license, you do not have the ability to schedule functional test runs or time slots in HPE ALM Lab Management.
Until now, your only other option would be to use the ALM RunTestSetScheduler, which is not supported by HPE. However, with Jenkins, you can create a job to run a test set from ALM and use Jenkins to schedule a build at a particular time to kick the test set off and publish the results to ALM.
How does all this work? At a very high level, the Jenkins instance operates with a client server relationship. In Jenkins, the server is called the master, and the client machines are referred to as slaves. To set up the HPE Application Automation Tools add-in, you technically do not need to have the HPE UFT/LoadRunner machine set up as a slave machine. However, in actually implementing this, I have never been successful in getting this setup to work without having the testing machine set up as a slave, so I would highly suggest setting up your test machine as a slave and making sure it is up and running in Jenkins.
With Jenkins receiving more and more attention recently in the QA community, I would suspect that the future generations of ALM are going to have the ability to communicate directly with Jenkins and kick off Jenkins’ builds directly from the platform. If this does happen, it will allow the future generations of ALM to publish build results from many of the other tools that have available add-ins in Jenkins. Just some food for thought.
Resources:
https://wiki.jenkins-ci.org/display/JENKINS/HP+Application+Automation+Tools
https://wiki.jenkins-ci.org/display/JENKINS/Step+by+step+guide+to+set+up+master+and+slave+machines