OpenText ALM Octane Reviews

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.

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. 

ALM Octane is used to manage our software delivery. Currently, we are running the hybrid mode. We use traditional waterfall delivery as well as agile. 

• For waterfall delivery, it is managed completely. Then, we have our requirements and our test cases to cover those requirements as well as the defects. 
• For agile, we currently have only one team. So, all team activity happens in ALM Octane. Their backlog is broken down into user stories tasks, then covered by the test coverage.

We have installed it on a Windows Server on our systems.

ALM Octane natively supports waterfall, hybrid, and agile software development perfectly at an enterprise scale. 

1. If you look at the Requirement module, then we see all the defects and test cases related to waterfall. 
2. If we look at the Backlog module, we see what the agile team works on. 
3. If you want to see it at the component level, then imagine that we have a CRM system where a release project of waterfall makes a delivery and the agile team also makes a delivery on that component. 
4. We come to the Quality module, where if you select that component, then both streams would be represented there. 
5. If you select in the Quality module components, then we could see that, "Okay, this is linked to the defects from this source and that source. These are test cases covering that." 

This was one of the key aspects of why we took ALM Octane. 

With ALM Octane supporting agile, this reduces complexity and the need to manage multiple tools. We are still working on some automation that would further make us more efficient. So, we are building in-house tools to reduce the manual work.

Our user experience has been greatly improved.

In the current organizational structure, our development teams and testing teams are separate. With this transformation, I think the collaboration will increase, and we are on our way to put these teams closer.

We are very much moving towards DevOps in certain parts of the application. We are starting to develop these microservices and running a proof of concept where we want to integrate our Jenkins pipeline, which builds and deploys the application into Octane. For example, if there is a defect in the content, then what defects are being deployed through this pipeline? Octane really supports DevOps with the Pipeline module using the comment information in the items, along with integration from the IDEs. So, once our PoC is done, then we will utilize the DevOps features.

Currently, we have our hybrid delivery model, where waterfall still is a big part. So, if I look at ALM Octane from the module perspective, we are utilizing this requirement module. We took our day-to-day, grouping them by releases. Our requirements are stored in Confluence and ALM Octane. So, our project managers draw their requirements in Confluence, then we have a synchronization where requirements are brought into ALM Octane. Therefore, from the module perspective, the most valuable feature would be the Requirements module. 

We utilize dashboards for all their reporting capabilities to see where our software is from a quality point of view: test progress, defect trends, and so on. 

We are big fans of the Pipeline module, where we have our automated tests running on Jenkins and our pipeline is integrated into ALM Octane. 

Octane provides multiple plugins and integration with IDEs, so developers don't even need to log into ALM Octane, for certain scenarios. They only need to install the plugin into their development environment, i.e., Eclipse, Visual Studio, or IntelliJ. Then, they can sync their work items to this IDE where they can easily see what defects or user story is assigned to them. They can work directly from there by adding comments, changing the status, or even committing the code. This also applies to the pipeline for Jenkins. 

There are a lot of predefined reports. We can attach additional reports for users, like who worked on what defect and when, as well as what is the status of the release compared to the previous release. It is really endless. All the data is really linked together. Then, if all the data is linked together, there is an option to prepare reports out of it. We are very impressed with its reporting capabilities.

They provide all data integration. So if you have an edge use case, which you cannot do with what the tool provides, then you can set your data through all the protocols and even prepare it for the reports. I think they are very strong in this area.

On a team level, it is really good. We have received only positive feedback from our teams. It is visual, so there are different ways for teams to see their backlog. If they wish, it can be viewed like a list and a board, where you can look at the content per screen, release, or for the whole backlog.

The tool is very intuitive. However, it is still new, so you still need to learn and explore it, but that is a standard thing. Initially, we did receive some questions from teams, "How do I do this?" and, "How do I do that?" However, in very recent times, since it has been up and running, teams have enjoyed the fast, modern, new platform.

For the PoC, we have ALM Octane integrating with our CI server for continuous integration and delivery. We have it integrated with Jenkins. We haven't integrated our other server yet. We are still exploring the solution.

ALM Octane is working to soon provide comment information, so we would really be able to see what piece of code was committed for a user story or feature. We are really looking forward to this, because it's going to give us a bit more traceability and transparency.

They don't support all IDEs yet. We have Visual Studio code, which is not supported, and loved by our developers. This integration is missing. We also had to do our own in-house integration with the Confluence. That is also something that they could add. 

There are small things, like hiding different columns when it comes to the board. Currently, whatever workflow items you have defined in the board, you can collapse them, but a collapse line still appears. These small things would make a difference.

In certain areas, ALM Octane has a limitation how many items can be displayed. So, if I group something, then I'm limited to the number of items which I can see. Also, if I want to export in Excel, there is a limitation onis lines. I know it's 5000. Maybe the number is quite high, but if they could improve on those limits, that would be good.

We did a migration around Midsummer. That was about six months ago.

It is very stable. With our current setup, we haven't seen any performance issues.

Very little maintenance is needed. No one does it full-time. We have five people who have the admin rights, then two people who act as a backup but don't really do anything.

It is scalable. We can add additional nodes without a lot of effort, if it is required. There is an option to scale from a license point of view. From a hardware point of view, we can also add multiple nodes to support additional loads.

We have about 1,000 users. 

We have an excellent guy who helped us with the whole migration project. We have already built a good relationship with him, so much that we don't always go through the official channels. He still takes our questions via email if we need the clarification on certain things. Additionally, the official OpenText support channels are also good. We raised a couple of incidents, which were addressed by the team. 

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

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

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

The deployment was straightforward. The documentation clearly states the requirements regarding what hardware is required. Additionally, all the installation and deployment guides are good.

The deployment went through phases. First, we installed the system, which was pretty fast. After that, we migrated all the data from Quality Center, which was an additional task.

The upgrade was super fast. We were so impressed. We ran a test first, but after that, it took maybe 90 minutes altogether. That includes the backup of systems. Before the upgrade, we backed up our Elasticsearch because ALM Octane comes with Elasticsearch, and in our case, it runs on Unix machines. So, we backed up Elasticsearch, the data repository for all the attachments, etc., then took a snapshot of the database and the Windows machine, which was the longest part. Some of the snapshots, we did in advance, and some of the snapshots we did just prior to the upgrade. 

We did two upgrades at once because we missed the previous one. The upgrade to 15.1.20 took about 10 minutes, then we did some checks and everything was working fine. We then did the further upgrade to 15.1.40, which was another 10 minutes. 

One person with a bit of hardware knowledge can do the deployment. Because we did a migration project, we had a team of four from release management, but this wasn't our full-time task.

We also had support from OpenText.

The testing team has said that can work more efficiently and that the setup of the testing at the beginning of the release is faster.

We already had Jira in-house, but its testing capabilities were insufficient and not scalable enough for our needs.

Define the process which fits your organization best. Explore the features in the test management and test execution area, then define the process that is best for you because there are a lot of options. Also, when you do create your data, make sure that you connect it to the right items. Because once you put the correct data into the tool, then you can build strong reports. However, the reports are only as strong as the data behind them.

MF Connect, which is a separate tool from OpenText, provides additional data synchronization. With MF Connect, you can synchronize ALM Octane with Excel, Jira, and other tools. We use it for synchronization with Jira. Then, if this doesn't support your needs, there is also the REST API. We use that quite a lot as well. Through the REST API, we connect with things in different solutions.

While our manual testing time has been reduced, it is necessarily true because of ALM Octane. It is more due to a bigger initiative where we have automated our test cases. ALM Octane supports our automation initiative. With the pipelines, we can execute test cases through Jenkins, then the analytics in the pipelines give us a trend to see. For example, are certain test cases constantly failing? Or, do we have a problematic area where we need to strengthen the automated test focus?

ALM Octane would give us information on what exactly went into which release and what exactly needs to be rolled out. For all our test cases that need to be executed for the release, or on the release night, we would hold information within ALM Octane.

We are planning to increase usage in the future. Currently, our other agile teams use Jira. The goal is that if we do not migrate those teams to Jira, then we should at least integrate both those tools together. We would then manage all the agile work within ALM Octane. Also, our organization recently got acquired by another organization, so we are in the process of merging two companies. Therefore, there potentially will be a lot of additional users going forward.

I would rate it as a nine (out of 10).

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

I like the fact that you can use it on top of Jira. 

Let's say for example, that if you have a DevOps team that is used to Jira, they can continue to use any of the Jira solutions and then have Octane layered on top of it from the business buyer's viewpoint to better use it more effectively.

There is no question that everything can improve.

I like their smart analytics; perhaps they should continue to expand and improve there because it's a fantastic start. And I enjoy the testing, especially the automated testing capabilities, so just keep improving on what they have.

I have been working with Micro Focus ALM Octane for one year.

I am reviewing the latest version.

Micro Focus ALM Octane is a stable solution.

Because of HPE's support, I would feel far more comfortable with Micro Focus.

Micro Focus ALM Octane is a scalable product.

We have approximately 500 clients who are using this solution.

They are large enterprises and digital transformation, IT engineers, more business-oriented than DevOps-oriented.

We have not contacted technical support.

We are working with the Hybrid version, but It even extends to on-premises. It is both the on-premises and cloud versions.

The initial setup is straightforward.

I believe it depends on the circumstance, getting it up and running seems to be rather simple. It appears to be suitable for standing up in a bigger setting.

If I compare it to Jira, for example, and you are in a complex environment, you have to ensure that everything is updated and all of the plugins, and everything works every time there is an update, but you don't have that problem with Micro Focus' Octane.

We received assistance from a third-party consultant.

Because I am making recommendations for a client, I lack firsthand deployment experience. I am merely talking to them and assisting them in making decisions.

My clients have seen a return on investment. I can't quantify it for you, but they believe that because it is cohesive and can be used across the enterprise in a simplified manner, it reduces the total cost of ownership, which might be translated into a return on investment.

In my opinion, it's good value for the price that you pay.

I have some experience with Jira and Micro Focus ALM Octane, but I am mostly reviewing them to give a recommendation for a client.

I would suggest reviewing it thoroughly to make sure that it is a good fit for your environment.

I believe it works well in a variety of settings, but like with any solution, some are more suited to some situations than others. I believe it is trustworthy, reputable, and scalable.

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

Its user experience made us a lot happier than using other tools, making it easier for non-IT teams to work together with IT teams.

Octane provides us with a single platform for all automated testing. Our test management is a lot more transparent and successful because it includes the team (the non-IT user and the developers). We are more streamlined and running a lot faster. The single platform for all automated testing has 100 percent affected collaboration between development and testing teams because everything is all in one place.

Octane integrates with your CI server for continuous integration and delivery. This makes us go faster, providing overall transparency during stages or phases.

The solution provides a single, global ALM platform that supports all our agile and waterfall needs. This has improved the overall quality of our DevOps by a lot.

The user experience is a lot better than any tool that I have used before. Overall, it is great. It has a smooth interface, which is very user-friendly. It makes it easier to work together and have more transparency and customization, which is very good. There are a lot of features where you can add fields, input individual fields, and input rules, like templated rule-based interaction between entities. 

The Backlog management is really interesting, because it is all in one place. You don't have a feature here and a feature there, instead you have the Backlog and testing using different backup items, like user storage features and tasks, all in one place. In addition, we are able to write documents, which we can transfer to backup items. Then, we can test them in the same solution without switching tools, or even switching from one part of the tool to another part, because it is all in one place.

We use the solution’s Backlog and Team Backlog capabilities. They make our DevOps processes easier through transparency and asset collaboration.

It could use just some small improvements. I would like additional features, like planning features, user story mapping, or connection to collaboration tools. 

We have been using it for two years in a client company. We have also used it for several of our teams as well as IT related product development.

We have used it now for two years, but only in the last six to 12 months have we really been going all in.

The stability is perfect. We haven't had any issues.

We are not using the most recent version. There are two more updates, and we are already thinking about updating to the newest version.

The scalability is excellent. I don't think there is a limit.

We use it quite extensively. We have about 30 teams working on it with approximately 10 projects, and we are definitely expanding.

The technical support is really good. I would rate their support as a nine out of 10, as there is always room for improvement.

We do use the community that is offered. This is a very good point for identifying issues in terms of how we can use additional features.

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

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

The initial setup was absolutely perfect and very easy. It was fast getting into the work. We were up and running in a very short amount of time. We switched from one tool to another in days, which is very good. 

We did it ourselves. Just a couple of people were involved in the deployment.

Octane has reduced manual testing time in our organization.

The solution has reduced our testing costs.

It has reduced integration costs by building a streamlined application delivery pipeline connecting to all IDE, CI, and SCCM tools.

The solution has helped us to produce releases faster. 

We did not really evaluate other options. We were introduced to Octane and found it to be a good idea.

OpenText ALM Octane natively supports waterfall, hybrid, and agile software development at an enterprise scale. There is no difference based on whatever path that you are trying to follow. You have work, and if you do it in cycles and iterations, that's fine. If you don't, that is fine too.

The solution provides out-of-the-box integrations to proprietary, third-party, and open source tools. However, we are not using DevOps integration right now.

I would rate this solution as a nine out of 10. 

We are only using the Quality testing module of Octane to test newly developed mobile solutions or changes. For example, if someone wants to deploy a new promotion of a cheap bundle for 1 GB of 50 ram. Once that goes through the project management and comes to us, we use mostly these three Octane modules: Backlog, Quality, and Pipelines. 

My team has benefited a lot from this solution. Sometimes it can be a massive, gigantic project where it's a migration from one system to another. Because we already have the requirements and the test kit setup on the system, it is easy for us to run regression.

The solution natively supports Agile-Waterfall hybrid software development at an enterprise scale. This is very important to us. Because even though the company wishes to go Agile, we still have projects which follow a Waterfall methodology. In order for us to accommodate both, we needed some sort of hybrid system. Because if we are using a fully Agile system, then the reporting might not be correctly extracted.

At the end of the day, teams are able to collaborate because we are working on one thing. One person can do their part of the job, then another person picks from there and carries on. So, it runs as a smooth process.

Even though there are other people who are not using the system, if we would give them access to the project management, then they would be able to trace where we are at any point in time.

I like that most tests are usable. I can parameterize, then use that test and pass a new value.

Its ability to handle a large number of projects is very good. I can just cross-reference and reuse what was existing before, instead of moving from one browser or application to another.

Octane's ability to connect all related entities to reflect project status and progress is great because even our team who runs external tests from Jenkins that the reporting is centralized. Because it was run from within Octane, the results come back into Octane. However, since I am not using those external systems, I only get results whether the test passed or failed.

The solution provides us with a single platform for all automated testing. It combines everything so someone doesn't have to look into many systems to be able to check this or that. They only have to log into one system to check for a particular requirement.

Backlog is like a library of our tests. It contains the features linked to the tests, so you can see which project or feature that you are working on. It is all in one place and everyone who needs it has access to it.

The reporting needs to be improved and allow for customization. I want to build my own widgets, but I don't want to use the ones already in the system. I want to build mine from scratch.

From the database point of view along with how we see the reporting, they use old data. Also, there are sometimes limitations due to their license restrictions. If we want to share our tests with other teams, extracting different tests out of the system, those tests come out as a script where the content will be something like a binary format type of text.

We started using Octane from February 2020. 

I do not know whether it is because we used an existing server, but sometimes the solution would be slow. Nowadays, it's much better because not as many people are logging into the system. However, I find it slow. When you capture a requirement or test (and it throws out an error), then when you refresh and find that it has created a duplicate. For some people who don't understand it, Octane can create a lot of useless information on the system.

My team does just minor maintenance of the solution.

The extensiveness of integrations into the DevOps ecosystem in the 15.1.20 version to support scalability has been very applicable to our business. We have integrated the solution with Jenkins, which was user-friendly. We also integrated Octane with Qlik Sense and QlikView for people for whom we do not want to give access to the system but want to have them viewing our reports. Therefore, I think the scalability is very wide. 

On my team, there are 18 users who are testers. Overall, there are 20 licenses.

We have used the technical support, and they are very good. 

There was a time that the server firewall was enabled, so we could not access the system from our side. Since we were working from home and connecting remotely, no one was able to establish regular shipping. Eventually, the IT person and our team went through everything. They checked the server settings and pinpointed the problem. 

We did an upgrade of our ALM from Quality Center.

Our team is saving time on testing by using Octane. Something that would take five days to do, now it takes one day.

The solution has helped us to produce releases 40 percent faster. 

Going forward, I think we will want to explore adding more licenses.

We have used more of a requirement-driven tool, where it will help you to identify which requirement already exists. Then, you don't capture duplicates and it directs you to the project that is linked to that particular requirement. 

We also use Jira at a high level for projects.

We don't use the security features of this solution yet, but it is something that my boss wants us to tap into.

Systems and technologies are evolving as well as methodologies.

I would rate this solution as a nine out of 10.