HPE ALM Octane is HPE’s next-generation lifecycle management solution for modern application delivery. The first release was announced in early June, and there have been two updates to the functionality since the initial release. HPE ALM Octane will allow choice and flexibility to manage traditional hybrid or waterfall methodologies and/or agile development methodologies. This will be accomplished by combining functionality that is currently in HPE QC/ALM (now referred to as HPE ALM.net) and HPE Agile Manager.
I have had the opportunity to present HPE ALM Octane several times over the last few months, and I have found that there are some misconceptions about it that could use a little clarification.
Keep in mind that the current HPE ALM Octane is really the initial step in a long-term roadmap. HPE is developing HPE ALM Octane in an agile fashion, which means the product we see today is much different than the product we will likely see a year from now. The purpose of this blog is to help you understand what HPE ALM Octane looks like today.
HPE ALM Octane is the “non-IE” version of HPE QC/ALM.
Fiction. While it’s true that HPE ALM Octane is not dependent on Internet Explorer and is accessible in any HTML5-supported Web browser, it’s much more than that. HPE ALM Octane is designed with a completely new user interface, providing a targeted and simplified user flow. The interface is much cleaner and more modern than the HPE ALM.net interface. So while there may be a slight learning curve to become familiar with the new interface, it will be worth it.
Test plan and test lab modules are not included in HPE ALM Octane.
Fact. I know many of us use those modules day in and day out, so I realize this may seem unsettling at first. The main modules in HPE ALM Octane today are shown below.
While it’s true that you won’t find a module called test plan or test lab, manual and automated tests are absolutely supported in HPE ALM Octane. Manual tests can be created in the backlog and the quality modules. The idea is that the test reflects the quality of SOMETHING and also tests are created to cover SOMETHING.
Therefore, HPE ALM Octane allows you to add a test directly on a backlog item such as a user story or on an application module. Application modules are the functional areas of the product or application you are developing and can be used to organize tests by functionality, without creating actual folders. No more complicated folder structure to organize and find things!
The new interface also allows for tests to be run directly from the test itself. The screenshot below shows an example of a manual test being viewed from a user story. From the “Steps” tab, we can add and edit test steps. The red circle is highlighting the “Run” icon that can be used to execute the test. No need to navigate to a different module and create a new entity just to run the test. Yes, it took a short while to get used to this new way to work with manual tests, but I now find it quite efficient.
Currently, HPE ALM Octane functionality is geared toward agile projects.
Fact. However, this will not always be the case. As I mentioned above, HPE ALM Octane will eventually support both agile and non-agile projects. These first releases of HPE ALM Octane support agile concepts such as epics, features, and user stories. However, manual tests, automated tests, defects, and dashboard graphs are also supported and these concepts are not specific to agile projects.
HPE ALM Octane is SaaS only.
Fiction. When HPE ALM Octane initially became available, it was offered as a SaaS-only solution. However, HPE released the on-premise version in August, and it is currently available for download. Currently, the HPE ALM Octane server is supported on:
Currently, automated tests are executed via a CI server integration.
Fact. When using HPE ALM Octane to handle test automation, the automation scripts themselves will typically reside within a source control system (e.g., Git). Jobs which execute the automated tests are created within a CI tool such as Jenkins. Pipelines are then created within HPE ALM Octane, which graphically displays the CI server job as shown below.
After you run a job from Jenkins, any automated tests that ran are reflected in HPE ALM Octane. The test run results are also sent to HPE ALM Octane, and incorporated in the quality analysis. This enables you to view automated test run results along with manual test run results when tracking your product or release quality.
Keep in mind that this is the way automation is currently handled in HPE ALM Octane. I expect that we will see some changes to this as HPE ALM Octane continues to mature.
Customers may find themselves utilizing both HPE ALM.net and HPE ALM Octane platforms.
Fact. If projects are working fine with HPE ALM.net functionality, HPE has stated that there isn’t a rush to switch to the HPE ALM Octane platform. Over time, as more HPE ALM.net functionality is added to HPE ALM Octane this can be reevaluated. Projects that have heavy workflow scripting or custom reporting will likely be slower to transition off the current HPE ALM.net platform.
However, as new projects begin to surface, organizations should become familiar with what is currently in HPE ALM Octane and evaluate which platform is a better fit. In general, projects that are using the following concepts might be a good candidate for HPE ALM Octane:
- Epics, features, and user stories
- Automation being executed from Jenkins or TeamCity
- Manual testing using Gherkin
- Access from any browser
Hopefully, this helps provide clarity around a few key concepts within HPE ALM Octane. For additional information, you can check out a recording of a recent Orasi HPE ALM Octane webinar here. As additional functionality is added to HPE ALM Octane, we will keep you updated with additional blog posts and webinars.