OpenText ALM Octane Reviews

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

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

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

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

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

I have been using it for three months now. 

It is a stable product. It performs well. 

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

I used Rally. 

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

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

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

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

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

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

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

We definitely use it as our one-stop solution. 

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

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

We are using it for test management. We are using its latest version.

It can simplify testing by structuring it after the application modules that you are defining yourself, and these are both tests and defects connected, which helps you control the quality in different areas of your solution that you deliver.

The filtering options are very good once you learn them. The document reports are also valuable. You can create reports in Word and PDF formats. That's very useful.

It is flexible. You can integrate it with a lot of other products that are available. If needed, there are APIs available. That's also very good. It's also pretty easy to adapt for the users.

Development of extensions or connections to GitHub actions could be better. Better integration with Azure DevOps would also help.

I have been using this solution for about four years.

It is stable.

It is scalable. It is just about adding more power and more Elasticsearch servers, and you should be fine.

We have about 500 different users daily.

We are happy with them. We have weekly meetings with the PAM.

We used HP ALM Quality Center. We switched to Octane because it's a more modern platform. It runs on full browsers and all OSes. So, it makes sense to use it. 

We installed it on the side of the existing one, and we migrated step by step or project by project. 

To start with, it was pretty complex because it was a pretty new solution when we installed it. We were probably one of the first bigger companies installing it. So, we were quite early adopters, but it is a lot easier today to install this. We haven't had any problems. There are very few errors in the solution.

It was done a long time ago, but we spent a lot of time because we had to explore enabling single sign-on, etc. That contributed to taking some time, but that had nothing to do with the product. It is probably a lot simpler today.

We are an IT company. We do it ourselves. We had just two people. We probably had a DBA too.

It is hard to say. We don't measure it, but we probably have seen an ROI.

If you compare the price with the functionality, it is pretty much the same as other solutions. If you compare it to Jira, for instance, it has a lot more functionality. You don't need any plug-ins, but it's also more expensive. Once you start adding your different plug-ins to Jira, you'll probably end up with the same amount or more.

There is also a yearly support cost, which is usually 25% of the initial cost of the license.

We already had ALM Quality Center. So, it was a natural move to Octane. It was easier for migration purposes, and the users knew some of the main functionalities. So, we did not evaluate other tools.

I would rate it a nine out of ten. It is pretty good.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The way we brought it in is that we have a Flex agreement with Micro Focus for a large list of products. Because we had ALM, Octane was included. If I have 200 licenses of ALM, I have the equal amount of Octane. If use one, I get the other.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We are using Micro Focus ALM Octane for agile purposes and integration with ALM.

The most valuable feature of Micro Focus ALM Octane is the reports. We are able to do customization.

The solution should improve by adding scrum board-like functionality.

I have been using Micro Focus ALM Octane for more than one year.

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

We have 14 people using the solution in my company. We might increase our usage of the solution depending on the project we have.

I rate the scalability of Micro Focus ALM Octane a nine out of ten.

I rate the support from Micro Focus ALM Octane a nine out of ten.

Positive

I have used Jira previously.

The deployment of the solution can take approximately four hours. However, it depends on the environment. The solution can be integrated with GitHub.

I rate the initial setup of Micro Focus ALM Octane a seven out of ten.

We used an integrator for the deployment. We have three people involved in the deployment.

The price of Micro Focus ALM Octane is too high compared to other solutions.

I recommend using the free version before purchasing. 

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

Micro Focus ALM Octane is hosted on a separate environment, that's a hosted environment for us, it's not on-premises because Data Consultancy Services is supporting the outsourcing to that company. If you compare Micro Focus ALM Octane with Jira, we have an on-premise deployment for Jira, that's the difference.

The most useful feature of Micro Focus ALM Octane is the dashboards, they are easy to use. 

I'm using Micro Focus ALM Octane as a manager, and it is two times easier for us than other solutions. The look and feel are good and we can customize the reports and dashboard. From a management perspective, it's quite a good solution. The features are robust, ironclad, easy to configure and use. 

When it comes to CI/CD for the developers, I did not find any major differences with other solutions except that some things are saved in the files rather than being visible in the window. It is not available in the graphical user interface(GUI), but it is in Jira.

The solution is frequently updated with new features.

I have yet to experience the CI/CD part of Micro Focus ALM Octane but as demonstrated by the team who is providing the services, I see that the CI/CD could improve. When we check in the code, for the code snippet that has been checked in by a particular user, you need to open a separate file. When comparing Micro Focus ALM Octane to Jira, they have a separate window in which you can click on the ID and the code is visible in the snippet. It's a two-step process in Micro Focus ALM Octane and it's a single-step process in Jira. It's essential for the developers to think about this difference.

I have been using Micro Focus ALM Octane for approximately two years.

Micro Focus ALM Octane is stable.

I have found Micro Focus ALM Octane scalable.

We have approximately 250 projects using Micro Focus ALM Octane. We are a  small team of 10 to 20 people that varies at times. Our performance-driven teams and we have been releasing month on month. We are finding it very easy and comfortable with Micro Focus ALM Octane. 

Since the ALM Octane is outsourced for us and another MNC provides support, regarding scalability, we as customers to them have observed it's highly scalable - addition of servers to handle thousands of requests/reposne from end users - agile/scrum teams/project managers/ stakeholders to manage backlog is easily met. There is no lag in response time, never did the pages hang. I never waited for Dashboards to collect data and show up, it's just in a fraction of seconds. 

Also, latest in DevOps technology like Azure DevOps for CI/CD is easily implemented. 

The support we receive is fast. When we had Jira, we had our internal team who had been given the training to support us. With Micro Focus ALM Octane we have outsourced the support to a separate company called Data Consultancy Services, and the response time is great.

We have used Jira previously.

The senior management of my company handles the purchases of the solution. However, the price per developer was a major reason we switched from Jira. Apart from the complexity and the support, the price was a major reason that a team of 20 people unanimously decided that we would prefer to go with Micro Focus ALM Octane rather than Jira. The senior management had seen some benefit in it and they preferred it over Jira because the per developer cost was less and the support was superior.

Micro Focus ALM Octane has been exemplary, and as a project manager, since the day I've started using it, it has been wonderful. We are very comfortable with the processes and the tool. We have zero worries since we have been using the solution. It has been very positive from our side.

It is early to rate Micro Focus ALM Octane because we currently are using only the dashboard features, solution backlog, and requirement backlog. The CI/CD has yet to be implemented. Addiotanlly, the orchestration is pending, but as for the current usage for these features, the solution backlog management, prioritizing the task, creating the task, creating the defects, creating the manual test fields, and automated test fields, are very good. 

We have experienced CI/CD in orchestration in Jira, but not in Micro Focus ALM Octane and, in a month's time we will have a better understanding.

I rate Micro Focus ALM Octane a ten out of ten.

I give the high rating because of the support, look and feel, reports, and the dashboards

We have a relatively splintered tool set and a number of tools which could not connect all of those things together. Therefore, the use case for ALM Octane was that we were trying to create a single version of the truth. A single source of everything to change within the IT department. 

I work in the programs management department.

We are using the latest version of the product because we are cloud-based. We receive all the deployments as they are released.

Octane has definitely improved the capability that we have for visibility within our tool set. The ability to report and see the current status on change, defect, and test runs on a spring by spring basis within our programs. Previous to this, change management was done in one system and testing was done in another system. Defects were in one of those systems, but they were like forgotten children and weren't really linked to anything. 

Octane has made everything a lot more visible. It's ability to relate everything together and create spider diagrams of change, the lifecycle of that change, defects, and the test status. These have made a massive difference to the visibility and our ability to trace back to the origin of a change, where it started, and see how it finished.

It's beginning to improve our processes as well. We are seeing some real improvements in the way we do things. We are becoming more agile in the way we do it because of that and in a way that stories are managed. Stories are given lifecycles as opposed to just being entities within a tool.

The visibility that we received from the ALM tool is that we can see a change through from its early requirements all the way through to development check-ins to the pipeline release then to the point that it's deployed. We can see the full lifecycle of the change within the ALM tool including integrations that we never before had in a change management tool. It's almost revolutionary for some people here to see check-in information appear against a user story in an ALM tool.

• Octane is built on the SAFe framework, which is the agile methodology that we are currently following.
• The capability that it has for so many out-of-the-box integrations is a fantastic feature. 
• The very clean, easy to use UI that it promotes.

The reporting side of ALM Octane could do with a few areas of improvement. There is not enough flexibility in the way that we can cut up the data to report on certain things. For instance, with test information, we can't split that up by team, so it's quite difficult to see what coverage each team is currently working on. Some tech managers and scrum managers want to see the testing which going on within their team, but it is difficult to see. We only get a more holistic overviews of that.

I come from a testing background, and think the testing could be improved. 

It is a very stable platform. We occasionally see areas that come up with a more client side, so they're not blanket across everyone. Sometimes people use the wrong browser. The product clearly states that it doesn't support IE, but then who would support IE, as it is end of life. 

We've only had a few stability issues. Generally, we have issues following any deployment they do, so if they do a deployment on a Sunday, then we may have a couple of issues on a Monday or Tuesday. However, their support and willingness to react and resolve issues for us has been second to none. They've been low impact to the point where it has not damaged anyone's perception at all.

We have 220 users on it. I have spoken to clients who have 3000 users on it. It's relatively scalable. We haven't seen any performance issues at all as we have ramped up the amount of data that we have on it or the amount of users. Our users include scrum masters, developers, testers, product turners, subject-matter experts, and business intelligence analysts.

In terms of usage going forward, we will rollout to our operations department. We'll get Ops using the same platform, so that should be another 60 to 70 users. The benefits of this would be that we would have more work concentrated all in the same place. Therefore, we can have a lot of crossover between other departments which aren't currently on ALM Octane that we can get onto Octane. This would make it work better and make it easier to manage because it would be a single place for work to be referred between teams, as opposed to having to go to a different tool if someone needs something hardware or software related to be created. 

For a company of Micro Focus' size and delivering this large of a tool, their engagement with me has been unbelievable. It has been to a point where I have never experience engagement like this from a software house. I speak to developers and architects. I speak to people who actually care about the issues that they are speaking about. I don't just get someone in a call center who is logging a ticket, and says, "Someone is looking into this." Then, the ticket disappears into the abyss for three months. It's really nice to see and have intimate feedback on your suggestions or queries. That relationship has been almost as valuable as the tool.

The technical support, help desk, or service desk where you log a ticket on their service platform has the ability to turn around an issue quickly and is very reactive. 

I logged an issue on Monday afternoon, and within 12 hours, it was fixed. They did a deployment on Sunday, where they made changes to the history area of every ticket. Then, on the Monday, that history had vanished. We noticed the history had disappeared. The history for every single change that we had in ALM Octane was gone. I logged a ticket with them late in the afternoon on a Monday, then by 9:00 in the morning the next day, our history had been restored. Whenever they do a deployment, if we have issues, it takes them no longer than three or four days to resolve that issue and deploy a fix for us.

One of the biggest strengths of the community that developed Octane is they are so willing to listen to their customers and learn, then improve the tool that they have delivered. They try and make it fit for the customers who are using it.

We were using Enterprise Tester and Rally (CA Agile) for change management. We switched from Rally to ALM Octane because of the lack of integrations and lack of drive to see Rally improve (from the company) because Rally is now owned by CA Technologies, and technically called CA Agile. CA has multiple other products that do the same thing as Rally. They have sort of acquired Rally, and it almost gives the impression that they will end of life Rally at some point, then take the user base and put them onto the tools that CA have. 

Also, Rally's age is a factor. Rally was one of the first scrum-based agile tools. It did a lot of things very well in its early life. It's been overtaken by newer agile tools now. The last reason was because Rally was not our choice. It was a tool that was pushed onto us by a third-party integrator when we brought them onboard to help us deliver a large program, so we just ended up with it. When you don't bring in a tool yourself and don't integrate it yourself, it ends up being a little bit of a mess on the administration side. There was a lot of stuff in it that had no home, no direction, nor desire to ever be completed, and had not been managed correctly. Thus, the administration to cover the tool was enormous.

We switched because outgrew the Rally tool with our process. It had gone beyond the capabilities of Rally.

People are generally happy with the position that they are in now in comparison to the position that we were in when we were on Rally. The administration is certainly a lot better now that we're on ALM Octane purely because people have a desire to not want to end up in the same situation, thus people are more conscientious of what they're doing.

The initial set up was very simple. The tool from getting our license to starting to use it, there is not a lot to do. We have evolved with the tool, as the tool has gone on, but we started using it straightaway. There was nothing that we needed to do to make that tool work. We have taken a very step based approach. We started using it, then we developed some changes in the way the workflow flowed. We have added additional fields here and there, where we decided we needed to do so. Then, we added additional bits of functionality through other bits of integrations as we've been seeing the need or when we know we've embedded it in processes with other things. We've rolled things out slowly. It seems slowly to us, but it's actually not taken that long.

There is not a deployment. It's literally they give you access. They go, "Your licenses are ready," and you login. That's it, then you start using the tool.

The planning phase for me was a year long project, getting everyone on the system and all the data migrated. Initially, it was about creating a need, because no one knew they needed a new tool until someone looked into it. I identified the need and problem, did the analysis, made the recommendations, presented the options, made the recommendations, and collected the requirements. There were a lot of requirements. Then, I went out and engaged with our InfoSec Department and our procurement process. I officially got sponsorship from the directors in about March for the project who saw it and put some money aside to be able to do it. It was a fairly smooth process from start to finish, but it was hard for me because initially there was no need for it. I created the need for it, then from that point on, it was a very smooth process.

I was the single person driving that process, but then it was a member of staff from procurement. I touched base with multiple areas of the business that would have been using it to gather requirements, so nine scrum masters for half an hour each. Architects were all advisory. Contract specialists/managers to do the contracts. We had our legal team. I was the single resource that drove the process, created the documentation, and found the supplies.

I am the person now maintaining the system. It shouldn't take more than me, but it probably won't be me forever. The only reason it requires maintenance at the moment is because of misuse, so it's not like things go wrong with it all the time. It's more of a case of that it's self-sufficient and I can go through and review the work that people do, ensuring they are using the tool and populating it as we would like them to, thus we can get quality data out of it. 

We purchased it via a supplier. Octane is being supplied by EOH Europe for us. I have worked with them in the past. They were happy to put us in touch with Micro Focus. We already have a couple of other tools through EOH, so we already had an existing relationship with them.

Working with EOH Europe was fantastic. My contact at EOH was very helpful. He has always been there to help with the multiple questions that I ask all the time about various different things, not necessarily related to Octane, but about anything that they supply us.

My biggest challenge as the integrator has been about changing culture. The tool does what it does. That is all. It has received a very positive reception by the majority of the people that use it. 

Changing the culture means improving the way that we do things, our processes, and the way that we do this is by having communities. We have a community to address concerns, misunderstandings, and conversation points that people bring, then we try and improve the practices that we do by trying to get everyone aligned to the same practices.

It's a bit early on to see improvements in times and deliveries. Our entire company has only been using the product since December of last year, so we don't have enough trend data.

We will see ROI once we have the automation suite connected up to Octane. We will then have the ability to report on automated testing versus manual testing and the ability to see those tests automatically parsing with the tool. When Octane shows us when our CI process fails and shows us what the story that failed, we will have return on investment. Because we will have not the overhead of having to do an investigation of having to find out what the change was, because Octane will tell us all of that information. 

For what it does, it's very reasonably priced. I like the licensing model as well, because it's very flexible. You can scale licenses up and down for short periods of time. 

In terms of pricing, it's comparable to what we had previously. It's not priced at the higher end of the scale by any means. It's priced nicely, in the middle of the market. For what you're getting, it's a very good tool.

It went through official procurement process where we went out to tender with seven different suppliers. We had responses from five of those suppliers. We had demos from five of those suppliers. We followed three more through, then we eventually selected Micro Focus ALM Octane. At which point, we started demoing Octane and ran it through 2018 whilst we were doing contract negotiations and signing contracts, which was probably the single hardest part of the entire thing. 

Four of the seven vendors that we looked at were Micro Focus, CA Agile (incumbent), VersionOne, and Jama. 

We went with ALM Octane because of its functionality and it is presented very cleanly and simply. You are never more than three clicks away from where you need to be in Octane. Another reason that we went for ALM Octane as a tool is because of our relationship with Micro Focus as a company.

ALM Octane has a cleaner version than VersionOne, which is a little busier.

If you're looking for a tool which will complement a CI or DevOps process, where you want to have a single point of visibility or a single version of the truth, and see all of the stuff that happens through that journey, Octane is the tool which will to give you that.

The biggest lessons learned: When you start focusing on a new tool that prides itself on having a very tight process to make things visible, you learn how other people don't necessarily follow its processes as tightly as you would expect them to.

Using the SAFe framework helps our workflow patterns. We have been using SAFe for about four to five years, and we've actually been using it properly for maybe two and a half to three years. We're still not perfect by any means, but we are definitely pushing forward in the right direction to become more focused on delivering the true version of that methodology. Although ALM Octane doesn't do every element of that methodology yet, they are endeavoring to clean up a lot of those areas. They are trying to mop of some of the methodology that SAFe works on adding in things. We have seen quite a lot of new features recently that have been specifically focused towards SAFe, which has been really positive for us.

ALM Octane has improved our use of agile, but we still do some waterfall stuff. We will always carry on doing some Waterfall stuff until certain systems fall out of use because we have old systems and those old systems don't lend themselves to agile.

ALM Octane has presented us the opportunity to push forward with a true CI/CD approach, which is where we want to get to. 

We use Micro Focus ALM Octane for testing. We don't use the entire portfolio, but we use it for testing, documenting test cases, executing test cases, and tracking defects. The platform is critical to us, because we're using it for compliance purposes.

We like Micro Focus ALM Octane because its performance is okay, and its stability is okay, so we use it a lot. The platform is easy to use.

From my personal point of view, what could be improved in Micro Focus ALM Octane is its integration with Jira. The latest version of the platform could have that integration by now, but at least our version doesn't have that integration with Jira.

We're using Jira for our user storage and the whole agile part of a software development lifecycle. We don't have that Jira integration, so the testing and the definition of user storage are separate. We're moving more and more towards the agile software development lifecycle, and we chose to stick to Jira, so what I'd like to see in the next release of Micro Focus ALM Octane is Jira integration.

I've been using Micro Focus ALM Octane for years.

Micro Focus ALM Octane is a stable platform.

I'm not sure what other tools we used before using Micro Focus ALM Octane, because we've been using it for a long, long time.

The initial setup for Micro Focus ALM Octane is very straightforward.

I'm not sure which version of Micro Focus ALM Octane we're using, but I know it's not the latest version. We have 3,000 users of Micro Focus ALM Octane, and we have plans to increase usage for it.

I would recommend the platform to others who are looking into using it.

I would rate Micro Focus ALM Octane a nine. It's not perfect, but it could also be because we're not using the latest version. We use it a lot, and it really adds value.

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.