OpenText ALM Octane Reviews

We are using it for agile projects. Our company projects run using Agile models, so we use all the important modules of Octane, like Backlog, Epics, Feature, and user story in Tasks. We are also using the Product Backlog and Team Backlog modules as well as the Quality modules under quality, test and defects. This is primarily for agile and are all the modules and dashboards that we use. 

Another use is for waterfall projects. To some extent, we are using the requirement documents and Quality modules for our waterfall projects.

We just started analyzing and using a module called Pipelines Analysis. We are trying to integrate our Jenkins with Octane to start using it. This is in the initial stages.

After taking input from the OpenText sales team, deployment team, installation team, and professional services team, we are using Octane to its full capabilities, except for with the Pipeline Analysis and dashboards. We still need to focus more on dashboards, because Octane does support plenty of dashboards. We want to start using those in a big way along with the Pipeline Analysis. We are already using all the other modules in a big way. We started configuring dashboards for agile, waterfall, and various built-in widgets, but this is also in the initial stages. We need to explore more the dashboards and Pipeline Analysis, which is where we are seeking support from OpenText.

It is purely for project milestone progress, project environment, project development, project execution, software development, and software execution. Then, we are using it mainly for holding and maintaining the repository of Product Backlog, Epics, Features, testing test cases, system integration testing, and user acceptance testing. That is the scope that we have defined.

Its end-to-end traceability is one of the big advantages. Most of our agile projects work in a closed team structure. We are seeing what is the flow, where we are, and what is the project milestone. So, it provides end-to-end traceability and good visibility of project milestones. 

In real-time statistics, anyone can go and configure it easily. The user interface is very user-friendly. 

We built a status dashboard within Octane by adding some additional user defined fields (UDFs) that use real-time status about how much a project progressed, how much testing is done, and how much testing is left. Then, project management can help with visibility of the progress for every project within Octane.

The cluster architecture that we implemented was server to server communication: Octane application to Elasticsearch and Elasticsearch to another Elasticsearch service. Recently, we found this is a security gap. The Octane application is interacting with Elasticsearch server, but that was missing from the requirements and prerequisites in the setup. The OpenText team has not given advice on how to implement authentication-based communication between Octane to Elasticsearch, and we found it as a gap later, then our security team asked us to fix that gap. So, there was a lot of time spent on rework. They should have helped us with a clear requirement. This requirement has slipped from the initial requirements and drafting during the installation, causing additional rework for us after installation. This means my admin team and I have to work to fix that gap. I already gave this feedback to my customer success manager, "Security related prerequisites and requirements should be thoroughly explained to the client." Hopefully, they can apply this and avoid future rework.

For the requirement document, the module should provide multiple templates to be prepared, or customized quickly, and be reusable.

For the Pipeline Analysis, job or application grouping has to support Jenkins job grouping, because we have thousands of jobs running. Unfortunately, we are unable to group those by using multiple filters. They could help us with these features in upcoming releases in the next six months. That would be great because many testing and production jobs for Jenkins users need filters and grouping.

We started using the tool in the last four to five months. Now, all our users are using OpenText ALM Octane.

For the last four months since we have been using it in a big way, we have not seen any downtime or surprises from the stability from an availability point of view. 

We have dedicated administrators who handle support for Octane and other tools.

It is scalable. We do need to explore it more to determine its support for a scalable framework. 

We are in touch with them. Their support is very good. We are constantly communicating with our customer success manager, who is helping us with a lot of queries. He is trying to resolve them. He brings in his R&D team to sort out our issues, which is good. We are getting good support, but there are a few product limitations that we have highlighted. We have asked them with help fixing those limitations by providing alternative solutions.

The requirement document has to be more flexible for the features, user interface, modules, and capabilities. It needs more advanced features, like copy paste of the various templates. It should have an inbuilt capability to build and design any template with reusable capability.

We moved from ALM Quality Center to Octane. We mainly switched because we have more than 50 percent of our projects running on an agile model, and ALM Quality Center doesn't support agile. 

We wanted to have interim projects for traceability and milestone visibility. We also wanted to have a tool where my team could write scenarios for user stories and those user stories would be available in a single tool. So, Octane is a better tool for the future.

Octane supports DevOps integration tools.

The actual Octane installation is straightforward, but it was a complex process for us because it is a cluster architecture. We have two Octane applications, three Elasticsearch, two databases, and seven to nine servers. While complex, we are not experiencing any issues so far. 

It was a nine week activity where we did the initial setup. The process was complex. We found issues while doing the integration between Jenkins and the DevOps and automation tools. 

When we started the integration with the other tools, like Jenkins, Selenium, or UFT, and tried to automate things or integrate with Jira, then it took more time because of the compatibility issues. It may not be working as expected and my automation framework may be different as well as Octane may not support my automation framework. My automation framework may be using Selenium, so I have to change my automation framework to ensure that it works with Octane. These things have to be in front of the client in advance to work out and give advanced information about compatibility issues of the automation framework and compatibility with the Octane, so an evaluation can be done during the due diligence on the first week of the kickoff meetings. Then, we can save time during the implementation.

The OpenText team should be providing more end-to-end view during the installation and user acceptance testing. They should provide more knowledge on the usage of the tools and various important capabilities, e.g., how do we use that? That is the missing part of the Professional Services. We had to go over it again by raising many queries and tickets. Therefore, the knowledge transfer of capabilities has to be given more focus during the installation.

Integration with other tools, compatibility, and frameworks has to be thoroughly checked by the OpenText team in conjunction with the client team for faster integration and to avoid surprises during the implementation.

For deployment, I was involved as a manager and there were two more guys from my admin team, who looked after the tools. There was one person from OpenText Professional Services along with a OpenText project manager. There were two team members actively involved throughout the project to open firewalls, do the setup, install, and troubleshoot. There was also one more guy for automation purposes when we were working on the automation integration for Selenium and UFT, and he worked for two to three weeks of time. Overall, three people worked for eight weeks.

We are not using this solution for operations. We are using the Octane tool for purely project solution delivery. For operations, we use Remedy tools, not Octane.

Jira has its own limitations, so we thought Octane would be better.

Our testers and manager do conduct risk-based testing implicitly, but we don't call it that. We apply it unconsciously and do it on the fly. We upload 100 or 200 test cases, depending on the timeline, and prioritize them. At the end of the day, we execute 70 or 80 of them and roll out the project. Eventually, all the functionalities are covered and no defects slip to production.

Currently, Octane's support for single sign-on is implemented separately, so we are not using it. Maybe in future we will use it.

We are ready to explore a couple of the solution's capabilities. I would have given a nine out of 10 had I explored those capabilities and been satisfied with them, but I am unable to do that. However, I can give the overall tool after the installation with support an eight out of 10.

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.

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.

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.

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.

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.

One use case was for development life cycle management for a pool of developers using it in an Oracle and .NET development environment.

One of the benefits is the integration with different platforms. Having the defect management, and being able to relate defects and testing to the initial user requirements—having this complete life cycle—is one of the major advantages with Octane. It's the "life cycle" way of thinking that the solution provides. That is a very important component of Agile and DevOps. Octane integrates with your CI server for continuous integration and delivery. This "life cycle" approach gives us end-to-end visibility.

It also provides a single platform for all automated testing and that definitely helped facilitate the testing, the test scenarios, and collaboration between the test team and the development team. Having both together on a single platform allows us to ease the integration between the different teams. One of the major things we talk about regarding Agile, and one of the major components we talk about regarding DevOps, is this seamless integration between the teams.

In addition, it gives you a single, global ALM platform that supports all your Agile and Waterfall needs. One of the big challenges for DevOps is the adoption of a tool among the teams. The fact that the tool facilitates and supports this definitely helps the adoption.

ALM Octane also reduced testing costs overall. It's hard to say exactly how much, but I would estimate by 20 percent. It also definitely reduced integration costs by building a streamlined application delivery pipeline connecting to all IDE, CI, and SCCM tools. In this case the integration costs were reduced by 20 to 30 percent. Finally, it helped to produce releases faster, again by about 20 percent.

The valuable features start from the defect management in the life cycle and go into the part for versioning control.

The defect management gives us full-fledged capabilities for handling defects, including capturing the details of the defects and even screenshotting the defect cases. The defect management is comprehensive. 

Also the integration capabilities with other development platforms we were using was helpful. The out-of-the box integrations are definitely a big part of making Octane comprehensive when it comes to DevOps quality management. It is full of features and gives us flexibility to provide the needed integrations with different platforms.

The solution natively supports Waterfall, Hybrid, and Agile software development at enterprise scale. That's very important because there is a big shift going on from the Waterfall environment into Agile in DevOps. Having a tool that can give us both practices was important.

In addition, Octane's Agile support is good at both the team and the portfolio levels. It has dedicated capabilities for Agile and is very flexible and comprehensive in these two areas.

Security and security management, meaning the integration of the security, could be enhanced. We know about Fortify, but it would be better to have security features in the original Octane platform without the need for another solution or another application.

We've been implementing solutions with OpenText ALM Octane since 2016.

From the stability perspective it's okay.

We did not stress-test it to see what it would be like in a mega environment. Usually we deployed it in a medium-sized environment, with 20 to 30 developers, and the scalability was okay.

I would rate technical support for the solution at six out of 10. Usually there is a lack of connection among the teams for handing over support cases. You often need to do or redo some work whenever support cases are opened. If it is handed over to a new engineer, you need to start doing things over from the very beginning. You have to explain things again.

The initial setup of Octane was straightforward. Because you are talking about development and software developers, it's not like a normal tool for business users. It was not complicated for people to get along with the tool and use it and integrate it.

Usually, deployment takes, on average, a maximum of two months. The deployment plan definitely depends on what the current technologies are, the integrations needed, and on what types of development environments and what types of IDEs are involved. It also depends on whether there are other systems and tools available already.

Just one person is required for deployment and maintenance of the solution. Rather than a developer, that person would be an administrator for the system.

The benefits I've mentioned can be reflected as monetary benefits, which I would estimate at 35 percent annually.

Microsoft is a big challenge for OpenText when it comes to pricing because they are much cheaper. But it definitely depends on the complexity of the environment. If it has multiple technologies, at that point, looking at other options and Microsoft would be a feasible approach.

We work with Microsoft TFS. We also use JIRA, but I don't consider JIRA a competing component, rather we integrate it. One of the pros of TFS is definitely its integration and supportability if you are a Microsoft development environment, using .NET and the like. There's a lot of seamless integration there. Also, from a pricing perspective, usually Microsoft can provide you with very cheap packaging options. Those are the two main pros for Microsoft TFS.

Dedicate someone for the administration. Often companies assign a developer to take care of it but this is not the proper approach. Someone needs to have responsibility for the administration. Also the process when using the solution should be a consultative approach. First look at your process and your development life cycle and then reflect it in the tool. Also, be clear about the integration points before starting the implementation so that the technical requirement and scope, etc., are clear.

Regarding reducing manual testing time, this didn't happen in the extreme because we were already automating most of the environments. There was a lot of automated testing. But it helped in facilitating the "life cycle" approach, especially if the environment already had Microsoft TFS. You integrate it and put it on top and you gain big benefits.