OpenText Software Delivery Management Reviews

Octane is a relatively new solution for us. We needed better tooling than we previously had and Octane gave us extra flexibility. Our primary use case is for cross-project program reporting and dashboards. We are customers of Micro Focus and I'm a company director. 

The dashboards and metric reporting are valuable features for us. From a development perspective, we use Jira and Zephyr. To stay agile, we need to ensure that our Jira data is feeding into our ALM projects. It's about the real-time integration between the two and bringing that information across accurately. 

I haven't been impressed with the reporting from a requirements matrix and a traceability perspective. ALM has always lacked in this area. They come at it more from a Waterfall testing perspective, and less from a Sprint-based perspective. It's in those areas that we use Jira with some of our development teams. We ran into roadblocks due to the sheer number of users, around 1,500 people using the tool, carrying out testing, and ensuring that people understand the requirements.

I think they need to look at ways of innovating and finding the wow factor with more flexibility and agility in development, but they've never really been good at handling that which is why we stick with Jira. There hasn't been much investment in the tool and there are definitely some areas that can be improved upon.

I've been using this solution for about six months. 

The stability is fine and they give you the capability that you need to run a good quality engineering program. It's what they've been providing more or less for at least 20 years; perhaps it's time for some innovation.  

There's no problem with scalability. 

We don't deal directly with Micro Focus but with one of their support teams through another vendor. We've never had an issue. 

ALM is a little pricier than Zephyr Enterprise. Because of our familiarity with ALM and the fact that we had all the integrations, it was easier to resume using it. 

We compared Zephyr Enterprise with ALM and decided to go with ALM because we have another provider that already had integration with ALM. If we'd gone with Zephyr, it would have required some technical integrations with their APIs and some of our testing tools. From a capability perspective, the two solutions are pretty on par with one another. If an organization is evaluating capabilities versus investment, then they might prefer Zephyr.

I rate this solution eight out of 10. 

We are using ALM Octane for electronic component testing and validation. We have a few departments where they are developing their software and using JIRA projects and exchanging results with Octane. 

About 80 percent of the users are not in software development itself, but are in software testing. The software is developed by external companies and we are just doing the integration testing. We are putting the components together from five different suppliers, and then doing the integration testing. Is the software working in real life, together, from the different control units of different vendors? It is a staged process. We check if things are working in the different parts of the system, like the engine components, drive train, navigation, and infotainment systems. If things are working in those different areas, we put everything together and test it in a complete car.

As a result, we have lots of test cases. We have automated tests and a test automation tool that is controlling complete car-wrecks and the like. So it's not only a mouse pointer on a screen. It's controlling robots opening and closing doors, for example. 

Our main focus is efficient planning of tests. We cannot run all the tests we have every single week, because lots of the stuff has different variants for Europe and the U.S. and China. So we have to have very sophisticated test planning. A lot of attributes are needed for this and for all the runs, whether manual or automated. We have what we call a very large problem management process to work on the defects with the 100-plus suppliers that are delivering different control units and, therefore, software packages.

We use Octane's Backlog and Team Backlog capabilities a lot. For example, we use them for errors that occur in software that we are not developing ourselves, where we are just doing the integration testing. In such cases we are using user stories to order teams to test a certain number of test suites or test cases. We can use it straight away, out-of-the-box, without breaking or adding something to the tool. Using Team Backlogs means our teams can use all the features that come with Octane, for our benefit, without doing anything else. In the past, if you compare it to the old ALM solution, lots of teams had to store their tests and results in ALM.Net and use JIRA as a parallel system. They were manually copying and pasting links into both tools to control their workloads. Users were used to working with user stories as a work order, and that is now integrated in one tool, which is a huge benefit.

It has also reduced our testing costs. I don't have the numbers, but we're speeding up a lot. Just the waiting time we had with the old ALM when logging in was about one minute. If you multiply this by 5,000 users who are logging in on a single day you can calculate very large savings, very fast.

The key feature is the usability. It is fast to learn and easy to use. It's very intuitive to work with. Most of the important functions are available via a few clicks, compared to other tools where I have to open a sub-menu and then a sub-menu and another sub-menu, and then press a button.

The native support for Waterfall, Hybrid, and Agile software development at enterprise scale was one of the reasons why we changed to Octane. In the development process we're creating the requirement specifications which are then handed out to a supplier, including Bosch, Continental, Alpine, etc. They then develop control units with software and we have to link our tests against those requirements to check if everything is implemented. This is a very important task. It's required by law. For example, for autonomous driving, we have to prove that the car is not, by default, running into trees. We are proving that by test cases that are passed. While that is still Waterfall, it's not Agile, we are using the Agile methodologies more and more to control our workload. For example, we are using a user story in test management to order teams to test a certain number of test cases.

In terms of integrations to proprietary, third-party, and open-source tools out-of-the-box, it has a very powerful REST interface. We can interact with other tools. OpenText also offers synchronization tools, OpenText Connect Core, which has out-of-the-box interfaces to industry standards tools. For everything else, you can use the powerful REST interface, which is both good and bad. It's good for creating an interface but sometimes our engineers use the REST interface to do things they should not do. But that's because engineers are always doing fancy stuff.

The elements in filtering need to be improved, meaning the number of filters I can use in widgets or in the grid views in parallel. There's a limitation which bothers a lot of our users. Filtering in text, or having a complex filter is limited. In a given field, for example, I can use a filter only once. I cannot say, "Include the values 1, 2, and 3, and exclude value 17." This is not possible but we have requested it often.

And in general, widgets should be more flexible and more sophisticated, with the ability to layer two different widgets. There is also room for improvement in the amount of test cases which are available for certain filter conditions and a given widget, versus what was worked off already.

Also, when it comes to getting reports out of it, and maybe this is a little bit specific to the automotive industry, there are certain requirements by law where we have to export the test results for the final software delivery and create PDF reports which are stored for 15 or 20 years. Creating reports in PDF, or PowerPoint which then become PDF at the end of the day, is something which could be improved a lot. We're working on it with OpenText in every single release as new features are added.

We have been using ALM Octane on a production scale since the middle of 2018. We started digging into the different tools about one and a half years prior. At that point our idea was to change from ALM to whatever other tool. We decided to go with Octane in early or mid 2017.

We are trying to use the latest and greatest version. We are now updating to 15.0.60, the so-called "Beatles" release, because of one technical issue that we solved together with OpenText. But in two to three months we will be on the latest and greatest "Depeche Mode" version which will be 15.1.40.

It's stable, out-of-the-box, with very few errors. And if we get an error message, very often it's because of the complex rules we have implemented, ourselves, in Octane. But in general, the usage of Octane is very good, the quality is very high, with very few errors and bugs, and with high reliability even on a large scale. We are close to being the largest Octane instance for OpenText.

The scalability is pretty good. We did some load tests in advance, before making the decision, pro or con, on Octane. With Octane we are in a very good position. We expected to have some 5,000 users by the end of 2019/beginning of 2020 working on Octane. I believe it can go up to 2,000 users working in parallel. We hope to be powerful enough, with the architecture and everything else we set up, to meet users' expectations of performance.

We are involved in further step-by-step expansion of our use of Octane. For this year, we are planning to extend the native Octane usage of test automation, the DevOps module. We are introducing it and maybe we will be able to replace some home-grown and other tools and to integrate them into Octane to have the benefit of Octane. It would be helpful to have everything in one place for the monitoring and reporting possibilities. Our processes and needs are changing from time to time, and this is always reflected in the test management tool.

I'm very proud of the opportunity that OpenText offered to our team, to be something of a design partner. We have a very strong relationship with R&D and are able to discuss user wishes and our needs directly with them. They listen very carefully and try to deliver solutions for our problems and enhancement requests. It is amazing to see how fast and how stably things come together, even if some users are complaining because their single feature request has been open for two years. But that's because we have more important ones. It's an awesome relationship.

You also have to take into consideration that Octane has become an industry standard. Lots of different companies are using it. From that point of view, you get to know how complex the work is for OpenText, and how valuable a good relationship is. I'm very thankful for being part of this kind of working together and improving the tool.

And it has often turned out that our requests and wishes have had a huge benefit for other customers.

The benefit of this design partnership, which is unique, is a plus for us. We are able to influence the tool and get features, especially within the timeline that we need them. That's one of the biggest advantages.

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.

For us, it was a very complex setup. It was not only setting up a server, installing Octane, and doing configurations. Our plan was to have a shared Workspace concept with six or seven Workspaces. We did have a major challenge in doing all the configuration stuff, defining methods and processes. We also had to connect at least ten major tools or databases, which are synchronizing information into Octane, or which are used for the special methods of test planning and test automation; pulling information from Octane and running them on our test benches in semi-automated cars.

That was a very complex process.  There were some small problems and some bigger problems but we found solutions for all of them.

Because we have some 70 to 80 suppliers that are part of an automated defects exchange, our development, our testers, are reporting defects and those defects are exchanged with those 70 to 80 suppliers. So it's a very complex situation we are in.

Of course, users have to learn different things compared to ALM.Net, the old version of the tool. But we're getting good feedback from the users that as soon as they are used to the idea that they have to use a different tool, they are learning how to use it very fast.  There are fewer obstacles in the tool, in this regard, compared to others. Even if you're a JIRA user, you have to overcome that, "I have to use a different tool" issue. There are people who are doing this very easily and with a smile, while some are just trying to stick to the known tools. But that's the change process.

For deployment and maintenance of the tool, there was a major team of experienced IT guys and process guys from our side, about 25 people, supported by about 60 other people just for the special processes of the different development departments. We call them "key users." They are collecting information and reporting it to the core team. For maintenance, it's a team of six people who are implementing changes requested by the core team. Depending on the workload, on average, maintenance is done by three people. There were numerous software developers working on the interface tools, perhaps some 30 IT guys working on the different tools we needed to launch with Octane.

I was not part of the cost negotiations. But the purchasing guys confirmed that OpenText offered the best pricing to us.

We started analyzing which tool we should use for the future a few years ago, and we started digging into Octane very early. 

Options we considered included JIRA, which is used by a lot of small teams. There is a standard toolchain around but with the amount of data and information we need to run, JIRA was very easy to strike from the list. We dug into IBM and PTC Integrity. We looked into ALM Octane vs codeBeamer ALM from Intland. We did some comparisons but ended up with Octane.

With JIRA and the toolchain, you cannot run a business like ours, doing car development, using a lot of plugins to get the needed functionality in one tool. You have so many small companies providing those plugins. What if the company providing one of the tools or plugins you're using collapses or doesn't support a new JIRA version? So this was not an option.

PTC is also using different tools to support the full functionality of requirements, test cases, team management, the backlogs, tests and defects, and so on.

codeBeamer was on the short-list and was the biggest competitor to Octane. But from our perspective, Octane did much better in performance. Octane is not able to do as many relations between the data objects as codeBeamer, but performance was the key factor for us. When you compare Octane to codeBeamer ALM, the UX concept is very good. What's also very important is to have good capabilities for getting reports about the system out of Octane in real time. The reporting engine, the widgets, and the dashboards are a huge plus.

This is still an area where we have lots of feature requests at OpenText to enhance things even further. We would like it to be more flexible for the users. We have lots of user-defined fields and lists so users are requesting more capabilities for enhancing this area or would like the possibility of filtering their work items.

We were setting the foundation for the next eight to ten years. We had to have that in mind, as well as the increase in data, the increase in users, the increase in data objects and rules, and the complexity of development which is divided into different pieces. To cover all this in one single tool led us to Octane. Cost and license fees were also a big issue. The two solutions, codeBeamer and Octane, weren't that far apart but, here as well, Octane was first.

Do a quick scan of tools in the market and dig into your needs. Especially for a project with a lot of users with different styles of working together, Octane is the best tool because of the shared space/Workspace concept. Management is able to get a total overview of all the projects or workspaces and the teams are able to operate in their particular styles. That would be my advice.

For small teams, there might be different solutions that are cheaper, JIRA for example, and tools that are more flexible. But if you need to run bigger businesses, Octane is the best because it's replacing a whole toolchain.

The solution can provide a single platform for all automated testing but it's a little different for us because of our strong dependency on hardware, like robots, for automation. We need to have a robot that presses a button, for example, for real end-to-end testing. It depends on the types of errors you're working with. ALM Octane is integrated and fully supporting every task. But on some levels, because of our special needs, we have to work with third-party tools and we then use Octane as a single point of truth for all the results.

Integration of ALM Octane with your CI server is possible and we are working on that so that we can use the features of Octane and connect it to our different departments and solutions. The idea is to try to streamline things and make Octane the central tool for those use cases. Although it's possible already to do this, we have to use some workarounds because of our tools and the way we use the solution. It takes time until the central tools are supporting various processes and, in the meantime, people develop their own processes and their own little tools and they want to stick to their working solution and not start all over again. This is going on in different departments and different areas of the company. So if you then try to integrate all this in a single tool, at the end of the day, you are taking away their "toys" and their "babies" that they invented. So it's a work in progress. But it's possible and it is on our agenda for this year.

The solution hasn't reduced manual testing time in our organization yet, since we are just starting with the integration of our test automation and Octane to create a workflow and process where everything is integrated. This is something we are working on. The first step was to replace the old ALM for a certain number of user groups. We now have more than 7,200 users working in Octane, and we have more than 1,000 concurrent users working in it. It takes time to develop this. But the goal for this year is to integrate it and to use it more and more efficiently. And then it will definitely reduce automated and manual work.

We are using Micro Focus ALM Octane for agile purposes and integration with ALM.

The most valuable feature of Micro Focus ALM Octane is the reports. We are able to do customization.

The solution should improve by adding scrum board-like functionality.

I have been using Micro Focus ALM Octane for more than one year.

I rate the stability of Micro Focus ALM Octane an eight out of ten.

We have 14 people using the solution in my company. We might increase our usage of the solution depending on the project we have.

I rate the scalability of Micro Focus ALM Octane a nine out of ten.

I rate the support from Micro Focus ALM Octane a nine out of ten.

Positive

I have used Jira previously.

The deployment of the solution can take approximately four hours. However, it depends on the environment. The solution can be integrated with GitHub.

I rate the initial setup of Micro Focus ALM Octane a seven out of ten.

We used an integrator for the deployment. We have three people involved in the deployment.

The price of Micro Focus ALM Octane is too high compared to other solutions.

I recommend using the free version before purchasing. 

I rate Micro Focus ALM Octane an eight out of ten.

We are using it for test management. We are using its latest version.

It can simplify testing by structuring it after the application modules that you are defining yourself, and these are both tests and defects connected, which helps you control the quality in different areas of your solution that you deliver.

The filtering options are very good once you learn them. The document reports are also valuable. You can create reports in Word and PDF formats. That's very useful.

It is flexible. You can integrate it with a lot of other products that are available. If needed, there are APIs available. That's also very good. It's also pretty easy to adapt for the users.

Development of extensions or connections to GitHub actions could be better. Better integration with Azure DevOps would also help.

I have been using this solution for about four years.

It is stable.

It is scalable. It is just about adding more power and more Elasticsearch servers, and you should be fine.

We have about 500 different users daily.

We are happy with them. We have weekly meetings with the PAM.

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. 

We installed it on the side of the existing one, and we migrated step by step or project by project. 

To start with, it was pretty complex because it was a pretty new solution when we installed it. We were probably one of the first bigger companies installing it. So, we were quite early adopters, but it is a lot easier today to install this. We haven't had any problems. There are very few errors in the solution.

It was done a long time ago, but we spent a lot of time because we had to explore enabling single sign-on, etc. That contributed to taking some time, but that had nothing to do with the product. It is probably a lot simpler today.

We are an IT company. We do it ourselves. We had just two people. We probably had a DBA too.

It is hard to say. We don't measure it, but we probably have seen an ROI.

If you compare the price with the functionality, it is pretty much the same as other solutions. If you compare it to Jira, for instance, it has a lot more functionality. You don't need any plug-ins, but it's also more expensive. Once you start adding your different plug-ins to Jira, you'll probably end up with the same amount or more.

There is also a yearly support cost, which is usually 25% of the initial cost of the license.

We already had ALM Quality Center. So, it was a natural move to Octane. It was easier for migration purposes, and the users knew some of the main functionalities. So, we did not evaluate other tools.

I would rate it a nine out of ten. It is pretty good.

I mainly use ALM Octane for product teams and Agile teams.

The biggest problem with ALM Octane is that it's very complex, so it's difficult to use and scale. The graphics could also be improved, and CSD could be added.

I've been using this solution for over a year.

ALM Octane is stable, but its performance isn't so good.

The scalability isn't good.

Micro Focus' technical support is good.

Positive

The initial setup was difficult and took over three months.

We used an in-house team to implement.

ALM Octane is very expensive.

I compared Octane with Jira, which is better-priced and more user-friendly than Octane.

ALM Octane is complex and difficult to use, so you have to be willing to train the people who are going to be working with it. I would rate it five out of ten. 

We use Micro Focus ALM Octane for testing. We don't use the entire portfolio, but we use it for testing, documenting test cases, executing test cases, and tracking defects. The platform is critical to us, because we're using it for compliance purposes.

We like Micro Focus ALM Octane because its performance is okay, and its stability is okay, so we use it a lot. The platform is easy to use.

From my personal point of view, what could be improved in Micro Focus ALM Octane is its integration with Jira. The latest version of the platform could have that integration by now, but at least our version doesn't have that integration with Jira.

We're using Jira for our user storage and the whole agile part of a software development lifecycle. We don't have that Jira integration, so the testing and the definition of user storage are separate. We're moving more and more towards the agile software development lifecycle, and we chose to stick to Jira, so what I'd like to see in the next release of Micro Focus ALM Octane is Jira integration.

I've been using Micro Focus ALM Octane for years.

Micro Focus ALM Octane is a stable platform.

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.

The initial setup for Micro Focus ALM Octane is very straightforward.

I'm not sure which version of Micro Focus ALM Octane we're using, but I know it's not the latest version. We have 3,000 users of Micro Focus ALM Octane, and we have plans to increase usage for it.

I would recommend the platform to others who are looking into using it.

I would rate Micro Focus ALM Octane a nine. It's not perfect, but it could also be because we're not using the latest version. We use it a lot, and it really adds value.

Micro Focus ALM Octane is hosted on a separate environment, that's a hosted environment for us, it's not on-premises because Data Consultancy Services is supporting the outsourcing to that company. If you compare Micro Focus ALM Octane with Jira, we have an on-premise deployment for Jira, that's the difference.

The most useful feature of Micro Focus ALM Octane is the dashboards, they are easy to use. 

I'm using Micro Focus ALM Octane as a manager, and it is two times easier for us than other solutions. The look and feel are good and we can customize the reports and dashboard. From a management perspective, it's quite a good solution. The features are robust, ironclad, easy to configure and use. 

When it comes to CI/CD for the developers, I did not find any major differences with other solutions except that some things are saved in the files rather than being visible in the window. It is not available in the graphical user interface(GUI), but it is in Jira.

The solution is frequently updated with new features.

I have yet to experience the CI/CD part of Micro Focus ALM Octane but as demonstrated by the team who is providing the services, I see that the CI/CD could improve. When we check in the code, for the code snippet that has been checked in by a particular user, you need to open a separate file. When comparing Micro Focus ALM Octane to Jira, they have a separate window in which you can click on the ID and the code is visible in the snippet. It's a two-step process in Micro Focus ALM Octane and it's a single-step process in Jira. It's essential for the developers to think about this difference.

I have been using Micro Focus ALM Octane for approximately two years.

Micro Focus ALM Octane is stable.

I have found Micro Focus ALM Octane scalable.

We have approximately 250 projects using Micro Focus ALM Octane. We are a  small team of 10 to 20 people that varies at times. Our performance-driven teams and we have been releasing month on month. We are finding it very easy and comfortable with Micro Focus ALM Octane. 

Since the ALM Octane is outsourced for us and another MNC provides support, regarding scalability, we as customers to them have observed it's highly scalable - addition of servers to handle thousands of requests/reposne from end users - agile/scrum teams/project managers/ stakeholders to manage backlog is easily met. There is no lag in response time, never did the pages hang. I never waited for Dashboards to collect data and show up, it's just in a fraction of seconds. 

Also, latest in DevOps technology like Azure DevOps for CI/CD is easily implemented. 

The support we receive is fast. When we had Jira, we had our internal team who had been given the training to support us. With Micro Focus ALM Octane we have outsourced the support to a separate company called Data Consultancy Services, and the response time is great.

We have used Jira previously.

The senior management of my company handles the purchases of the solution. However, the price per developer was a major reason we switched from Jira. Apart from the complexity and the support, the price was a major reason that a team of 20 people unanimously decided that we would prefer to go with Micro Focus ALM Octane rather than Jira. The senior management had seen some benefit in it and they preferred it over Jira because the per developer cost was less and the support was superior.

Micro Focus ALM Octane has been exemplary, and as a project manager, since the day I've started using it, it has been wonderful. We are very comfortable with the processes and the tool. We have zero worries since we have been using the solution. It has been very positive from our side.

It is early to rate Micro Focus ALM Octane because we currently are using only the dashboard features, solution backlog, and requirement backlog. The CI/CD has yet to be implemented. Addiotanlly, the orchestration is pending, but as for the current usage for these features, the solution backlog management, prioritizing the task, creating the task, creating the defects, creating the manual test fields, and automated test fields, are very good. 

We have experienced CI/CD in orchestration in Jira, but not in Micro Focus ALM Octane and, in a month's time we will have a better understanding.

I rate Micro Focus ALM Octane a ten out of ten.

I give the high rating because of the support, look and feel, reports, and the dashboards

My primary use case is as a test management tool.

Octane has allowed us to trace data when it goes into test management, so everything is linked together and cannot be lost, and we can see the progress data is making through the system. Another benefit is that you can automate data being brought into Octane.

The most valuable feature is the product's integration with existing tools.

An area that needs improvement is the dashboard - particularly the lack of ability to compare data on a single graph. This means that you need to switch to another product instead of being able to do everything within a single tool. Performance and filtering could also be improved.

I've been using this solution for two years.

The current version of the solution is fairly stable - we're not seeing many problems.

This solution is scalable, but additional servers may be necessary depending on how many users you add.

Technical support can be slow to deal with if you need more than basic support.

Initial setup can be a bit difficult, particularly for people who are unfamiliar with all the components. For us, setup took about six months.

There is a conversion fee for changing licenses to Octane, even if the current license is from the same company.

I would rate this solution as seven out of ten.

I work for a state government in the United States. So our business constituents have departments that use it. And we have analysts who build business cases in the ALM Octane for specific tasks or specific projects that we're working on. We create business rules for each project in ALM Octane. Then, when the developers finish coding and we're getting ready to test, we use ALM Octane again to test against the business rules we created. So that way, we know we're meeting our business objectives, our customer's requests, and what they want to be changed in our system.

It's more streamlined because we have it all under one umbrella. And once the business requirements and rules have been created, we can do test cases and apply them to the business rules. So we're able to make sure that the developers' code is tested thoroughly to meet the needs of the business.

It would help us if ALM Octane got FedRAMP-certified, so our government departments could use the cloud solution. That way our external consultants could access it. We've created a URL to get to it, but if it were FedRAMP-certified and service and had support in the continental United States, that would be better. In the government space, we need organizations or companies to be FedRAMP-certified, and the system must reside in the continental United States. The Micro Focus help desk and their environment are not located in the continental United States, so they do not meet the state's criteria for us to be on the cloud. I understand that the company is working on some FedRAMP certifications and is looking to do that because they cannot put all of their government customers in their cloud environment. It's not a technology issue. It's a security issue.

So we've been using Micro Focus for almost four years now, but we just recently migrated to Octane back in July of this year.

ALM Octane is very scalable. We have a great server team that we use to increase its space or size. We handle it internally, but it works great. 

We have worked with Micro Focus support, and they're very good. I'd say 9 or 10 out of 10. They're always available. And if they don't know how to fix an issue, they know to talk to. It may not be the person you're talking to or the person they've referred them to, but they know somebody who could help. So they know how to escalate within their organization.

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.

Setting up ALM Octane is straightforward because we were already using Micro Focus ALM for testing. We were implementing it in the business requirements area. That was four years ago, so I can't remember exactly how long it took, but it was a few months. I'd say maybe two to three months. We did it on our own with Micro Focus guiding us. And Micro Focus had a statewide user base at the time. Other departments were using it, so we were able to share what everyone was doing. I have two FTEs. One is in charge of the business requirements module, and the other oversees the test testing and defect management.

I think the cost of ALM Octane is comparable to other solutions. It's actually a little less than DOORS Next Generation, but I don't have the numbers in front of me.

I rate MicroFocus ALM Octane eight out of 10. It's a great product. If you want to integrate your business requirements with your testing and defect-management tracking, it works beautifully.

Our use cases are test management, defect management, and release management. We also do quality management and we have started to put our Agile journey on it. That is something we started at the end of last year. We're putting more and more on it. We're doing Agile delivery and Waterfall delivery with it.

It provides us with a single platform for automated testing. We've integrated our automation testing with Jenkins to the pipeline module—parts of it, at least—and the other part is connected through the API. It makes the test you're executing very visible. It also enables you to centralize. When we report on a project basis, we're able to do it in one click for a given project. The graphs are standard for all the projects. You just click and you always have the same set of reports, tailored to that project. It fetches the data from that project. I don't need to click five times to find my report. I just click to the next project and my report is there with all the needed information in one view. 

That's what my release manager also loves about it. He doesn't have to click 10 links or 10 drop-downs to get a report. It really has it all together in one view. If we have a release we report it on a project basis, and we can also report on an overall release basis. The overall reports are also done with one click.

In addition, we use the solution’s Backlog and Team Backlog capabilities and the team is very much working together there, from the developers to the testers to the product managers. They're all working together in one space or one Backlog to deliver the functionalities or the features. This is a good thing.

Octane has also reduced manual testing time. We integrated a big part of the regression sets into the pipeline. There's room for much more. We've only scratched the surface.

And using it, we have been able to streamline a lot on the business side. We have business testing or acceptance testing, and for them it's less complicated and there is less effort needed to get their stuff done. It has reduced the cycle times which, in the end, reduces cost.

On the user side, what I like a lot is the reporting capabilities. There's no tool, to my knowledge, that gets anywhere close to Octane at the moment when it comes to the reporting capabilities. I can do everything with the reporting. There's nothing missing. I have all the options. I can create graphs, including graphs of several types and looks.

Octane provides out-of-the-box integrations to proprietary, third-party, and open source tools. The integrations are of high quality because we were easily able to integrate Jira with an additional tool. That connector tool is out-of-the-box and it's very easy to handle. We also integrated one of our in-house developed applications that has a rollout tool. The person responsible did it in one or two days with API connections. It was very easy for him. In addition, we integrated Confluence with Octane, using a self-developed script that is also based on the APIs. For people who know APIs it's very easy. 

Octane's Agile support at the team level is pretty good because it's very visible. The sorting and filtering are very advanced, which is something I miss on Jira.

There aren't major things that need improvement. It's more detailed things, minor tweaks and improvements. For example, updating items, sorting, bulk updates—these things could have a bit more flexibility, but it's still possible to do them. 

Also, for training, the proposed graphs in the dashboards could have some more explanation about what they're doing because not everyone is using the same metrics. This is more a training or knowledge thing, not a lack in the tool, and I already addressed it with my OpenText contact.

They improved some of the things I had on my list in the newest version. I haven't dug through the newest version fully yet.

We started to evaluate OpenText ALM Octane at the end of 2019. We did the kickoff in January of 2020 to plan all the migrations to it. We came from ALM QC.

It's very stable. We had one issue that was due to a faulty, outdated script that overloaded the system somehow. Apart from that, Octane is as stable as it gets. We haven't had any downtime apart from that outdated script.

The technical support is very good. Depending on the severity of your ticket, the feedback is almost immediate. And we can collaborate with them, show screens and share logs, and they come back with a solution. It has been a positive experience.

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.

Because we came from ALM QC, and that tool was in use for quite some time, there were a lot of user-defined things and customization. Initially what we had to do was a cleanup on the QC side: what we wanted to take over and what we didn't want to take over. We really cleaned out stuff that wasn't needed anymore. That took one or two months. 

The actual installation of Octane was very quick and straightforward. The customization and configuration of Octane took about two months. That was because we were very new to the application. If I set up a workspace now, it's much faster.

We have 1,100 users and their roles are really across the company. We have project managers, developers, testers, release managers, and test managers. We also have business users and product managers on the Agile side. Any role you could think of is using it, apart from the C-level.

What I like a lot about Octane is that it's very easy to handle from an admin point of view. The maintenance is very low compared with ALM QC where it took several hours or days, even, to set it up and upgrade it. Those processes are very easy with Octane.

I compare it, still, with ALM QC, and there's definitely a return on investment on it. I see this leveraging more in the future.

The comparison is always with Jira, so the pricing of Octane is a bit on the higher side. But if you look at what you have to add to Jira, on the plug-in side, to have the same abilities you have with Octane, you're more or less even, or even ahead with Octane.

We only looked at Jira. We had some concerns about its reporting capabilities and its task management capabilities, as well as managing Waterfall and Agile in parallel.

You definitely need to prepare well, if you're going to implement it. Do a proper analysis of where you're coming from and what is still needed and what is not needed, and really kick out stuff that isn't needed anymore. It will make the whole migration to Octane easier when you have less historical data in it.

I see that our users like to add things and try new things because it's built in an open manner. When you add Python scripts and use the API connection, you have a lot of flexibility for doing certain things. I see some developers who like it and who like to experiment with how to work better on their side.

We have started a PoC on integrating the solution with our CI server for continuous integration and delivery. The CI/CD is working and we're fine-tuning it now. I hope it will give us a one-click approach where we can even execute the pipeline from the GUI, which will make it easy to use. My vision is that we have all the pipelines integrated in Octane and that we can trigger them from there to speed things up and have them visible for developers and for testers. This would also be a way they could collaborate more. We're not there yet. 

It has the potential to reduce integration costs by building a streamlined application delivery pipeline that is connected to all IDE, CI, and SCCM tools.

Octane can also provide a single, global ALM platform that supports all our Agile and Waterfall needs. We don't have all our Agile in yet, but it can. That's the vision: that we have them all in one tool. We're not there yet, but I see glimpses of hope. It has the potential to improve the quality and the speed. The potential is there.

It still has upside coming. Things are being developed. We are in the preferred partner program, so we see also the new features that are coming, which will facilitate daily work.