OpenText ALM Octane Reviews

We use it for application lifecycle management.

We had projects in which we had the Agile part in a specific tool and the testing parts in another tool and it was very difficult to synchronize all that together for a reasonable price. Of course, you can buy tools to synchronize the different tools together, but to buy synchronization tools is very expensive. You have to handle that and if something is badly synchronized, you have to redo it by hand. So to have all that included in just one tool really makes our life easier.

Another benefit is the integration with Continuous Integration tools. Before, we had to upload all the test results either manually or automatically, but we had to write the scripts for that. With Octane that's just native, included in the package.

Finally, it consumes fewer resources than the previous tools in Quality Center. We have the same number of users but with half the servers. It's really economical from that perspective.

The most important feature is the integration of all the different features in just one tool: Agile management system, requirements management system, test management, defects management, automatic test execution. Really, if you're looking at other tools, you will never find all that integrated into just one tool with all the traceability, with all the elements in just one place. For me, that's one of the main advantages of Octane.

Globally, I don't see many major points of improvement. It's mostly plenty of little things, and it's weird to me that they are not in the product yet. They are really details, but they're annoying details. I'm sure all these features will be included in Octane in the following month or year because I talked with their R&D so I know they're working on it. But it's just awkward that some points are not there yet. 

Let me just give you an example. Today, in the tool, we've got plenty of assets we can handle, like requirements, user storage, defects, tasks and so on. And to all of those elements, we can add comments. We can add comments to any asset in Octane but not to tasks. It's just impossible to understand why it's not available for tasks because it's available everywhere else.

Similarly, for attachments, you can attach files absolutely everywhere except for automated runs, which is, again, awkward. I don't understand why for this element, in particular, you cannot do it. It's little touches like that. 

The Kanban boards are pretty easy to use and easy to configure. The only thing is that you cannot set a specific color for a specific card, depending on the value of the field. It's a really simple feature, very easy to implement because I implemented it in some other tools that I wrote. So I know it's easy to do. It would be really nice to have that, from a user-experience point of view, but we don't have it yet.

It's really little touches here and there that are missing.

We started from the very beginning with Octane, the very first versions that were released by Micro Focus, and the quality was really high from the beginning. We haven't had any major issues. It's mostly those small enhancement requests we are asking of them. But otherwise, it's working.

We haven't put scalability in place yet because of what I explained earlier. Previously, we had two servers for our Quality Center system platform and, with the same number of users, we've got just one application server with Octane. We haven't used the scalability yet.

We don't have a contract directly with Micro Focus. We bought our licenses through a partner, so we are not supposed to have direct support from Micro Focus. However, I personally know people from R&D, so I get support from them directly, although it's not the official way to do it. However, all the questions I've had have been answered very quickly and they are very efficient about it. So I expect that if I had a contract directly with them it would work like that. So support has been very good.

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

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

The initial setup was in between: not very complex, not so simple. Medium.

We are currently in something of an "in-between" situation because we are still using the old tool and moving to the new one. We have a transition period in which we need to maintain both tools at the same time. It's a difficult period with more work because we have two tools instead of one. We need time to move from the old to the new one. We will stop Quality Center, the old tool, in one year. At that point, things will be much easier and much more cost efficient than before, for several reasons.

First of all, Octane is automatable with APIs, so we have automated everything that we can for the users: project creation, user management, and the like. With everything automated via the APIs, we don't have to invest in people to support our users. That makes it cost-efficient.

Secondly, it's cost-efficient in terms of the platform. As I said, we use half the servers compared to what we needed for QC.

Also, a project in Octane can handle everything that is needed. We don't need to have two or three tools to handle different things.

It's also efficient because we have less training for users, and there is less expense for synchronizing data between one tool and another.

Putting all that together, it's really more efficient.

Pricing is the weakest point. It is expensive, but the tool has plenty of features. The main problem we have is that the pricing is very high compared to some other solutions.

We evaluated several solutions. One is called the Tuleap, which is open-source. Globally, it's a software development forge. The problem with that solution is that it's lacking test management, primarily. Then we tested another open-source solution made by a company named Henix, called Squash, which is a good solution, especially for open-source. It's just missing an integrated Agile management system. We also looked at JIRA but it does not have a test solution system and I don't like Atlassian politics very much.

Just jump in, go ahead. Don't try to understand everything before starting. The tool is really easy to understand for users. We don't even give training to our users today, they just jump into the tool and use it and they immediately understand how to use it, so it's very cost efficient for us. We need very few people to do training. Don't hesitate to use it, whatever your development methodology is. 

You have no obligation with Octane. There are plenty of features but you can use just a few of them and, after a while, when you get used to it, you can use new ones, and so on. You don't have to use everything at once and to understand everything at once to use the tool. You can just build on what you're doing and, month after month, use new features. Just go ahead and use it.

There is a free trial of the SaaS solution, so users can jump in and use the free trial to understand how the tool works, to see what it looks like, and so on.

I rate this solution at eight out of ten. I'm mostly positive about all the technical aspects. It's just loaded with features. It's very efficient. It works well, there are very few bugs. I don't rate it higher mainly because of the price.

It's the most powerful tool to do Agile framework. It's very lightweight, and the tool itself is built based on Agile methodology.

My favorite feature is the user interface, how easy it is. And also how the modules are segregated in Octane. It is based on the Agile framework so it looks exactly like how you would develop your applications using the Agile framework. You get into user stories, you get into Epics. Everything has the same names so you don't need to interpret what is what. You can get into it right away.

I say to our customers, "You can just get into the tool, and just follow the process." That means you are doing the job, like you got into the Agile methodology.

I like the flexibility that I have working with them, starting from licensing it. The SaaS aspect, the hosting that they are doing, the way they respond to our requests, the way that I can escalate. And the way that we are working with R&D right now.

For one, it's the whole Agile framework itself. You're cutting the time, the wait stage, and all that. We wanted a tool. You could do Agile methodology on a whiteboard, by using Post-Its. But practically that is not going to work out because the teams are in different locations. For example, our development team is in India.

So we have to have an enterprise level tool which can support everybody. So now we can create the same "whiteboard" and the "Post-Its" in Octane, and everybody can see it around the world. That means the people who support our service, the development teams in India. And the functional team sitting here in the U.S. It's the "collaborator thing." That happens using the enterprise tool.

I can't say, as I'm not completely technical. But we do have someone working with R&D directly.

We provide them feedback after they asked us for it. We are meeting once a month with the R&D team. And then we'll send them the list of things that our customers are asking for, or which are missing from ALM. And they will tell us, "Oh, this is coming in this release. That is coming in that release." And if there is something that is missing they will say, "Yep, we will include that in our next release." They take feedback from us and then do it.

I have some problems with the way they license things because HPE is a hardware-come-software organization. I think that will be solved by moving to Micro Focus. Yesterday I had a meeting with the executives and I told them the same thing, that I hope this is one area that I want them to be improving. This whole licensing issue, it's so complicated. They agree. They wanted to set it as one fits all. But hardware is different than software.

Right now it is pretty stable. The thing is, it is continuously improving every two or three weeks, they are releasing new features in Octane. We are one of the customers who started way before it was as a prime-time tool. So we are educating our customers telling them there are things that are coming. Also, we work directly with R&D to know what is new, what is coming.

For example, last month, we didn't have the testing module at all. In ALM we have the testing module. And our customers are so into ALM.net, and when they didn't have the testing module they freaked out. But we said, "Don't worry. It's coming." And it came within a couple of weeks. They got hooked up and they started working.

The product is stable. Whatever they release, it is stable.

We haven't tried scaling yet because we just started and we have about 20 projects in there which are not such big projects. But we haven't had any issues so far. We have confidence, after using ALM for so long, in scalability, the way HPE - before Micro Focus - are doing it. We hope that, they will do the same thing.

We are directly dealing with R&D in most scenarios. For example, one of the things is we are struggling with is to get some of the reports we want. It's not that flexible to get the reports because we are SaaS and we don't have direct access to the database to see how many users are live at a point.

But tech support are good. They are responsive.

It's straightforward. Because it's a SaaS application, we got access to the server. And then the URL was sent and we started using it. So it's that straightforward.

When Octane came to us it was a beta program. They said, "This not prime time yet." We evaluated a couple of other tools, like JIRA, which is one of the other tools that we have in our organization right now.

But the integration between JIRA and ALM wasn't there. JIRA is not our standard, actually. But we do use JIRA because developers really like it. What we wanted to have is the integration between tools. Right now we are using AGM in our organization, which is integrated with ALM.

So that's where we thought that Octane - even though it was a beta version at that time - we would take it and do a PoC and see if it works. And we thought it's really good because there is a lot of investment being done on the tool from Micro Focus.

We like how simple it is. It's easy for people to understand. Self-taught and they can work on it. A lot of our internal customers are using the tool even without formal training. They are self-teaching by going through all the resources. So we evaluated it and finally decided that it would be good to use Octane. We made that our strategy.

Comparing Octane and JIRA, I don't really know what the advantages are from JIRA. For Octane, it is primarily the integration with all the other tools that we have right now. And, as I was saying, it's simple to use.

And the changes - the way they are building the tool - we are part of the team which is building the tool. So we can always provide our input and make changes. We don't have that with JIRA. JIRA is there, but it's not used as a lifecycle management tool at all. We wanted to have a lifecycle management tool. So that's the reason.

When selecting a vendor, it depends on the product and how much they are investing in building that product. We don't get tools because we just like the tool. There has to be the need for the tool itself. It's important that they are able to support us and that they have good customer feedback or references.

If you are looking for any Agile tool, I would definitely recommend ALM Octane. Not only because it's a Micro Focus tool, but the way that they're investing in the tool. And the ease of use. Our customers were scared before, but now they are loving it. It's a really simple tool. And it's more powerful.

The fact that it works on all the different browsers, it easily integrates into all the other tools, and that it looks like it will work with our pipeline 2.0 with a kind of DevOps in mind.

It helps us go to the true DevOps model, which means we can do shorter cycle times. Go from releasing every month, to every day. It's got a nice clean interface that people don't mind using. It integrates into the developers IDEs, like IntelliJ, which means that everybody gets to work in the tool they want to work in. Then it easily integrates across, so everybody can see the information in any place they want to see it.

It's the idea of, how do you share testing microservices across different projects? Today things are separated into different projects. I want to understand what the vision is of how you're supposed to test those across, because everything's interrelated now. You're not just testing for one project or for one application. Many of the applications have shared services. How are they gonna do that?

The next thing is, how do you test deployment objects? So after you're done testing your stories, your features, you want to build a deployment object. I want to take those same tests in automation, and then rerun them, and understand, now I've tested them, but now it's a deployment object, and I've included all the code, and it could include scripts and database changes.

The stability is good. Granted it is a new product; we use the SaaS version of it. But it's been relatively stable, and we haven't had too many issues. They are releasing new versions of it almost every six weeks, and we really haven't noticed problems with that.

I imagine it should scale very well. We're using it kind of in a limited basis now, but going forward we're going to use it for a very large project with up to 100 testers. Because we're using the SaaS solution, and because we used the ALM HPE QC product before, and SaaS, I don't see any reason why it can't be scaled the same way. So, not too worried about the scaling.

Yes we use the tech support. We use the ticketing system through the tool. We also talk to our customer success person, and generally speaking, the support's been pretty good. The development team also sometimes reaches out to us and asks us, are there any features we'd like to improve, or if there are any issues with the products. It's pretty interesting. I never talked to the actual developers of a product before, and been asked what we're looking for, so that's pretty cool.

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

We did the SaaS version, so if anybody has loaded up Octane SaaS, you just put in your email and request a version, that's basically the setup. So it's just as easy as implementing any kind of open source tool, maybe even easier, because you have built-in support right there. It's extremely easy to do.

We looked at JIRA with Zephyr. We built our own internal one in ServiceNow. We also looked at something called TestRail. We went with Octane, just because of the reputation of HPE. It looked like everything they were doing was going the right way. We did an evaluation between Zephyr and Octane, and we really liked the interface in Octane. We just weren't really happy with JIRA, we were already using our own storyboard that we built in ServiceNow, so it really didn't make sense, and Octane just seemed like a much better choice.

When selecting a vendor, I think what's important is being able to scale to enterprise. Somebody that's going to be a partner, and somebody that's flexible and willing to help us. Some of the open source tools are great, but when you're dealing with an enterprise of $10 billion, you really want that real, dedicated support that you get from a dedicated corporation.

Regarding Octane, there are some features that it still needs, but apparently they are in the roadmap. I've given it to our most "open source" kind of DevOps developers, and they said, "Well, it's actually a pretty good tool." And these are the guys it was impossible to get into a test tool before. So just based on the adoption, it just seems like it's going to be much easier. So I'd rate it much higher in that sense.

I would say, you can go out and get a free trial of it, demo it. The integrations are extremely easy. Just try it out in parallel with production, and see how you like it. I think it's something worth looking at, and then understand the roadmap. And if you're truly going through a DevOps transformation, then this is a tool that's gonna align with what you're trying to do better than a lot of the tools out there.

My primary use case is as a test management tool.

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

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

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

I've been using this solution for two years.

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

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

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

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

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

I would rate this solution as seven out of ten.

Implementation of SDLC in large companies based on Agile methodology, with accent on test automation. 

Migration from VModel projects to Agile

We implement most of our test automation projects based on Octane. Very compatible to what customers need and I can deploy very fast. The projects start working from day one even with default configurations. 

We can deliver to customers a holistic view over all projects... an integrated view. In a company most projects are interdependent, the status view delivered live on all of them is very important. This is a big asset for us.

The most valuable feature of ALM Octane is an easy implementation of Agile projects. It perfectly respects the theory of Agile. If you fill in the predefined fields you will get a good implementation of your Agile project.

If I go in details a little we can offer insights to easy identify bottlenecks in the projects, overloads of teams, stagnating tasks, TRENDS ANALYSIS and based on this info we can improve the SDLC 

Areas for improvement would be installation and configuration. In the next release, I would like them to include simpler to read documentation or an installation engine like UFT or LoadRunner provide. I would also like to see integration with all continuous integration tools on the market, now it has many of them onboarded but this market grows fast and many other new CI/CD products appear.

Since it appeared

very scalable for Scaled Agile For Enterprises

I've only used technical support for very serious/difficult problems,  slower responses are normal in these situations. 

Positive

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

You need technical knowledge in order to install this product, the documentation is complex but it could be made easier to read

iQST is the vendor team... very good expertise

The investment in this product may not be cheap, but you can get high value out of it. Please consider consultancy to have a complete and detailed configuration tailored to your needs for best ROI

ALM is very compatible and has all the necessary integration. Octane is an improvement on previous versions because it comes as preconfigured as possible, which simplifies the whole process of integration in a company's ecosystem. When implementing this product, make sure to call in a specialist team who can make sure everything is configured properly. I would give this product a score of ten out of ten.

We use ALM Octane for lifecycle management and for testing.

The most valuable feature is the test lab. For example, we use it for both mobile testing and browser testing.

The interface is user-friendly. 

I would like to see the mobile testing improved so that we can simply select a mobile device, then specify what parameters we want, and the testing will be run based on that. This feature would be a very good addition.

I have been using ALM Octane for about eight and a half years.

We have not had any challenges in terms of stability.

This is a scalable product. We have more than 50 users in our company. Some of them are Q&A while others use a different license for development. We will very likely increase our usage in the future.

The technical support is really good. They have a support portal, which is helpful.

The initial setup was not complex. It was very good for us.

We have two people who are responsible for maintenance.

The look and feel of this product have improved over previous versions.

I would rate this solution an eight out of ten.

We use Octane to track our testing plan for projects.

Octane works well with the Jira portfolio to track the project with two methods: Agile and Waterfall. We can track all the testing in Waterfall or Agile and synchronize it with Agile tools.

The limitation of Octane is that we can't do a release outside of the sprint. We can only plan the release in the sprint. With Agile and JIRA tools, we can plan the release outside the sprint and do a global release of all the projects from the sprint. It would be helpful if Octane had a portfolio follow feature so we could follow the project portfolio. We need the all-view of a project to track it step-by-step and stay on deadline. 

We started using Octane two years ago.

Octane has been stable so far.

Octane is scalable. We're looking to scale up in the next year.

The end-user in charge of testing could easily deploy Octane, onboard new users, and train new users.

I think we can give ALM Octane an eight on 10. For now, we recommend using Octane to track the test plan for testing.

View the comparison document and quality of the document for informational and sharing purposes.

Octane creates a gentle approach to Agile-based projects.

The most valuable feature is CI/CD integration, and it is a good fit into the Agile lifecycle.

Improvements could be made by way of additional integrations across the lifecycle.