We knew we needed to go with Octane for a couple of reasons. From the business side, there were some requests which ALM could not cover, in terms of data storage, etc. Since we have so many test cases, and given how versioning and base-lining work in ALM, it would require so much storage that we were not using the versioning in ALM. This was one of the biggest pain points from an ISO perspective in terms of testing. Also, operation maintenance was hard. We were running the biggest ALM.NET instance in the world, according to OpenText. We had the most users, the most data, and the most complex VBA workflow code in a single instance of ALM. This needed to be migrated smoothly to Octane.

In addition, Internet Explorer, which is not the finest tool, was removed from our company's IT at the beginning of 2020. There were a lot of smaller reasons which lead to the need to change to a different tool, to a more flexible tool, to a more powerful tool. For example, the Autonomous Driving guys were going to be adding tons of test cases and automated tests, which would cause ALM, in the configuration we were in, to crash in the future. That was clear, and it was clear to our management as well. We only had a small time window to change to a different system.

My clients were using ALM, the predecessor, and due to the cost-effective migration and technical capabilities to leverage an agile framework application solution, Octane was the right choice.

I have experience with different tools, especially Microsoft. I have experience with different tools, especially Microsoft. My company switched to OpenText ALM Octane from Microsoft as it is considered to be a single solution for every use case.

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.

We used HP ALM Quality Center. We switched to Octane because it's a more modern platform. It runs on full browsers and all OSes. So, it makes sense to use it. 

I have used Jira previously.

We only used Micro Focus ALM Octane.

I'm not sure what other tools we used before using Micro Focus ALM Octane, because we've been using it for a long, long time.

We used HPE Micro Focus ALM Quality Center for a significant amount of time. From a competitive point of view, no comprehensive tools could cover ALM functionalities better than HPE and OpenText. Almost 80% of enterprise companies use OpenText as a well-integrated solution. It doesn't require the technical expertise required to work with open-source tools. Also, it provides good support services.

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.

I work with QA Testing Tools from Tricentis and Rally by Broadcom. A competition to Micro Focus ALM Octane would be Jira and Visor's combination.

The way we brought it in is that we have a Flex agreement with Micro Focus for a large list of products. Because we had ALM, Octane was included. If I have 200 licenses of ALM, I have the equal amount of Octane. If use one, I get the other.

We have used Jira previously.

So before July, we were using IBM DOORS Next Generation for business requirements.  Then we decided to consolidate the business requirements, testing, and defect management into one system, and Octane provided that solution for us. So we were able to decommission IBM DOORS Next Generation for business requirements after our July implementation to ALM Octane.

We looked at Micro Focus ALM minus the Octane solution about two years before they decided to go with DOORS Next Generation. And they selected DOORS Next Generation, but IBM's integration with Micro Focus wasn't very mature. So it required a lot of manual tinkering to get the two systems to talk together. Finally, after some analysis about how much time was being spent, staffing resources, etc., we just went with ALM Octane.

I wasn't really looking proactively for a new solution at that time, two or three years ago. We were aware of the limitations that ALM.NET has, that's it's too rigid, too complicated, and the user interface is not too user-friendly. There was an announcement from Micro Focus, that they were going to release a new tool that would be the next generation of ALM. That was the first time that I heard about this software.

In the past, we had ALM Quality Center to manage our waterfall deliveries. Once the company took the decision to do the transformation to agile, we needed a tool that could support both waterfall and agile, but not compromise functionality. This was a key factor why we took on ALM Octane. We knew that the transition to agile would not happen overnight and that we might be in the hybrid model for a while, which is the exact reason why we took on ALM Octane.

It is very much integratable. This was a piece that was critical for us because ALM Quality Center was used by our company for more than 10 years, and it was very easy to integrate. Before we could migrate to ALM Octane, we needed the integration to be in place for a new tool. There are different ways to integrate, through the REST API, plugins, or the MF Connect tool, which also comes with ALM Octane.

Because we were coming from a very old Quality Center version, we have become more efficient because the work can be done faster.

We have ALM implemented and we're still using AGM. We are making the switch to Octane because we implemented AGM with integration to ALM so that we could have Agile project management and a manual testing tool for our project teams. The nice thing about Octane is that it doesn't require integration. Integration always introduces a potential for points of failure. If you can house those capabilities within a single tool, why not go in that direction? It provides ease of use, less maintenance, etc.

Also, this is the direction the vendor is going in. Several years ago, our organization made the decision to go with HPE, now Micro Focus, for the majority of our suite of enterprise tools. We're following the direction that the vendor is going, but also recognizing that there are advantages to the tool that has good capabilities. We're not blindly following them, we're doing our assessments and saying, "Hey, this looks like a good thing for us." Of course, if it requires fewer tools, less maintenance, less setup, we'll go in that direction. That's how we made the decision to go with Octane.

There are other things that we haven't deployed yet, but the advantages of the direction they're going in for integration into the DevOps world to support CI and CD, that's a direction we want to go in. I'm on the Agile solution team, but we have the testing solution team, so they're very interested in those types of capabilities as well. Octane is opening that door for us to get more and more functionality hubbed in a single tool.

Octane was brought in to be the standard SDLC platform in concert with QC. We replaced VersionOne, Jira, and several in-house solutions since I've been with the company.

We switched from Jira. The main reasons that we switched to Octane:

1. Provides a single tool.
2. A lot smoother user experience.

We did an upgrade of our ALM from Quality Center.

We figured out that with our BDD approach, and what we planned with more modern technologies, and our shift-left approach, that ALM didn't fit. There was no chance to implement any Agile approach in ALM. We started to think about what else could be useful. It was pretty obvious that Octane was the right tool.

In ALM you do not have any flexibility to model the processes, to say how you would like to see new things like quality stories. With Octane you can add pipelines, and with the API you can add other tools and, therefore, other processes. All of that is not available in ALM. In ALM, you have a closed system and you have to live with what is given, while in Octane, you have the chance to add new stuff to the tool, like reports from outside, etc.

We used Agile Manager and it does not have the testing capabilities. We really needed that. We also need the business rules, we needed some of the workflow that's not in Agile Manager. We needed an Agile solution that had a lot of the same capabilities and business rules that ALM has.

We didn't see that coming in the Agile Manager, so as soon as Octane came out, we jumped on it.

In choosing a vendor what's important is communication. Show up. Talk with us. Build that relationship and then we'll talk product.

Our previous solution, ALM QC, was outdated. Our company started our Agile journey and we needed to be able to support that journey and the Waterfall journey as well. Octane offered this hybrid model which was the clear selling point for it.

The native support for Waterfall and Agile software development was very important in our decision to go with the solution because we knew that Waterfall and Agile will co-exist for quite some time, and the tool had to be able to manage both in parallel. Also, for the future, it will still support what we want. If the shift goes more to Agile and less to Waterfall, the tool still has to support both of the methodologies.

We were using the Quality Center Solution from HPE before and, in that solution, we had no way to handle Agile projects. That's one of the reasons we decided to move to Octane, which includes an Agile management system with the test management system and requirements management system that are available in Quality Center. Octane has more features than QC, especially for Agile methodology. It also has all the features to connect with the Continuous Integration tools, and that's very important when moving to DevOps.

Quality Center is totally obsolete today and Octane has all the new features we did need like Agile management, full web GUI, and connection to the Continuous Integration systems, as well as many others.

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.

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.

I'd gone to the Discover Conference in the summer, and saw them talk about Octane. And they presented it right at the moment that we were really looking for something. Half of our group that do the testing are on Macs, and were having to go through the Citrix clients to get into HPE QC. Everything they said just hit right on what we were trying to do with DevOps, and the fact that they developed it using DevOps principles, and they "drank the Kool-Aid" that they're trying to sell the product to be used for, was very compelling to us.

I used many solutions in the past... I will keep using Octane