OpenText ALM Octane Reviews

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

We use it for Agile: Requirements, backlog, and testing for 80 apps, including SAP and Teamcenter.

Octane provides the platform needed for teams to run Agile projects. Previous tools like ALM QC were modeled for Waterfall methodologies. Metrics are not relevant for us in this case as we are still moving from Waterfall to Agile and hybrid delivery.

Our Waterfall practices have been standardized and templated to provide cross-project metrics and reusable assets, such as tests and other libraries. Our Mobile and Solution Delivery teams are finding Octane provides the CI/CD and DevOps connections with development and infrastructure teams, connections that they had previously managed with brute force tools like SharePoint, Excel, and email.

Backlog management is the most valuable feature. This was a capability that was missing or difficult to achieve in ALM Quality Center.

Octane, from an administration perspective, is very limited. The application is improving with each release but what is missing is the ability to manage users and workspaces. I would also like "usable" reporting for more than a few workspaces. Also still missing is the ability to copy a workspace or get data in or out, except for limited REST calls.

As early adopters, we began using Octane before the ink was dry on the first release. Since the first release, we have seen nothing but added capabilities and feature/functionally improvements. We have not experienced a single instance where something was removed or deprecated. That said, we do find they like to move buttons around and hide things in different drop downs now - but there has never been a loss in capability.

We have projects and teams with several hundreds of users and tens of thousands of records (requirements, tests, etc.). There are risks with not being able to copy a workspace to test changes to the CI/CD or pipelines, so that is a miss. The reporting is limited to a few thousand records so we've had to request an override to the limits - but Micro Focus delivered on this immediately, once we stated the case.

I've worked with the SaaS team and Micro Focus R&D on many aspects for initial setup, bridges, and complex four-system conversions. The technical experts are some of the best I've worked with in more years than I can admit to.

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 are on SaaS. Setup and deployment were immediate and required no effort on our part, except to make the request. This was also true for staging environments for a PoC.

Initially, our implementation strategy was to enable a trial period of six months to one year. The community response was so overwhelming that we went into a production mode within the first quarter and began setting up and migrating teams within the first year. Even emphasizing that the platform at that time was essentially a PoC, teams adopted it, even with the risks, and never looked back.

We work directly with our Micro Focus CSM. The technical team, including R&D, is first-class.

The only quantifiable ROI is the license cost savings converting from VersionOne and JIRA. With about 200 users for each platform, the ROI calculations are based on what was paid for the previous solutions.

I highly recommend the flex licensing model. With flex, we can ramp up or down to accommodate demand changes for roll-outs or PoCs, etc., as needed. It is especially useful for our performance and load testing areas.

We evaluated solutions from ServiceNow, VersionOne, Jira, and multiple in-house solutions.

My advice, going on my experience to date with Octane, is to be sure you are ready to support the demands for licenses. I have found that once a team gets access, they will not go back to the previous tools and will want to convert everything. Make sure you have guidelines in place on the CoE's expectations so the teams actually use the tools for SDLC and not as a replacement for simple request tracking.

In terms of our biggest lessons learned about adapting tools and processes for Agile and DevOps, building templates and standards that have provided a lot of value in a Waterfall approach do not migrate well to an Agile practice. Previously, we focused on testing, mostly in isolation from requirements and development. Moving to Agile in Octane switched the primary usage to backlog (requirements) focus. The challenge has been to bring focus back to testing and quality delivery in concert with backlog management.

The challenges we faced with ALM Quality Center were the test and defect management capabilities. There was a difficult process in place to track and link requirements and releases. In ALM Octane we are finding the reverse. Requirements management, release, teams, etc. are exceptional, but we are finding the users are less focused on the testing and defect management capabilities.

We have 1,000-plus users using this solution in every role. Most are team members but we have admins and integration teams assigned to every role, including custom roles we've set up. In terms of staff for deployment and maintenance, we are on SaaS. Our CSM manages that side of things.

We have been using Octane since it was released, and maybe a little before that. Octane is a corporate standard and we see no reason to not continue migrating teams - that are ready - from Waterfall tools to Octane. We still support 3,000-plus users in Quality Center who could potentially migrate at some point.

We're using it for test management, to write test cases and we have put it into an overall approach which is called BDD, Behavior-Driven Development. Within BDD we're using Octane to manage all tests, to plan and do test automation. We're doing test automation with IntelliJ, together with TestCafe, which is a pretty nice test-automation tool. We have Jenkins with a pipeline connected to Octane, working the whole process. 

The main intent is to have a quality solution. Our development is working in JIRA, which means that we have split it. We import user stories from JIRA to Octane and start working from there on our testing.

We started from scratch because we didn't have any BDD approach. We used a more old-fashioned method of development, more Waterfall and so on. We were looking for a solution which would be a good tool for our new methodology. For us, this was a key benefit from Octane, to get rid of the old style. We are implementing Agile methodologies in DevOps, that's the main thing. We try to use shift left to test much earlier and therefore it's really helpful to have Octane and to implement the new approach with it.

The most valuable feature of Octane, in comparison to ALM, is the whole Agile approach, that we can run it with the sprints and have it better connected to the whole development process.

The other feature is the pipeline, so that we can now connect to Jenkins and then have all the results from testing, from external, in the tool, so that we can see the whole approach from there.

Many things are nice so it's hard to say what is best; for example, the way it's organized. We can work with labels so we have better filtering solutions than in ALM. And it's much smarter and leaner to use than ALM.

There is a lot of room to implement new things. I would like to have more possibilities for doing test automation directly in Octane or to see UFT scripts within Octane. The implementation within ALM of UFT was much better than in Octane because I can only see the results from our test runs in Octane, but not the test itself. With Gherkins in there, that's fine, but I do not really have a hand on the scripts themselves. I can follow the pipeline jobs in Jenkins, but I can't see what's really happening there. So I would like to have some more information about that in Octane.

Also, while there is a Requirements Module in Octane, it is very plain. It's okay to have some requirements described there, but it's not really following the whole BDD approach. I would like to have more features for requirements in there; not as much as in ALM because in ALM it was a mess, it was too much.

There is a whole lot of room to improve.

It's very stable. Over the last one-and-a-half years, we have really not had an issue. It's fine. We only have a handful of people who are working with it so far, but for them and for us it's okay. 

We have a very small team. Some are working from Croatia and we have a team here. We have a maximum of three or four concurrently using it. In the future, we will have many more. For the moment it's a pilot, but as a pilot, it's working fine.

Tech support is very good. We are in direct contact with the guys from Tel Aviv and it's very good. We're in touch by phone, email, and we have sessions together with them. It's much better than it was with HPE, in my opinion.

It could be, because we are a pilot project and one of the first here in Germany, that we have more direct contact. But this is working. I really like it.

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.

It was really straightforward. It was a pleasure to implement our approach with it, compared to ALM or to the older tools. It was really easy. I started from zero with Octane. I had never seen it before. It was brand new and I really learned it on my own, everything in there, including the setup and how to implement the processes, etc.

In terms of maintaining it, right now it's just one person. Once we scale it, I don't expect it will take many more people to maintain it because it's very easy to maintain. If it's set up well there shouldn't be too much work to do there. For the technical parts, we will still need only one person and, within the project - depending on the number of projects - we will need, perhaps, one guy who's taking care of it from time to time.

We have had some strong discussions in regards to JIRA, to use JIRA plug-ins and to get rid of the overall HPE/Micro Focus way, because of the money. We had some discussions about whether we could make it with open-source tools. But at the end of the day, we figured out that they're really not good, full test-management tools. The overall approach, with everything in one place in Octane, for the money, is more valuable.

Since we're not finished with the license discussions, I can't tell you the end result or numbers and figures but, in the end, it's more or less equal, from the money point of view: if you're using open-source with more consulting or if you use a tool like Octane, which costs some money, but you don't have a lot of work in terms of implementing and consulting, etc.

I don't deal with licensing and pricing, but it's worth the money, from my point of view, because it's very good. But that's all I can say about that.

We looked at a few. One we're still having look at is Xray but doesn't fit with our BDD approach. We also looked at ServiceNow. That's mainly for ticketing systems but they also showed us something about test management. It was very close to ALM, to the old way, so it was also not very useful for our process. Our support is working with ServiceNow but it doesn't fit with our project.

Think about your processes and the methods you're using for development and quality management and see if the tool fits. If yes, it could be a good idea to use Octane. I have presented Octane many times within our company and outside of the company, and I have had very good feedback and many questions about whether it is useful or not. "Can you really say it's the perfect tool?" Mostly I have said to them it's really good. If you work in Agile and if you work in BDD and Gherkin, I think it's the best tool on the market.

I have a pretty long history in testing. I started in 1999 and, since then, I have worked with all these products from HPE or, now, Micro Focus. I know all the history and the older tools and I'm really pretty happy that we have a tool now which is working in a more modern way, in a good, Agile way. It's pretty nice.

With respect to how our tools and processes are evolving to adapt to the change from traditional Waterfall development, for requirements we do not have a good tool to work with, but we have Octane for testing, we have JIRA for development, and we still have ALM for defect tracking and for working together with the other teams that are still working in the Waterfall process. So for synchronizing of defects, we are connected to ALM. We have IntelliJ for development, and we use it together with Cucumber and TestCafe for test automation. We have Git for all our results and for version control. We have Jenkins, as mentioned before and, for reporting, we are mainly using Octane. This is the overall tool landscape we have.

The biggest lesson about adapting to Agile for DevOps is that it is really important to have APIs, to have open interfaces to connect all of these tools together; to have the chance to implement the pipeline easily. We are no longer bound to only HPE or Micro Focus tools. We can work together with open-source tools. It was easy to implement such things in Octane. This was a great lesson.

For our releases, we still have a Waterfall approach. We have a live release every three months. It was a little bit tricky to put together the testing for Agile and for Waterfall so that we could do the quality assurance for both approaches in one tool. I've found a way that I can have sprints over a longer time for the UAT, using Octane. We have 40-day sprints and testing in one tool. It was really nice to have found a way to have them in one tool. This was also a good lesson, to see that both can work in one tool.

There's room for more features but, for a relatively new tool, it's very good. I would rate it at seven out of ten. If the features and enhancements we have requested come through, it will be a ten in the future. Given the maturity of the tool, that it's only one-and-a-half or two years old, seven is a very good number. I can give it a 10 when the Requirements Module is working better and when some other things are solved, some problems with implementation that need work. Then it will be a ten.

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 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.

I use it to integrate automation jobs from Jenkins, and to document manual test cases to have traceability on our deliverables and OpenText coverage of our requirements.

The integration capability of ALM Octane was very straightforward. We had a supporting team, and they provided us with detailed documentation.

Test reporting and traceability metrics have proven most effective for managing our projects.

Promoting it more could help a lot of projects. It's time-saving and efficient, and I'm sure it will benefit projects with safe implementation in place. 

Octane is a good choice for companies using the safe portal.

I have been using it for three months now. 

It is a stable product. It performs well. 

Technical support has been good so far. They've implemented our requirements on time, with no delays.

I used Rally. 

Rally wasn't easy. The interface was very difficult, and it was hard to have traceability of our work. The UI wasn't user-friendly. From a test management perspective, we couldn't integrate our automation pipeline into Rally. 

We wanted one solution for both automation and manual testing to have a complete picture. Management team also needed easy access to relevant data. 

As a QA, I wanted to see the release details, defect rates, test coverage, and epic coverage for each release. ALM Octane's reporting structure is much better than Rally's. Rally is a bit complex from the UI perspective.

It's an online cloud version. We just had to have user accounts created, and we were all set up. It's been very smooth.

I am not aware of the pricing because it was introduced at an organization level, and we just integrated it into our project.

My organization would have definitely evaluated other options. We've been using ALM for years, at least since I joined three years ago. 

However, we recently acquired a new organization, and they were using Rally, which was difficult to integrate with Jira. So, we switched to ALM Octane.

We definitely use it as our one-stop solution. 

I would recommend it but depends on the specific project and organization needs. But for our project, it suits us well and has resolved a lot of problems. We are quite happy with it.

It's only been three months since we started using it, and there are still many features to explore. For now, I'll rate it a six out of ten because I haven't discovered all the features yet.

The platform's most valuable feature is pipeline integration or continuous integration services. It can fetch insights about various deposit points after synchronizing with Jira, IBM, or other tools. It gives visualization through dashboards and reports updates quickly and easily.

The product's requirements management feature needs enhancement in terms of functionality. Also, the release management feature needs expansion.

We have been using OpenText ALM Octane for ten years.

I rate the platform's stability a ten out of ten.

I have worked with around 400 OpenText ALM Octane customers. It works well for synchronizing data.

We had a good experience working in the support team's R and D department. However, they could provide more technical resolutions.

Positive

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.

The initial setup process is straightforward. The platform has well-defined, out-of-the-box workspaces and projects incorporating good practice workflows.

The product is highly priced compared to other tools. However, it offers substantial value. There is a distinction between OEM pricing and the final pricing for customers. They could understand the delta between the two and work towards a favorable outcome.

I rate OpenText ALM Octane a ten out of ten. It is a great product considering ETL and DevOps methodologies. It integrates and synchronizes well with other tools as well. I advise others to understand the business requirements before making a purchase decision.

In my company, I don't specifically work on OpenText ALM Octane, but my team works on it. My company uses OpenText ALM Octane as a test management platform.

Since I work for a software company, we use it for the management of test scenarios, how many tests to run against certain features, what are the test results, how long the resolutions or the fixes take, and when we can stop testing the features. The product helps in terms of collaboration and coordination between different teams.

The most valuable features of the solution are its ability to manage test scenarios, test results, and test automation, which are its primary functionalities.

Improvement-wise, I think that the tool needs to be made more flexible and easy to integrate with the rest of the tools in the SDLC ecosystem. There are some challenges when we want to integrate the tool with other products, and it takes time for a team to figure out how to do it.

I have experience with OpenText ALM Octane for a year and a half. I am a customer of the solution.

It is a stable solution. Stability-wise, I rate the solution a nine out of ten.

I haven't seen any significant requirements in my company regarding the scalability aspect of OpenText ALM Octane.

Scalability-wise, I rate the solution an eight to nine out of ten.

Around 250 people, consisting mostly of QAs and software engineers in my company, work on the solution.

I rate the technical support a seven out of ten.

Neutral

I rate the product's initial setup a seven on a scale of one to ten, where one is difficult, and ten is easy.

The solution is deployed on an on-premises model.

I rate the product price an eight on a scale of one to ten, where one is cheap, and ten is expensive. The product is neither cheap nor expensive.

I don't recall the names of the products my company had evaluated against OpenText ALM Octane in the past. The reason why my company chose OpenText ALM Octane is because we were using Micro Focus in our environment.

I suggest to those planning to use OpenText ALM Octane to ensure that the workflow and the tools that you use can collaborate and integrate with the product.

I rate the overall tool an eight out of ten.