OpenText ALM Octane Reviews

We use Octane to track our testing plan for projects.

Octane works well with the Jira portfolio to track the project with two methods: Agile and Waterfall. We can track all the testing in Waterfall or Agile and synchronize it with Agile tools.

The limitation of Octane is that we can't do a release outside of the sprint. We can only plan the release in the sprint. With Agile and JIRA tools, we can plan the release outside the sprint and do a global release of all the projects from the sprint. It would be helpful if Octane had a portfolio follow feature so we could follow the project portfolio. We need the all-view of a project to track it step-by-step and stay on deadline. 

We started using Octane two years ago.

Octane has been stable so far.

Octane is scalable. We're looking to scale up in the next year.

The end-user in charge of testing could easily deploy Octane, onboard new users, and train new users.

I think we can give ALM Octane an eight on 10. For now, we recommend using Octane to track the test plan for testing.

One use case was for development life cycle management for a pool of developers using it in an Oracle and .NET development environment.

One of the benefits is the integration with different platforms. Having the defect management, and being able to relate defects and testing to the initial user requirements—having this complete life cycle—is one of the major advantages with Octane. It's the "life cycle" way of thinking that the solution provides. That is a very important component of Agile and DevOps. Octane integrates with your CI server for continuous integration and delivery. This "life cycle" approach gives us end-to-end visibility.

It also provides a single platform for all automated testing and that definitely helped facilitate the testing, the test scenarios, and collaboration between the test team and the development team. Having both together on a single platform allows us to ease the integration between the different teams. One of the major things we talk about regarding Agile, and one of the major components we talk about regarding DevOps, is this seamless integration between the teams.

In addition, it gives you a single, global ALM platform that supports all your Agile and Waterfall needs. One of the big challenges for DevOps is the adoption of a tool among the teams. The fact that the tool facilitates and supports this definitely helps the adoption.

ALM Octane also reduced testing costs overall. It's hard to say exactly how much, but I would estimate by 20 percent. It also definitely reduced integration costs by building a streamlined application delivery pipeline connecting to all IDE, CI, and SCCM tools. In this case the integration costs were reduced by 20 to 30 percent. Finally, it helped to produce releases faster, again by about 20 percent.

The valuable features start from the defect management in the life cycle and go into the part for versioning control.

The defect management gives us full-fledged capabilities for handling defects, including capturing the details of the defects and even screenshotting the defect cases. The defect management is comprehensive. 

Also the integration capabilities with other development platforms we were using was helpful. The out-of-the box integrations are definitely a big part of making Octane comprehensive when it comes to DevOps quality management. It is full of features and gives us flexibility to provide the needed integrations with different platforms.

The solution natively supports Waterfall, Hybrid, and Agile software development at enterprise scale. That's very important because there is a big shift going on from the Waterfall environment into Agile in DevOps. Having a tool that can give us both practices was important.

In addition, Octane's Agile support is good at both the team and the portfolio levels. It has dedicated capabilities for Agile and is very flexible and comprehensive in these two areas.

Security and security management, meaning the integration of the security, could be enhanced. We know about Fortify, but it would be better to have security features in the original Octane platform without the need for another solution or another application.

We've been implementing solutions with OpenText ALM Octane since 2016.

From the stability perspective it's okay.

We did not stress-test it to see what it would be like in a mega environment. Usually we deployed it in a medium-sized environment, with 20 to 30 developers, and the scalability was okay.

I would rate technical support for the solution at six out of 10. Usually there is a lack of connection among the teams for handing over support cases. You often need to do or redo some work whenever support cases are opened. If it is handed over to a new engineer, you need to start doing things over from the very beginning. You have to explain things again.

The initial setup of Octane was straightforward. Because you are talking about development and software developers, it's not like a normal tool for business users. It was not complicated for people to get along with the tool and use it and integrate it.

Usually, deployment takes, on average, a maximum of two months. The deployment plan definitely depends on what the current technologies are, the integrations needed, and on what types of development environments and what types of IDEs are involved. It also depends on whether there are other systems and tools available already.

Just one person is required for deployment and maintenance of the solution. Rather than a developer, that person would be an administrator for the system.

The benefits I've mentioned can be reflected as monetary benefits, which I would estimate at 35 percent annually.

Microsoft is a big challenge for OpenText when it comes to pricing because they are much cheaper. But it definitely depends on the complexity of the environment. If it has multiple technologies, at that point, looking at other options and Microsoft would be a feasible approach.

We work with Microsoft TFS. We also use JIRA, but I don't consider JIRA a competing component, rather we integrate it. One of the pros of TFS is definitely its integration and supportability if you are a Microsoft development environment, using .NET and the like. There's a lot of seamless integration there. Also, from a pricing perspective, usually Microsoft can provide you with very cheap packaging options. Those are the two main pros for Microsoft TFS.

Dedicate someone for the administration. Often companies assign a developer to take care of it but this is not the proper approach. Someone needs to have responsibility for the administration. Also the process when using the solution should be a consultative approach. First look at your process and your development life cycle and then reflect it in the tool. Also, be clear about the integration points before starting the implementation so that the technical requirement and scope, etc., are clear.

Regarding reducing manual testing time, this didn't happen in the extreme because we were already automating most of the environments. There was a lot of automated testing. But it helped in facilitating the "life cycle" approach, especially if the environment already had Microsoft TFS. You integrate it and put it on top and you gain big benefits.

We are using it for agile projects. Our company projects run using Agile models, so we use all the important modules of Octane, like Backlog, Epics, Feature, and user story in Tasks. We are also using the Product Backlog and Team Backlog modules as well as the Quality modules under quality, test and defects. This is primarily for agile and are all the modules and dashboards that we use. 

Another use is for waterfall projects. To some extent, we are using the requirement documents and Quality modules for our waterfall projects.

We just started analyzing and using a module called Pipelines Analysis. We are trying to integrate our Jenkins with Octane to start using it. This is in the initial stages.

After taking input from the OpenText sales team, deployment team, installation team, and professional services team, we are using Octane to its full capabilities, except for with the Pipeline Analysis and dashboards. We still need to focus more on dashboards, because Octane does support plenty of dashboards. We want to start using those in a big way along with the Pipeline Analysis. We are already using all the other modules in a big way. We started configuring dashboards for agile, waterfall, and various built-in widgets, but this is also in the initial stages. We need to explore more the dashboards and Pipeline Analysis, which is where we are seeking support from OpenText.

It is purely for project milestone progress, project environment, project development, project execution, software development, and software execution. Then, we are using it mainly for holding and maintaining the repository of Product Backlog, Epics, Features, testing test cases, system integration testing, and user acceptance testing. That is the scope that we have defined.

Its end-to-end traceability is one of the big advantages. Most of our agile projects work in a closed team structure. We are seeing what is the flow, where we are, and what is the project milestone. So, it provides end-to-end traceability and good visibility of project milestones. 

In real-time statistics, anyone can go and configure it easily. The user interface is very user-friendly. 

We built a status dashboard within Octane by adding some additional user defined fields (UDFs) that use real-time status about how much a project progressed, how much testing is done, and how much testing is left. Then, project management can help with visibility of the progress for every project within Octane.

The cluster architecture that we implemented was server to server communication: Octane application to Elasticsearch and Elasticsearch to another Elasticsearch service. Recently, we found this is a security gap. The Octane application is interacting with Elasticsearch server, but that was missing from the requirements and prerequisites in the setup. The OpenText team has not given advice on how to implement authentication-based communication between Octane to Elasticsearch, and we found it as a gap later, then our security team asked us to fix that gap. So, there was a lot of time spent on rework. They should have helped us with a clear requirement. This requirement has slipped from the initial requirements and drafting during the installation, causing additional rework for us after installation. This means my admin team and I have to work to fix that gap. I already gave this feedback to my customer success manager, "Security related prerequisites and requirements should be thoroughly explained to the client." Hopefully, they can apply this and avoid future rework.

For the requirement document, the module should provide multiple templates to be prepared, or customized quickly, and be reusable.

For the Pipeline Analysis, job or application grouping has to support Jenkins job grouping, because we have thousands of jobs running. Unfortunately, we are unable to group those by using multiple filters. They could help us with these features in upcoming releases in the next six months. That would be great because many testing and production jobs for Jenkins users need filters and grouping.

We started using the tool in the last four to five months. Now, all our users are using OpenText ALM Octane.

For the last four months since we have been using it in a big way, we have not seen any downtime or surprises from the stability from an availability point of view. 

We have dedicated administrators who handle support for Octane and other tools.

It is scalable. We do need to explore it more to determine its support for a scalable framework. 

We are in touch with them. Their support is very good. We are constantly communicating with our customer success manager, who is helping us with a lot of queries. He is trying to resolve them. He brings in his R&D team to sort out our issues, which is good. We are getting good support, but there are a few product limitations that we have highlighted. We have asked them with help fixing those limitations by providing alternative solutions.

The requirement document has to be more flexible for the features, user interface, modules, and capabilities. It needs more advanced features, like copy paste of the various templates. It should have an inbuilt capability to build and design any template with reusable capability.

We moved from ALM Quality Center to Octane. We mainly switched because we have more than 50 percent of our projects running on an agile model, and ALM Quality Center doesn't support agile. 

We wanted to have interim projects for traceability and milestone visibility. We also wanted to have a tool where my team could write scenarios for user stories and those user stories would be available in a single tool. So, Octane is a better tool for the future.

Octane supports DevOps integration tools.

The actual Octane installation is straightforward, but it was a complex process for us because it is a cluster architecture. We have two Octane applications, three Elasticsearch, two databases, and seven to nine servers. While complex, we are not experiencing any issues so far. 

It was a nine week activity where we did the initial setup. The process was complex. We found issues while doing the integration between Jenkins and the DevOps and automation tools. 

When we started the integration with the other tools, like Jenkins, Selenium, or UFT, and tried to automate things or integrate with Jira, then it took more time because of the compatibility issues. It may not be working as expected and my automation framework may be different as well as Octane may not support my automation framework. My automation framework may be using Selenium, so I have to change my automation framework to ensure that it works with Octane. These things have to be in front of the client in advance to work out and give advanced information about compatibility issues of the automation framework and compatibility with the Octane, so an evaluation can be done during the due diligence on the first week of the kickoff meetings. Then, we can save time during the implementation.

The OpenText team should be providing more end-to-end view during the installation and user acceptance testing. They should provide more knowledge on the usage of the tools and various important capabilities, e.g., how do we use that? That is the missing part of the Professional Services. We had to go over it again by raising many queries and tickets. Therefore, the knowledge transfer of capabilities has to be given more focus during the installation.

Integration with other tools, compatibility, and frameworks has to be thoroughly checked by the OpenText team in conjunction with the client team for faster integration and to avoid surprises during the implementation.

For deployment, I was involved as a manager and there were two more guys from my admin team, who looked after the tools. There was one person from OpenText Professional Services along with a OpenText project manager. There were two team members actively involved throughout the project to open firewalls, do the setup, install, and troubleshoot. There was also one more guy for automation purposes when we were working on the automation integration for Selenium and UFT, and he worked for two to three weeks of time. Overall, three people worked for eight weeks.

We are not using this solution for operations. We are using the Octane tool for purely project solution delivery. For operations, we use Remedy tools, not Octane.

Jira has its own limitations, so we thought Octane would be better.

Our testers and manager do conduct risk-based testing implicitly, but we don't call it that. We apply it unconsciously and do it on the fly. We upload 100 or 200 test cases, depending on the timeline, and prioritize them. At the end of the day, we execute 70 or 80 of them and roll out the project. Eventually, all the functionalities are covered and no defects slip to production.

Currently, Octane's support for single sign-on is implemented separately, so we are not using it. Maybe in future we will use it.

We are ready to explore a couple of the solution's capabilities. I would have given a nine out of 10 had I explored those capabilities and been satisfied with them, but I am unable to do that. However, I can give the overall tool after the installation with support an eight out of 10.

We have a relatively splintered tool set and a number of tools which could not connect all of those things together. Therefore, the use case for ALM Octane was that we were trying to create a single version of the truth. A single source of everything to change within the IT department. 

I work in the programs management department.

We are using the latest version of the product because we are cloud-based. We receive all the deployments as they are released.

Octane has definitely improved the capability that we have for visibility within our tool set. The ability to report and see the current status on change, defect, and test runs on a spring by spring basis within our programs. Previous to this, change management was done in one system and testing was done in another system. Defects were in one of those systems, but they were like forgotten children and weren't really linked to anything. 

Octane has made everything a lot more visible. It's ability to relate everything together and create spider diagrams of change, the lifecycle of that change, defects, and the test status. These have made a massive difference to the visibility and our ability to trace back to the origin of a change, where it started, and see how it finished.

It's beginning to improve our processes as well. We are seeing some real improvements in the way we do things. We are becoming more agile in the way we do it because of that and in a way that stories are managed. Stories are given lifecycles as opposed to just being entities within a tool.

The visibility that we received from the ALM tool is that we can see a change through from its early requirements all the way through to development check-ins to the pipeline release then to the point that it's deployed. We can see the full lifecycle of the change within the ALM tool including integrations that we never before had in a change management tool. It's almost revolutionary for some people here to see check-in information appear against a user story in an ALM tool.

• Octane is built on the SAFe framework, which is the agile methodology that we are currently following.
• The capability that it has for so many out-of-the-box integrations is a fantastic feature. 
• The very clean, easy to use UI that it promotes.

The reporting side of ALM Octane could do with a few areas of improvement. There is not enough flexibility in the way that we can cut up the data to report on certain things. For instance, with test information, we can't split that up by team, so it's quite difficult to see what coverage each team is currently working on. Some tech managers and scrum managers want to see the testing which going on within their team, but it is difficult to see. We only get a more holistic overviews of that.

I come from a testing background, and think the testing could be improved. 

It is a very stable platform. We occasionally see areas that come up with a more client side, so they're not blanket across everyone. Sometimes people use the wrong browser. The product clearly states that it doesn't support IE, but then who would support IE, as it is end of life. 

We've only had a few stability issues. Generally, we have issues following any deployment they do, so if they do a deployment on a Sunday, then we may have a couple of issues on a Monday or Tuesday. However, their support and willingness to react and resolve issues for us has been second to none. They've been low impact to the point where it has not damaged anyone's perception at all.

We have 220 users on it. I have spoken to clients who have 3000 users on it. It's relatively scalable. We haven't seen any performance issues at all as we have ramped up the amount of data that we have on it or the amount of users. Our users include scrum masters, developers, testers, product turners, subject-matter experts, and business intelligence analysts.

In terms of usage going forward, we will rollout to our operations department. We'll get Ops using the same platform, so that should be another 60 to 70 users. The benefits of this would be that we would have more work concentrated all in the same place. Therefore, we can have a lot of crossover between other departments which aren't currently on ALM Octane that we can get onto Octane. This would make it work better and make it easier to manage because it would be a single place for work to be referred between teams, as opposed to having to go to a different tool if someone needs something hardware or software related to be created. 

For a company of Micro Focus' size and delivering this large of a tool, their engagement with me has been unbelievable. It has been to a point where I have never experience engagement like this from a software house. I speak to developers and architects. I speak to people who actually care about the issues that they are speaking about. I don't just get someone in a call center who is logging a ticket, and says, "Someone is looking into this." Then, the ticket disappears into the abyss for three months. It's really nice to see and have intimate feedback on your suggestions or queries. That relationship has been almost as valuable as the tool.

The technical support, help desk, or service desk where you log a ticket on their service platform has the ability to turn around an issue quickly and is very reactive. 

I logged an issue on Monday afternoon, and within 12 hours, it was fixed. They did a deployment on Sunday, where they made changes to the history area of every ticket. Then, on the Monday, that history had vanished. We noticed the history had disappeared. The history for every single change that we had in ALM Octane was gone. I logged a ticket with them late in the afternoon on a Monday, then by 9:00 in the morning the next day, our history had been restored. Whenever they do a deployment, if we have issues, it takes them no longer than three or four days to resolve that issue and deploy a fix for us.

One of the biggest strengths of the community that developed Octane is they are so willing to listen to their customers and learn, then improve the tool that they have delivered. They try and make it fit for the customers who are using it.

We were using Enterprise Tester and Rally (CA Agile) for change management. We switched from Rally to ALM Octane because of the lack of integrations and lack of drive to see Rally improve (from the company) because Rally is now owned by CA Technologies, and technically called CA Agile. CA has multiple other products that do the same thing as Rally. They have sort of acquired Rally, and it almost gives the impression that they will end of life Rally at some point, then take the user base and put them onto the tools that CA have. 

Also, Rally's age is a factor. Rally was one of the first scrum-based agile tools. It did a lot of things very well in its early life. It's been overtaken by newer agile tools now. The last reason was because Rally was not our choice. It was a tool that was pushed onto us by a third-party integrator when we brought them onboard to help us deliver a large program, so we just ended up with it. When you don't bring in a tool yourself and don't integrate it yourself, it ends up being a little bit of a mess on the administration side. There was a lot of stuff in it that had no home, no direction, nor desire to ever be completed, and had not been managed correctly. Thus, the administration to cover the tool was enormous.

We switched because outgrew the Rally tool with our process. It had gone beyond the capabilities of Rally.

People are generally happy with the position that they are in now in comparison to the position that we were in when we were on Rally. The administration is certainly a lot better now that we're on ALM Octane purely because people have a desire to not want to end up in the same situation, thus people are more conscientious of what they're doing.

The initial set up was very simple. The tool from getting our license to starting to use it, there is not a lot to do. We have evolved with the tool, as the tool has gone on, but we started using it straightaway. There was nothing that we needed to do to make that tool work. We have taken a very step based approach. We started using it, then we developed some changes in the way the workflow flowed. We have added additional fields here and there, where we decided we needed to do so. Then, we added additional bits of functionality through other bits of integrations as we've been seeing the need or when we know we've embedded it in processes with other things. We've rolled things out slowly. It seems slowly to us, but it's actually not taken that long.

There is not a deployment. It's literally they give you access. They go, "Your licenses are ready," and you login. That's it, then you start using the tool.

The planning phase for me was a year long project, getting everyone on the system and all the data migrated. Initially, it was about creating a need, because no one knew they needed a new tool until someone looked into it. I identified the need and problem, did the analysis, made the recommendations, presented the options, made the recommendations, and collected the requirements. There were a lot of requirements. Then, I went out and engaged with our InfoSec Department and our procurement process. I officially got sponsorship from the directors in about March for the project who saw it and put some money aside to be able to do it. It was a fairly smooth process from start to finish, but it was hard for me because initially there was no need for it. I created the need for it, then from that point on, it was a very smooth process.

I was the single person driving that process, but then it was a member of staff from procurement. I touched base with multiple areas of the business that would have been using it to gather requirements, so nine scrum masters for half an hour each. Architects were all advisory. Contract specialists/managers to do the contracts. We had our legal team. I was the single resource that drove the process, created the documentation, and found the supplies.

I am the person now maintaining the system. It shouldn't take more than me, but it probably won't be me forever. The only reason it requires maintenance at the moment is because of misuse, so it's not like things go wrong with it all the time. It's more of a case of that it's self-sufficient and I can go through and review the work that people do, ensuring they are using the tool and populating it as we would like them to, thus we can get quality data out of it. 

We purchased it via a supplier. Octane is being supplied by EOH Europe for us. I have worked with them in the past. They were happy to put us in touch with Micro Focus. We already have a couple of other tools through EOH, so we already had an existing relationship with them.

Working with EOH Europe was fantastic. My contact at EOH was very helpful. He has always been there to help with the multiple questions that I ask all the time about various different things, not necessarily related to Octane, but about anything that they supply us.

My biggest challenge as the integrator has been about changing culture. The tool does what it does. That is all. It has received a very positive reception by the majority of the people that use it. 

Changing the culture means improving the way that we do things, our processes, and the way that we do this is by having communities. We have a community to address concerns, misunderstandings, and conversation points that people bring, then we try and improve the practices that we do by trying to get everyone aligned to the same practices.

It's a bit early on to see improvements in times and deliveries. Our entire company has only been using the product since December of last year, so we don't have enough trend data.

We will see ROI once we have the automation suite connected up to Octane. We will then have the ability to report on automated testing versus manual testing and the ability to see those tests automatically parsing with the tool. When Octane shows us when our CI process fails and shows us what the story that failed, we will have return on investment. Because we will have not the overhead of having to do an investigation of having to find out what the change was, because Octane will tell us all of that information. 

For what it does, it's very reasonably priced. I like the licensing model as well, because it's very flexible. You can scale licenses up and down for short periods of time. 

In terms of pricing, it's comparable to what we had previously. It's not priced at the higher end of the scale by any means. It's priced nicely, in the middle of the market. For what you're getting, it's a very good tool.

It went through official procurement process where we went out to tender with seven different suppliers. We had responses from five of those suppliers. We had demos from five of those suppliers. We followed three more through, then we eventually selected Micro Focus ALM Octane. At which point, we started demoing Octane and ran it through 2018 whilst we were doing contract negotiations and signing contracts, which was probably the single hardest part of the entire thing. 

Four of the seven vendors that we looked at were Micro Focus, CA Agile (incumbent), VersionOne, and Jama. 

We went with ALM Octane because of its functionality and it is presented very cleanly and simply. You are never more than three clicks away from where you need to be in Octane. Another reason that we went for ALM Octane as a tool is because of our relationship with Micro Focus as a company.

ALM Octane has a cleaner version than VersionOne, which is a little busier.

If you're looking for a tool which will complement a CI or DevOps process, where you want to have a single point of visibility or a single version of the truth, and see all of the stuff that happens through that journey, Octane is the tool which will to give you that.

The biggest lessons learned: When you start focusing on a new tool that prides itself on having a very tight process to make things visible, you learn how other people don't necessarily follow its processes as tightly as you would expect them to.

Using the SAFe framework helps our workflow patterns. We have been using SAFe for about four to five years, and we've actually been using it properly for maybe two and a half to three years. We're still not perfect by any means, but we are definitely pushing forward in the right direction to become more focused on delivering the true version of that methodology. Although ALM Octane doesn't do every element of that methodology yet, they are endeavoring to clean up a lot of those areas. They are trying to mop of some of the methodology that SAFe works on adding in things. We have seen quite a lot of new features recently that have been specifically focused towards SAFe, which has been really positive for us.

ALM Octane has improved our use of agile, but we still do some waterfall stuff. We will always carry on doing some Waterfall stuff until certain systems fall out of use because we have old systems and those old systems don't lend themselves to agile.

ALM Octane has presented us the opportunity to push forward with a true CI/CD approach, which is where we want to get to. 

Our primary use case is using it as a single application lifecycle management tool, meaning all the way from our original planning, requirements, doing backlog management, user stories, test lifecycle management, defects, in a single tool. We consolidated. In the past, we used more than one tool. Our ultimate goal is to have this as our global standard. Our primary use case was to move away from other tools and standardize on Octane.

Coming from an HPE Quality Center/HPE ALM background, in the company, I think Micro Focus has done a great job in redesigning the overall user experience. We've seen a big increase in the adoption of the tool itself. The amount of time we spend on training, in general, has definitely come down. People find it very intuitive.

The real value is that we're able to standardize, and project teams are more vested in, or interested in, actually doing their standard activities in the tool itself. The value is in the adoption, that people are willing to use it for the purpose for which it was put in.

We have gained some efficiencies. We had a challenge in standardizing our tools. Sometimes activities were tracked within the central depository, sometimes they were outside, on multiple tools. Standardizing on a single tool, and standardizing our process brings us value. It is definitely saving us some time because it's very simple from a user perspective and it's more efficient.

We did an extensive market scan and evaluation before settling on Octane, even though we've been an HPE customer and Micro Focus customer for many years. When we wanted to get into Agile planning tools, we looked at all the market-leading tools, but we did not find anything quite as comprehensive as ALM Octane. When I say comprehensive, it's not just a single tool for Agile planning, backlog management release, sprint planning, etc., but it also has a built-in, comprehensive quality management module. It also has pipelines where we can hook up with our DevOps ecosystem/toolchain.

The real power of this tool is how comprehensive it is, the breadth of what it covers.

To the credit of Micro Focus, we are very actively working with their product management team and the R&D team as well. When we looked at this tool, inevitably we draw comparisons to, or parallels with, the HP ALM or the legacy ALM tool.

From that perspective there are some features that we find are missing, probably for a valid reason: Because it's a next-generation tool, some of the legacy stuff has been removed, and it has a newly designed user-experience. But that being said, there is an opportunity to do a little more with the dashboarding. We still feel that HPE Quality Center/HPE ALM reporting is very powerful. We talked with R&D, and there are some things on their roadmap, but at the same time, their strategy is to connect Octane with visualization tools such as Power BI.

Our perspective of the drawbacks or the limitations comes from drawing comparisons with HPE ALM. Some of those limitations are probably by design and for a reason. That being said, the product management and R&D teams are working very closely with us and we are giving them a lot of enhancement requests.

We have not encountered any stability issues with it yet. We have an on-premise ALM Octane, it's not a SaaS version. We host our own hardware. We did the implementation by ourselves. So far, the application is fairly stable.

The usage is going up pretty fast. There will probably come a point where we need to scale. The new architecture for Octane is quite different than HPE ALM. It allows us to scale. We're not quite there yet.

We have over 3,000 users, about 85 concurrent. It's a globally active application. It goes around the clock. We have North America, Europe, Asia-Pacific, and Latin America.

The tech support is pretty solid. I've never had any problems. We start with the tech support and, if it's very technical, it sometimes goes beyond them all the way up to the R&D team. 

Overall, the support experience has been excellent. The reason I say this is that they bring all the possible resources and people to the table, all the way up to R&D, which is the top team from a support perspective. Support is not even that team's primary role, but they still get involved to help us out. They've been outstanding. I'm very pleased.

We have a customer-success manager allocated to us who is constantly trying to understand where they can help us. With Octane, we've seen a great deal of engagement at all levels of the support team. They are going the extra mile to help us and support us.

I also really love how they have enhanced their online help, how comprehensive and user-friendly it is. They give standard examples. The help refreshes with every release, it's very dynamic. That has been a pleasant surprise.

We were using HPE Quality Center, which was sort of a predecessor. We are currently moving out of Quality Center and completely standardizing on Octane. We also briefly used CA Agile Central and JIRA, in small pockets. We decommissioned them, and Octane became our standard tool across the Enterprise.

We started with the goal of having one tool across the enterprise. Octane met most of our requirements. We did not want to have two different tools for Agile and Waterfall and then have to start integrating them and managing two applications and the training on them, etc. Our primary position was to standardize on one application and we decided Octane was going to be it. Then we slowly planned and moved everything out of Quality Center into Octane.

I don't want to call it complex, but it was different. The initial setup felt a little complex just because it's a different architecture, and we were also doing it on-prem. If it's a SaaS, obviously, you don't even have to worry about setting it up.

One thing we have noticed, since we have done two upgrades, and we're getting ready for the third one, is that the upgrades have been so simple and easy. In the previous legacy platform, upgrading was a project for us. There was a lot of planning, a lot of people were involved, and there was a lot of downtime. 

For Octane, we get quarterly upgrades and we lag for a couple of weeks and then start upgrading our environment. That's been a huge difference. That way, we are not staying on an older version for many months or even years. We just upgrade as soon as the versions are available from Micro Focus.

We looked at six tools as part of our evaluation, when we were looking for an Agile ALM tool. We looked at CA Agile Central, VersionOne, JIRA, TFS, Agile Manager, and Octane.

We did have very extensive requirements and they scored very closely. JIRA was our number two, Agile Central was number three, and VersionOne was our number four. Agile Central scored more, the highest, but Micro Focus allowed us to share licensing between HPE Quality Center and Octane. That was the primary reason it was a no-brainer for us to get started with Octane. Apart from our hardware and implementation costs, there were zero costs to begin with.

Most of the other tools that we evaluated were very comparable. You could pick any of those tools on any day. But for our use cases, for our specific needs, and the costs and scoring, we zeroed in on Octane.

A lot of people, when they pick up this tool, are focused on one specific aspect of it, like Agile planning. They're doing backlog management, release planning, sprint planning, etc. But I would suggest looking at the broader, end-to-end application lifecycle management tools, which includes hooking up into your Dev tools, integrating it into your quality lifecycle, and the pipeline module. That's especially true if your company is an Agile shop and you're doing a lot of automation. In that case, you need to look into Octane and really understand what it offers. I think a lot of people probably don't appreciate or don't understand, they're not aware. Keep that bigger picture, the end-to-end lifecycle, in mind and see if there's any other tool that fits like Octane.

I would rate it at eight out of ten, which is still a high score for me. It is still truly evolving. I work with Micro Focus and, looking at the product roadmap, there are a lot of good features coming.

We use ALM Octane for lifecycle management and for testing.

The most valuable feature is the test lab. For example, we use it for both mobile testing and browser testing.

The interface is user-friendly. 

I would like to see the mobile testing improved so that we can simply select a mobile device, then specify what parameters we want, and the testing will be run based on that. This feature would be a very good addition.

I have been using ALM Octane for about eight and a half years.

We have not had any challenges in terms of stability.

This is a scalable product. We have more than 50 users in our company. Some of them are Q&A while others use a different license for development. We will very likely increase our usage in the future.

The technical support is really good. They have a support portal, which is helpful.

The initial setup was not complex. It was very good for us.

We have two people who are responsible for maintenance.

The look and feel of this product have improved over previous versions.

I would rate this solution an eight out of ten.

View the comparison document and quality of the document for informational and sharing purposes.

Octane creates a gentle approach to Agile-based projects.

The most valuable feature is CI/CD integration, and it is a good fit into the Agile lifecycle.

Improvements could be made by way of additional integrations across the lifecycle.

What we're doing is a cloud migration program. We're migrating about 70 applications from on-premise centers to the Amazon Cloud. That migration is primarily using Octane to store manual test cases and for a manual backlog of user storage to migrate each application. We're also using Octane to record the results of automated testing and performance testing.

The integration points are very good. Octane gives us a window not only into our manual testing, but also our automation testing and our performance testing. We can see all results from all three streams of testing in one place. We've never done that before, until this past year. Whether that was possible with Quality Center or ALM.NET, I really don't know, but it's the first time we've ever done this. So the fact that it gives us that window into all phases of testing is where it's a bonus for us.

The whole thing is geared towards Agile deliveries. It certainly has a good GUI, it's good to look at. The features provide good impact. It lends itself very well to Agile deliveries.

So far the stability has been okay. The stability is: Is the server up and running? In the last year we lost access, maybe once, for a couple of hours. Because it's a SaaS product, we don't know why it came down. We just know that it became unavailable to us. But on the whole, it's been pretty stable. We're not intense users just yet. We will be. In six months' time, we won't be able to afford any downtime really. But we're not an intense user right at this moment.

We may have not noticed when it wasn't available. But in six months' time, that story will change. Obviously, as part of our DevOps pipeline, we will really expect it to be up 99.9999 percent of the time.

In that one occurrence, they reacted quite quickly. We raised a ticket and then had an instant response. They said, "We're looking at it." I can't remember what the actual resolution was. I find Micro Focus quite reactive to issues.

I think it would scale. We've not needed to scale too much yet, but it seems scalable to me.

I think that the biggest obstacle to scaling with this particular tool is the licensing. You predict what licensing you need for the year, a whole year, and you're stuck with that for that year, unless you pay more to scale up. That's always a challenge. The challenge is not the scalability of the solution but the scalability of licenses.

We've just upped our licenses to 25. We started off with ten. Once we get to steady state, in some six months' time, we'll have about 30 steady-state silences.

Regarding the increase in usage, we'll push more work through it. Right at this moment it's just one program of work. Once we're happy with the way we use it, the stability, we'll then push all our organization's work through Octane, rather than ALM.NET. At the moment, the majority of our work is going through ALM.NET. It's just this transformation program that I mentioned where we're using Octane. It's almost a proof of concept for us. If it works with that program, we'll make it work for all programs.

Tech support is okay. So far our experience with them has been positive. They're certainly quite quick to react to the initial issue. Because they've got this "follow-the-clock, follow-the-sun" support model, there have been times when we have raised a ticket and has gone over to a resolving group in South America, and there has seemed to be a time lag in getting our updates. That can be a problem but, because we're not an intensive user yet, I'm not sure if that would manifest itself a major problem.

The initial response seems to be good, but sometimes the follow-up is not quite as quick as you'd like it to be.

When we've asked for details, we've received details. They don't seem to hold too much back. When we've pushed them for detail, we've gotten it.

We were working with Micro Focus on our cloud transformation program. We included them and a lot of vendors, but we had identified the Micro Focus set of tools as the tools we should be using for our DevOps pipeline. That was made through a process of evaluation of other tools. At that point, we engaged Micro Focus and said, "Look, this is what we want to do. How can you help us?" At that time, Octane was just coming off the production line and they said, "Well, we've got this new product which might work better for you." They made that product available to us. So we looked at it at that the suggestion of Micro Focus, given that this new product was coming out.

We'd always had what used to be HPE before it was Micro Focus, so we'd always used the variations of HPE testing tools, ALM.NET and, prior to that, Quality Center. We did some research with industry reviews and, obviously, the Micro Focus set of tools were in the top quadrant. Because we had the relationship anyway with Micro Focus we decided to stick with that toolset.

It was a natural progression, plus the fact that the review sites had the set of tools in the top quarter for being the most integrated set of test tools. We were looking beyond test management tools. We were looking at automation and performance, and the recommendation from those sites was that Micro Focus had the richest set of integrated test tooling. That led our thinking quite a lot.

I thought the initial setup was pretty straightforward for us. We started off with ALM.NET on-premise. We then took the SaaS offering. So our initial challenge was to migrate our existing ALM.NET projects into the SaaS product. We then were made aware of Octane, which was made available to us quite easily, and we were able to start using it.

What we didn't do, because of various challenges with our program, was we didn't really get too involved early because we weren't ready. So although the tool was ready, we weren't ready to consume it. But in the last few months, we've made quite a few strides with that. We're now at the stage where we need to say, "What more can give this give us?" There's a lot we can do. What is it we want to do? That's probably where we are now.

Our implementations strategy for Octane was quite simple. Because we've got this program of work, which is a cloud transformation program, we used that program as a proof of concept with Octane. That program worked, which is lifting and shifting 70 business applications. They are being migrated from on-premise to cloud, and each one of those migrations, on an application-by-application basis, is being managed by Octane. So our implementation strategy was to use it for this program of work. Once we realized the good and the bad, we could then start implementing it across the rest of the organization.

The staff from our side required for deployment was none. For us, it was just a request to Micro Focus and then agreeing to pay for licensing. It's a URL, basically.

For administration within our organization, the overhead is that there are several admin tasks, such as creating new backlogs, creating users, and administering users. It's no more of an overhead than with any other test management tool. The admin side is still the same. You have to set up your folder structures, you have to set up the users, you have to disable users when they leave the organization. It's simplistic and it's quite easy.

Here, because we're quite a small organization, we've got three people with admin rights, and between them they handle requests as they come through. We've got a site admin and a project admin. It's a layered type of admin, as much as it was in the previous products. The site admin can do everything and project admin can do everything within that project.

The product was there for us. As soon as we requested it, it was made available, so there was no implementation, as such, for the product. It was down to us to make use of it, and start creating our backlogs, and our structures, etc.

We relied on the help we get from Micro Focus. There are some good online video tutorials from Micro Focus. We made use of those. We made use of Help topics on the product. Other than that, for any issues, we would raise a ticket with Micro Focus. We didn't actually take on formal consultancy.

I don't think we've reached the point of ROI yet. For return on investment, we're looking at about 12 to 18 months before we start seeing that return. Our return will come when we automate more testing, when we show those results in Octane, and start making more use of the Octane dashboard. That's when we'll see a return on investment.

It's expensive. HPE products, and now Micro Focus, have always been expensive. The license is not cheap, and it will always be a challenge, particularly for small organizations like ours.

It's a good product. You need to consider the cost of it. We didn't do too much comparison against other tools, but I always felt that this product didn't only give you a project view, it gave you a program view as well, which some of the other tools don't. With this tool, you've got a program. You can see multiple programs. If you set up your dashboards correctly, you can get a much wider organizational view. That's where we need to play a bit more with it, to get more out of that capability.

I would advise others to consider the expense, maybe look at other tools, to see if they can do what they want to do cheaper. For us, we felt it was worth the investment.

I don't think we're quite mature enough yet to be able to say that it has improved our workflow. Where we are now, we've proved the integration points, we know how we can use the tool, we know how it can benefit us. But what we haven't done is actually reaped the benefits of that just yet. But in six months' time, we'll see improvements to our workflows and we'll be making more use of the tool for that aspect. We're quite immature in our journey at the moment. Although we've had the tool for a year, we haven't started to use it in anger until the last few months, where we've input all those integration points. Now we've got a set of integrations where we can do exactly what we want to do and now we need to decide how best to use that to improve our workflow, etc.

We're introducing an automated pipeline. Our end-to-end DevOps pipeline starts with ServiceNow, where we will request an environment. That request will be picked up by Jenkins, go off to the Amazon cloud, and stand up that environment. Jenkins will then orchestrate a set of automated tests, using UFT, to make sure that environment is working, and it will pass results back to Octane. At that point, a notification goes back into ServiceNow to tell the requester that, "Your environment is available, and it's been delivered." That's the kind of pipeline we're delivering for each application that we might write. In theory, we'll automate as much of that pipeline as possible. We are on that DevOps journey. It's still a work in progress for us.

Regarding the biggest lessons learned so far from adapting tools and processes for Agile and DevOps, I think it's the culture, spreading the culture within your organization. Some people don't like change, they don't like new ways of working. So the cultural issue, the people issue, is a challenge. 

When it comes down to tools and technology, it's the integration points; doing some proofs of concepts to prove each integration point works and finding out where your limitations are. We found some limitations in what we want to do on the Amazon cloud, which we weren't prepared for. The lessons learned for me are: We should've done many, many proofs of concept, small proofs of concept, to prove each point of integration, and then bring all those small proofs of concept together. If I was to do this again, that's exactly what I would do: small proofs of concepts before trying to build anything in an end-to-end fashion.

In terms of how Application Lifestyle Management Tools can help with the transition from Waterfall to Agile, Octane was created very much with that Agile focus. It gives you that set of tools to create the environment, to create your backlog, to create your sprint, and to give cadence to that and give a reporting view of where you are at. Also, it's not just at the project level, you can do it at the program level. We need to start looking at things from a program level, and how we can expand out. It's the views it's giving you, and the tooling that it's giving you that fully support that Agile-type delivery. We've made it work for a Waterfall-type delivery as well. It's giving you everything you need, for whatever delivery you want: the project view and the program view.