OpenText ALM Octane Reviews

It's an Agile tool for our project-based test management. 

One of the things we're working towards is DevOps. With an Octane project, we have our automation, our requirements, our tests, our pipeline into build-and-deploy, and the ability to identify problem areas. It makes things quicker because it's more along the lines of an automated process. I would estimate it saves us 20 percent in terms of effort and time. We haven't gotten to Nirvana yet, which would be full automation, but we're trying to achieve that.

The most valuable features include the predictive analytics, being able to trace everything, and having all the tools for testing and test management in an Agile environment.

The problem with Octane is that if I'm in ALM and I need to go into this Agile process, and I have been using Micro Focus ALM, when I go to Micro Focus Octane, all the things that are in ALM are not all working in Octane. For example, the template feature: When I manage projects that are being created in ALM, I have a standard template, but I don't have a template for them in Octane. I literally have to create the project from the ground up every time, which for an administrator, is a nightmare solution. It could take you upwards of two to three days to set up a project, and then you have to try and make sure it has all the same stuff as the previous projects. You literally have to have this massive checklist to make sure you create all the same fields, you put all the links, you put all the dropdowns to make sure all this stuff works for the projects.

If I'm jumping from ALM to Agile, I'll go into Octane and create a new project template form, but I have to actually document creating that because I have to create every individual piece of that project - all the pages, all the fields, all the drop downs. I have to duplicate all the work, each time I have to add a new project in Octane.

It's very complicated. When I set up new projects, it takes multiple days, and then it's fraught with mistakes, because it's a manual process for setting these things up. I have multiple people trying to do it and I'm going to have all kinds of errors Typically, for ALM, it takes any one of us minutes to create a new project. I can create a new project in about 15 minutes, at the most. And I can guarantee you the project that's created is identical to all the other projects that I have created, because it's a template. In Octane, I literally have to create every field value, every field, every form, every workflow, manually, each time, which always ends up with a problem.

I've talked to them about it. They say it's on a list to be looked at. I would think that would need to be at the top of the list.

Another issue is that one of the things I do is link all these things together. Octane has a Synchronizer tool. The only problem was, it didn't work with all the fields. They just upgraded it to work with multi-select fields. I haven't had a chance to test it yet.

I worked with their engineers on this. I don't know how they could have not done this. There are not that many different field types that you would create. A text string or a single dropdown or a multi dropdown, or a numeric field. They had everything but the multi-select field. All the rest of them worked but multi-select didn't. In my projects, about one-third of my fields are multi-selects. When I tried to get the systems to work using Octane, I couldn't get them to work. I had to use another tool for the projects that needed multi-select. I put those projects in JIRA because JIRA worked.

You've got it up and working. It's stable. Other than the problems that I talked about, it works. I haven't run into any other major issues.

I did have one project switch out of Octane, back into JIRA, because of the way that it displays status. If you are in the Octane test area, and you have defects and test results and user stories, and you want to see a user story, if you have different workflows for defects and for test, what you see on your task board is all three tool items on one page. Say you had a work in progress with a vertical line of task records. You would see a work in progress for user stories, a work in progress for test, and, a work in progress for defects. So from the board, you see three work-in-progress verticals, and you say, "Oh, that's a problem. Which one is it? It doesn't say." The only way to get rid of those is to hide them. They're still there, but you have to hide them.

I struggled with trying to get it fixed for the users. They kept making changes to workflows and every time they'd make a change, I'd have to go in there and try to figure out how to hide it. I think the design of those boards could be better.

I'm in SaaS. If it slows down, I just call them. They increase something, whether its memory, CPU, or disk space. Scalability is pretty much a non-issue.

The support is good. They have worked very well with us, in getting things addressed. I work pretty heavily with the development staff and they are quite open and easy to work with. They do try to get the solutions addressed as quickly as possible.

We do have some big issues that we are struggling with, the template feature and the multi-select and the synchronizing. We were moving in a positive way to move people from the old tool to Octane until we ran into those issues. Now we're actually going backward. They got the multi-select fixed, but, unfortunately, I've got to erase some bad taste in peoples' mouths to get them to come back.

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 the SaaS. The system was all set up and working through the Micro Focus SaaS team. For me, it was just a matter of getting access to it. They said, "Here, put in your user ID and password," and that's how long it took.

The biggest ROI, compared to any other tool out there, looks like it will be the predictive analytics. I don't have it fully implemented, but from the demos I've seen, it is pretty amazing. Getting that fully set up and implemented is, in my opinion, a game-changer. It could make the tool top of the market. 

It's pretty pricey, one of the most expensive ones on the market.

The value depends on if you use all the features that it has. It comes with a lot of features. The difference between the license structure of ALM and Octane versus JIRA, is that you get everything with ALM and Octane. All the plug-ins that come with them pretty much come with the product. You may have some one-offs that you have to buy outside the product but it pretty much all comes with the product.

For JIRA, you buy the pieces one piece at a time. If you only use three of the pieces, you only have to pay for three of the pieces.

If I used all the features of the tool then the price of the tool would probably be fair. I've been doing this for 45 years and I don't think there's a tool on the market that anybody uses fully.

The good thing with ALM and Octane is you get all the features and you don't have to add anything else. If you want to see what the others are, you have them to use.

With JIRA, you need those three things and you buy those three things and, most of the time you don't go looking to see if you can use something else. Maybe two of those things could help you immensely with something else, but typically you don't go looking for them because they may cost more money and you may not have it.

Everything in the tool is good, but then it's expensive. The mindset, now, is go Agile. And go Agile means go cheap, at least in the executives' minds. But, in reality it's not.

You're fighting the "JIRA monster" because all the new developers in schools today use JIRA. When they come out on the marketplace they know JIRA and they like to use it. They don't know Octane because it's a new tool and it's still in its beginning, growing pains. You really have to have a perfect scenario that convinces them to leave what they know to go to what they don't know. I fought tooth and nail to get people to start using Octane here because we had a license, meaning it didn't cost anything more than we were already paying. I couldn't get anybody to come see it. I couldn't get anybody to use it. What I started doing was selling it to new people, people who hadn't been involved with JIRA before. They took it and they like it, except for the one team that left because they didn't like it.

When you compare ALM Octane vs JIRA, it's different than JIRA where you have the core product and then you have to buy all of the add-ons to do what you need to do. Octane tends to have everything you need.

Octane is really good about synchronizing data. Synchronizer is a really good tool to get people who are into any other tool using it quickly. Regardless of where you're coming from, you use Synchronizer to synchronize the data, as opposed to trying start new or migrate. This is a quick way of getting data over and being able to manipulate it so that it's usable in the new tool. If you're going to ALM to Octane, as long as you can get all the fields to come over, it's quick. I took two projects and it worked within hours of getting it set up. When I ran into the problem of multi-select fields, that was pretty much a roadblock; but a simple project to a simple project, it worked fine.

In terms of our tools and processes evolving to adapt to the change from traditional Waterfall development, it requires a retraining. When you're going from ALM to Octane, in an Agile process, everything is completely different. You have to train all the users on how to be Agile, you have to train all the developers on how to develop in Agile. You have to realign your whole organization by resource and resource assignments.

Then, you have to develop your change control, your change management process, because that all changes. Also, your configuration management teams all have to change. It's a complete upheaval of literally the whole organization, to go from Waterfall to Agile. And, for tooling, everything you do, everything you knew before, has to change. Your tools, your process, your planning, your resource allocation, everything has to change. It's a very big process and it will take a long time, and we haven't achieved it yet.

The biggest lessons we've learned, so far, during this transition is that it's bigger than we thought it was. However, I'm still the owner of the tool and, for me, a tool is a tool. You have a screwdriver, and maybe you come up with a nicer screwdriver, but it's still a screwdriver. You still have to screw a nut into an object. The same thing with the testing tools. I still have requirements, I still have tests, I still have test runs, I still have defects. It's just how you process those things within the overall organization, how you address your processes. From a Waterfall process to an Agile process, everything is smaller. As opposed to a six-month delivery and test, where you're addressing thousands of defects, and thousands of test cases, in an Agile process, you're dealing with tens of them instead.  It's much smaller everything because you're working in two-week sprints as opposed to six-month or 18- month cycles or releases. 

In terms of the tools that you use, it's how they fit, how they get you to meet the objective quicker, and how much training has to happen. Some tools require more training than others because they're not logically thought-out processes for creating records. Octane's usability is more logical and step-processed, where you start with one record and it drops down to the whole thing as it explodes out into all of the different areas. Comparing it to JIRA where, if you don't know how to use JIRA, it's not very logical and you have to hunt and find things. In Octane, it gives you the big menu ribbon that has everything from left to right. So, you see how the process flows.

Regarding ALM tools in general, they're struggling with it and it could be because they themselves are on the same road that everybody else is on. But, they're a little bit behind. Agile has been around for a while. JIRA is the ALM of tools: ALM was the tool for test management for Waterfall, where JIRA is the tool for the Agile process. 

Octane is trying to play catch-up. The design of the tool is a little different. JIRA gives it to you in pieces, so you get the core product and you have to add on things to make it actually work, where Octane gives you everything.

We're in the process of going to this process. Right now, the larger side is JIRA. We have four projects using Octane. We can only hope it can replace JIRA.

We currently have fewer than 50 users in Octane. Their roles include BAs, testers, developers, and administrators. We don't require any staff for maintenance because it's all SaaS. The only resource utilization for us is setting up user access to Octane. Ninety percent of that is either the SaaS organization or the users themselves. Because we go through a portal, they have to set themselves up as a user on the portal, and then our support staff just grants them access to Octane and sets them up with a role. I'm the owner of the tool set and the support and maintenance.

Overall, I rate Octane a strong eight out of ten. The tool works and it works well if you're only on the Octane side. It does what it needs to do. It doesn't claim to be the easiest configuration tool, but utilization of the tool and its support for what your project needs seem to work quite well. All the things that they're giving you are everything you would need in projects. It's when you get into the integration piece, when you get into the more complex pieces... that's why I give it only an eight.

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.

I work for a section of our company where what we do is host enterprise tools that our consulting projects can use. Potentially, as we get more and more users, we can have hundreds of projects at a time. We're not a typical use case where we have one way that we're using the tool. The tool is being used on various consulting projects.

Our use cases vary drastically. We have some people who have told us they just use it for testing, there are some people who just use it for defect management. People are familiar with other tools, like JIRA and ALM and even AGM. Octane is new, so some people are trying to take baby steps into adopting it.

Day-to-day, how we typically use it, and how we're promoting it should be used, is for Agile project management with manual testing, including release management, sprint management; end-to-end type of use. We use it to manage our releases in sprints. Other teams within my group also use it for testing and defect management, and that's how we promote it, and train our consulting project teams to use it.

For our use case, it's brought our entire team into a single tool. We're all looking at the same real-time data. Our project management office has been able to set up dashboards for individual teams, and do comparisons by teams, of integration, and cross-team integration, burn-up, burn-down, and cumulative flow types of things. So from a PMO perspective, there is a really good overview, from how we've set up our dashboards, to know where each team is and how they're progressing and how much work they have that integrates with other teams. That's really helpful.

The feedback that we've gotten is that the way testing is closely tied into the product Backlog has made it more intuitive, or easier to manage the relationship between building out an application and testing it. In other tools, that is more segregated. The way it's designed in Octane, people have said it makes more sense to them, and that it's easier for them to understand their data and to maintain and test their solutions.

Very generally, the feedback that we've received is that people really like the user interface overall. It's intuitive to use, it's easy to learn, people like the usability features, the user experience. 

Another thing that people really like about Octane is how easy it is to customize. In some previous tools, that has been very limited, or you had to know how to write code to do some of the customizations, or it was very confusing. Going back to the user interface, they've made the customization of the tool, the workspace settings, very easy for people to figure out and use. We've gotten a lot of good feedback on that.

In general, I think people really like the Team Backlog and the capacity bucket for each individual team member. They like that ability to track capacity and progress very easily that way, by individuals.

I work pretty closely with Micro Focus, particularly on ALM Octane. Right now we have a backlog of some 60 or 70 enhancement requests, varying in priority from very high to low.

In general, there's a trend in our requests to have the ability to export data, en masse, out of Octane. There are capabilities within Octane to export data, but there are specifics around test suites and requirements and relations, as well as certain attributes, that we would like to be able to export easily out of Octane and into a database or Excel.

One of the things that a lot of our project teams have complained about is the simplicity of reporting that's available in Octane, and that they have to export data out of it in order to create the types of reports that their PMO or their client wants to see. Octane provides solutions around OData, and integration into reporting tools, but what people really want is smart and good reporting, advanced reporting, within the tool. They don't want to have to go out to another tool for reporting.

In general, we also have some requests to beef up the manual testing abilities and the ability to report on testing progress. All the basics are there, but there's an issue of maintainability. For example, one thing that we brought up to them recently was: Once you plan a test and it creates a run, more particularly a suite run, you can't edit the suite run afterward. It locks you in, and we're saying that that is not realistic with how people work. Mistakes are made and people are humans and we change our minds about things. So the tool needs to allow for a bit more flexibility in that testing area, as well as some better widgets to report on progress.

Overall, we haven't had any issues with stability. There are two things that do come up.

It seems like we have issues with Elastic, the integration to it. Intermittently we have these issues where global search isn't working, or widgets aren't populating, so there's something a little bit unstable with that integration. It could be on our end, or it could be something with the setup, I'm not sure.

We're also having performance issues. It's not really stability, but we do see some slowness in the system and in our performance testing, so we're working with Micro Focus on that to figure out how to resolve those issues.

The performance issues that we have come about when we have load on the system. We're trying to figure out if the source of those issues is the environment, and what the optimized settings would be for the environment: memory size, number of disks, things that we're doing in our performance testing, etc. But we're also looking at the software to see if there are any issues there.

We are working with about 180 to 200 concurrent users, which isn't a terribly high number. We're looking at all sorts of angles but we're currently in the middle of it, so it's hard to tell what the source of the issue is.

Micro Focus has definitely been good about helping us out with all of that, giving us advice, hardware related, on what our settings should be. Maybe we're not sized exactly correctly. According to Micro Focus - they also, of course, do their own performance testing - and they haven't seen the results that we have.

Because we're a partner and we've been working with them for years,  we'll have quick calls twice a month, at least for Octane, to talk about new enhancement requests that are coming up, providing them with feedback on the tool as we're hearing it from our project users, and to review our highest priority requests and their statuses and if they have been included in their release planning for upcoming releases.

We have a pretty good dialogue going back and forth with them, so we know when to anticipate the functionality that we're looking for is going to get delivered. That helps us when we're making decisions around which upgrades to take.

Tech support does a pretty good job. Sometimes it's a little frustrating because they're the Level 1 support, the helpdesk support. They often are trying to rush us to close out tickets. I understand that they've got metrics, but that part is a little bit frustrating.

When we get it escalated, when we're working with their research and development or with the customer service contacts that we have, they're much more amenable to our requests. They like listening to what we need and the type of support that we're requesting. They take us pretty seriously when we escalate and have high priority issues, and they really try to get us resolutions as fast as they can. We definitely appreciate that.

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.

I don't do the software installation or that side of things, but in terms of our implementation strategy, we have four environments in which there are seven servers. In our lower environments, our base environment, we have one server that gets installed. 

We don't have any integration that we support currently, so it's a standalone environment. We do integrate into an Elasticsearch farm, as well as to LDAP for user creation, password validation, etc. We have those basic types of integration setup, but we don't have integration to other tools such as DevOps tools, yet. We are currently working on integration to PPM, and that's going to be deployed in the next couple of weeks.

Once we get up to our stage and production environments there are multiple servers on a load-balancer, so that adds an extra degree of complexity to the setup. They're also externally exposed to the internet so that our clients and external users can have access to the tools.

It was just us and Micro Focus.

We did not evaluate other options before choosing Octane. At that point, we were in pretty deep with HPE. But before we chose HPE as our vendor for the bulk of our enterprise tools, we did an evaluation of different vendors, different suites of enterprise tools that we could possibly host, before we made that decision to go with ALM and AGM and UFT.

The way that we approach it is that we don't rush into a decision and say, "This is the tool that we have to use." One thing that's nice is that there's always an option for a SaaS trial for 30 days or 60 days. Micro Focus has been very kind to us and given us extensions on our trial versions so that we would have enough time to evaluate the tool and the SaaS version before we make a full, educated decision about how we want to move forward. That's a good place to start: Plan on getting a trial version and plan out your assessment, what your objectives are, what your requirements are for the tool, and then just get in there and start using it.

I use Octane in my day-to-day work, but I'm mostly an administrator of the tool's usage on our consulting projects.

With respect to how tools and processes are evolving to adapt to the change from traditional Waterfall, one of the things our organization is finding is that it's not a switch that you turn on - that you're "traditional" one day and you're "Agile" the next. So, having tools that are flexible enough to accept variability, and that are flexible enough to adjust to project teams transitioning and becoming more Agile as they go along, is important. Octane, because of some of the additional features that are there and that are not in some of the other Agile tools we've looked at - like the Quality module, the quality story, the ability to customize workflow and business rules, and also having the Requirements module - lets you still be a little bit traditional when you need to be, while you're learning to become more Agile. There's some transitioning that the flexibility in Octane lets you do, where other tools might be more rigid in enforcing pure Agile project management.

As for lessons we've learned about adapting tools and processes for Agile, I feel that's very similar to what I just said. It's this journey that people are on. Where we started was with very traditional project management tools and, as Agile became more the trend, we recognized the need to add more tools into our landscape that would support it better.

The way that we work is that, while we host all of these enterprise tools, we don't enforce that these are the tools that are to be used on projects. We have to be a bit more flexible than that. Recognizing the need to have enterprise tools available for project teams that couldn't find their own tools, or clients that didn't have their own tools, that's where we brought in AGM and then, eventually, Octane when it came onto the market.

The other thing that's helpful to recognize with this transition, is that you can't become Agile on day one, once you make the decision that's the direction you want to go. It's very good that we have the ability to integrate our more traditional project management tool with our Agile tool. Currently what we support for project teams that are doing a bit of both, what we used to call "hybrid," is their integrating of their Agile project management tool, like AGM or Octane into a traditional workplan tool like PPM so that they can see the full breadth of their project progress across both more traditional tasks and Agile tasks in a single place. We're bridging that gap by using multiple tools and integration.

In general, ALM tools help in the transition from Waterfall to Agile because you have a tool enforces some processes, and provides a little bit more rigor than you would have otherwise. Having those ALM tools available has helped us enforce some consistency and adherence to Agile processes.

To date, we've had 136 projects, that's 136 workspaces, and about 1,000 users.

In terms of increasing usage of Octane, we deployed AGM and ALM four or five years ago. The problem in our organization - and this is another thing we've talked to Micro Focus about, and they're hearing similar feedback from other places - is that people are used to what they know. If people have used AGM or ALM on a previous project, they're just going to go with that.

We do have some early adopters. People have been keen, they've heard about this new tool Octane, checked it out, and those early-adopter types were on the bandwagon pretty soon. There are some people that are lagging behind and kind of skeptical. We're dealing with the psychology of that. Part of that is knowing there is not really a great reason for us to continue supporting two tools that do very similar things. AGM and Octane have a lot of overlapping capabilities. We're looking at our strategy for how long we want to continue to maintain and support two tools that do the same thing.

We're trying to encourage people who are used to using AGM, or are leaning more that way, that they should come over onto the Octane side, because that is the direction that the vendor is going in. That's where the investment is going, and that's where all the new functionality is coming out. We're trying to increase adoption in a variety of ways to get those people onto the Octane side.

We have an assessment planned early next year to strategize when we might scale down AGM, and maybe even cut off provisioning new projects, but we don't know the timeframe of that yet.

In terms of maintenance of Octane, their roles are project manager-types, people who do the server administration, and DBAs. There's also a QA group and a PMT group that we enlist on a very short, annual basis to do our performance testing.

I would rate Octane at seven out of ten. There's definitely some functionality that I think could make our lives a lot easier, especially around the extraction of data and the reporting. Those things would really help us out. I'm conservative on rating things.

We are in the middle of a pilot, an evaluation. We have been evaluating the software for about 13 months.

Our focus, at the beginning of the evaluation, was to probe a BDD approach with Gherkin to help us track the end-to-end process from requirements to test automation, without leaving quality aspects behind. That's the first use case. The second use case is that we want to optimize the traceability and integration within the Continuous Integration and Delivery process.

Throughout the evaluation, we've sensed that we have better collaboration among these three roles, the business, the testers, and the testing automation engineers or the developers. From a functionality point of view, we have been able to execute more testing automation on this particular pilot team because of the integration between the tools.

These are things we can see from the daily work between the teams. It's a feeling that everything is moving a little bit faster, it's a little bit easier.

Right now, we have a lot of tools facilitating the BDD syntax but they are scattered. For example, the product owners are working with JIRA or other application products, like Confluence. The developers are working inside their IDE. And the testers are working somewhere else, for example, on ALM.NET.

We thought the possibility of having a single platform which can connect all three roles, centralize them into one platform, would be helpful. It's quite difficult because if you write the feature files first in JIRA, for example, you have to copy the content of the feature files to the testing tool. With ALM Octane, it is possible to have synchronization between JIRA and ALM Octane, if we are using both tools. But there's also the possibility that we use only ALM Octane for both the requirements management and the testing.

By clicking a button after we have the feature files in ALM Octane, we can send a message directly through the IDE plugin of ALM Octane - for example, for ItelliJ or Eclipse - to inform the testing automation engineer that this test is ready to automate.

In other words, it would allow us to keep each of the roles flexible. So the product owner could work in JIRA, the testers in ALM Octane, and the testing automation engineers in their IDE. But we wouldn't leave the consultation aspect behind.

It's hard to say which features are the most valuable because all the features are really fantastic. What distinguishes the ALM Octane from ALM.NET is, first, the Pipeline module because with the Pipeline module you are able to integrate with the CI server.

The second point is the support for the BDD Gherkin syntax. It's valuable because the point of BDD, I'm talking about the "culture," is to optimize the collaboration between the business - the product owners - the testing, and the development. We are pushing them to speak the same "language."

First, the Requirements Module could be better, to build up a better requirements process. There's a huge improvement from ALM.NET to Octane, but it's still not really facilitating all the needs of the product owners, to set up their requirements in Octane.

Second, because JIRA is a leading tool for both development and requirements management - everybody is using JIRA - I'm pretty there will be a use case where people are trying to connect between ALM Octane and JIRA. The back-end configuration of the synchronization with JIRA could be simplified. The architecture is really complicated. We required a lot of machines to build the cluster and the configuration was not really clearly described within the documentation. This may have something to do with the fact that the software is pretty new.

I addressed this with the vendor, but a solution was not really provided. However, I saw just today that they are creating a collaboration platform for people who are evaluating ALM Octane. That's a good start to facilitate this but, as I said, because the software is pretty new - it's only two or three years old - I expect that some things are not really completely optimized. I'm pretty sure it's going to be better in the future.

In terms of performance, I haven't had any complaints. It's really performing well. But I'm not really qualified to judge it because, for the last 13 months, we have only been working with a handful of people, with one team, some 20 users at most. For 20 users it has been really stable. We'll have to see after we have, say, 2,000 users working all at once in ALM Octane, how the software actually performs.

For this particular software, the support is very good. We have direct access with an R&D colleague from the provider. They are not only reacting to our requests but also providing some insight and tips about the tool.

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.

It was pretty straightforward. Everything was written in the documentation, down to the smallest details. The package was as an RPM package which was good for our administrator in doing the installation. The only thing that bothered me was the configuration of the .YML file. It was actually really simple, according to what they described about what to configure there, but there were some delicate points that we had to pay attention to. Other than that, everything was really good.

The installation itself only took our administrator a few minutes. If I hadn't had problems with the .YML configuration, it probably would have taken me a couple of hours to complete the installation.

The onboarding, the transition from the old tool to the new, is quite a challenge though. We have been using ALM.NET for ten years or more. We are still finalizing the pilot, but our thought is that if we go to Octane, we would prefer to go with a greenfield approach. It's not that we're going to migrate stuff from ALM.NET to Octane. We will just start fresh, from scratch, in Octane. 

The reason is that the tool provides really good functionalities for us, especially for testing. It's good to take a chance. There will be a review process and we'll try to really integrate the process with the tool.

For us, the initial setup involved three to five people, until the application was ready to be used. We have been maintaining it for 13 months with two people, myself and the consultant.

For the deployment, for installation and configuration, we did everything by ourselves.

But we are working with a third-party, a consultant, for the customization. Compared with ALM.NET, ALM Octane doesn't have a full scripting capability, so everything is really defined as business rules. This is quite a change for us. Therefore, we need a partner to provide us with some guidance and tips.

The consulting firm we're working with is profi.com AG. Our experience with them has been really good. I have no complaints.

You have to take into account all the costs. Right now, we are using ALM.NET. If we decide to go to ALM Octane we will have migration costs, we will have costs for integrating other tools. If we stay with ALM.NET or go for open-source tools, we have to evaluate the same cost factors.

My guess is, if we go to ALM Octane, and considering all the features that ALM Octane provides, with the open architecture, that would mean we don't have to buy more plugins. We could gain some financial advantage from implementing ALM Octane.

It will be as expensive as ALM.NET, if not more expensive. But here's a good tip: If you have ALM.NET, you are able to share your licenses from ALM.NET to Octane. You just have to define a dedicated number of licenses on ALM.NET and then you can share them with ALM Octane, with some configuration effort. This is something that you have to take into account, that there is a possibility of such license sharing that could decrease your costs.

Compared to open-source tools, the price the ALM Octane is definitely higher, in terms of the licensing cost.

We are doing a lot of other evaluations; for example, the possibility of using direct JIRA backends for testing. In addition, but not in the same magnitude as our evaluation of ALM Octane, we're still looking at the possibility of holding on to ALM.NET longer.

As I said, it's best to involve all the stakeholders, for faster implementation, because it's new software and they need to be on the same page and have the same understanding of the software's concepts. In addition, assess what you need, your process, and if the tool can fit into that process.

What we did was create a requirements catalog, with a list of all the requirements from the non-functional point of view and the functional point of view. Then we started to evaluate the software based on these requirements, which were created together with the stakeholders. We had interviews with them. That was very helpful because, in the end, you have to see that the tool is providing value for you, based on your requirements.

I would recommend that you do a pilot with a team that is mature enough to work on the tool. Instead of just looking at webinars, it's better to have a pilot with a team that is really able to work on the tool. That way, they can really see, first hand, how the tool is working, if it's going to be able to be integrated with the process.

We are trying to implement Agile methodologies in DevOps right now. In terms of how our tools and processes are evolving to adapt to the change from traditional Waterfall development, it's quite difficult because we have been working with the classic Waterfall method forever. It's not just about the tools, it's about the process first, and that the people have to be on board with it. In my role, what I can provide is delivering one tool that is able to support this transformation.

We are evaluating the possibility of Octane replacing ALM.NET because ALM.NET does not really support Agile software development and continuous testing and because the workflow process, itself, is too rigid. In addition, the effort involved in the maintenance of the application is really big. That is especially true when talking about the software updates. And then, ALM.NET has a complex UI, it's not user-friendly. In addition, there's no lightweight integration possibility between ALM and open-source tools. 

If we look at these features that ALM Octane provides, and that ALM.NET doesn't have, that is one thing that we can contribute, from the tooling point of view, to support the transformation. But you cannot easily say that the transformation of the whole organization depends on just one aspect, like tooling, because it also involves the process and the people.

When it comes to the biggest lessons learned about adapting tools and processes for Agile DevOps, I think it is really important, in the scope of evaluating ALM Octane for a transformation, to have all stakeholders on the same page, and to have their opinions and experience included. In addition, define the process first and then go on to the choice of tool.

Regarding how ALM Octane can help us with the transformation from Waterfall to Agile, we'll still have both methodologies. We're not cutting off one method. We'll have to live with Waterfall and Agile. But for me, Octane will be like concentrating on the core competence, meaning we eliminate waste in managing the software application, for example, by simplifying the workflow. That is important.

One issue that people forget, when comparing, is that if we are going to update the ALM.NET software, we need at least three hours to do it. With Octane, it took me one minute to update the software. That kind of waste with ALM.NET can be avoided.

The second issue is that it's important to consolidate information, especially from the testing, defects, and requirements areas. Right now, with ALM.NET, it's not possible to integrate it easily. Everything is possible. You can always do something to create integration between two tools, but it's going to take a lot of effort and resources. In the end, it's all about money. If we are able to consolidate information under one roof, by using ALM Octane and its lightweight integration feature, that will help us with the transition from Waterfall to Agile or, at least, from Waterfall to both methodologies.

After we are done with the evaluation, the next step will be to deploy it for the organization. We are piloting this software with one scrum team. The next step will be to bring more scrum teams on board with us.

I rate it an eight out of ten and, for a new product, that's quite good. Overall, it's really good software. I haven't seen anything like this in a long time. But there are some limitations right now: What I mentioned about the architecture of the JIRA synchronization, that it could be simplified; and the documentation could be better. Those are small things that could have been better from the beginning. Other than that, I really have no complaints about it. Those are just some configuration and set-up things that could be better. If those factors are eliminated, I would give it a ten.

My company has several scrum teams, so we use OpenText ALM Octane for sprint planning. My company also uses OpenText ALM Octane for test management, quality management, requirements management, deployments, engineering purposes, and some automated testing.

The most valuable feature of the solution is that it is a one-tool solution, meaning you have everything you want in one tool, so you don't need to switch to other tools.

I think the area of release management in the tool is an area of concern where improvements are required. In general, the connection between releases and scrum teams needs improvement, as it could be optimized owing to its linkages, making it very uncomfortable as soon as you have strong teams or scrum teams that work with different items over several releases.

In future product releases, the solution needs to focus a bit more on the metric part. The product's dashboard is a metric for productivity and process control.

I have been using OpenText ALM Octane for four years. I use the solution's latest version.

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

I don't see any limitations in the product's scalability. Scalability-wise, I rate the solution a ten out of ten.

There are more than 1,000 users of the product in my company.

The solution's technical support team is responsible and helpful, but in our company, we don't require much help in relation to the product as we are able to manage it by ourselves. The solution's technical support is good.

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.

The product's initial setup phase was straightforward.

The solution is deployed on an on-premises model.

The time for the product's deployment phase is something that depends on how much of the product a user wants to use. In my company, we actually indulge in the product's onboarding process team by team and project by project, meaning it's not about just implementing the product all the time but moving in a step-by-step manner.

Around ten people who take care of administration and engineering areas in our company take care of the deployment and maintenance of the product.

I would say that it is an affordable product. There is an annual service fee, which is one of the additional payments to be made apart from the standard licensing costs attached to the solution.

I recommend the solution to those who plan to use it.

I really like the progress made by OpenText ALM Octane since I have seen many features being introduced lately. I believe that there are still some features left to be introduced in the solution. I would be happy to see some new features in the product. I would like to see the product offer some optimization to users, along with some improvements in terms of metrics and dashboards.

I rate the overall solution an eight out of ten.

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. 

It's for monitoring the application lifecycle for quality and testing in an agile methodology.

The enterprise view for application management has been great.

It’s easy to set up.

Generally, we’d like more adoption of the solution in our industry.

We’d like to see Platform One/Iron Bank compliant containers. These are certifications. Certification for Platform One and specifically for the product ALM Octane, Platform One/Iron Bank certification would be ideal. My understanding is it just so happens that that's the roadmap.

The clients have been working with it for 25 years.

The solution is very stable.

It's extremely scalable. It's an enterprise solution for lifecycle management.

As a rep, I’d always like to increase usage. In general, there's a total direction to increase exposure to ALM Octane.

I have experience with technical support. For secure clients in the US, domestic in-country support is outstanding.

If you're just doing the regular follow the sun, there could be issues with support availability. However, if you use premium in-country support, you won’t have issues.

The product management and the Go Octane support, which is the migration to Octane, which is not an in-country that is now going and leveraging the Go Octane team is also outstanding.

I'm working with them right now with my customers to migrate from their Al Octane. They're right on target, with a lot of cool exposure. Clients have been satisfied.

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.

The initial setup is straightforward.

There's a migration SHIFT from ALM to Octane that is straightforward.

I don’t have any specific information about ROI.

There’s such a large investment in scripts built for these. To recreate that content in other products would be a disadvantage economically to pursue once you have the legacy products. It would be very expensive to get a system integrated to do so.

As a partner, we offer perpetual licensing as well as annual or monthly subscription licensing.

I’m not sure how it compares to other products.

There aren’t any additional costs that I am aware of. It may be different with different deployments. However, customers in the security community have their own secure cloud, and so they just install it there.

I've had my customers look at ServiceNow, DevOps AddOn as well as Jira, and Zephyr.

I don't want to limit our sales. However, my clients were ALM customers and they said the best choice coming from ALM was to migrate their projects to Octane instead of moving over to a new platform.

Micro Focus is an English company. We're a small US-based company that is a master reseller for all the Micro Focus products. I sell the product. I'm a vendor.

I’d rate the solution ten 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.