OpenText ALM Octane Reviews

We're using it for test management, to write test cases and we have put it into an overall approach which is called BDD, Behavior-Driven Development. Within BDD we're using Octane to manage all tests, to plan and do test automation. We're doing test automation with IntelliJ, together with TestCafe, which is a pretty nice test-automation tool. We have Jenkins with a pipeline connected to Octane, working the whole process. 

The main intent is to have a quality solution. Our development is working in JIRA, which means that we have split it. We import user stories from JIRA to Octane and start working from there on our testing.

We started from scratch because we didn't have any BDD approach. We used a more old-fashioned method of development, more Waterfall and so on. We were looking for a solution which would be a good tool for our new methodology. For us, this was a key benefit from Octane, to get rid of the old style. We are implementing Agile methodologies in DevOps, that's the main thing. We try to use shift left to test much earlier and therefore it's really helpful to have Octane and to implement the new approach with it.

The most valuable feature of Octane, in comparison to ALM, is the whole Agile approach, that we can run it with the sprints and have it better connected to the whole development process.

The other feature is the pipeline, so that we can now connect to Jenkins and then have all the results from testing, from external, in the tool, so that we can see the whole approach from there.

Many things are nice so it's hard to say what is best; for example, the way it's organized. We can work with labels so we have better filtering solutions than in ALM. And it's much smarter and leaner to use than ALM.

There is a lot of room to implement new things. I would like to have more possibilities for doing test automation directly in Octane or to see UFT scripts within Octane. The implementation within ALM of UFT was much better than in Octane because I can only see the results from our test runs in Octane, but not the test itself. With Gherkins in there, that's fine, but I do not really have a hand on the scripts themselves. I can follow the pipeline jobs in Jenkins, but I can't see what's really happening there. So I would like to have some more information about that in Octane.

Also, while there is a Requirements Module in Octane, it is very plain. It's okay to have some requirements described there, but it's not really following the whole BDD approach. I would like to have more features for requirements in there; not as much as in ALM because in ALM it was a mess, it was too much.

There is a whole lot of room to improve.

It's very stable. Over the last one-and-a-half years, we have really not had an issue. It's fine. We only have a handful of people who are working with it so far, but for them and for us it's okay. 

We have a very small team. Some are working from Croatia and we have a team here. We have a maximum of three or four concurrently using it. In the future, we will have many more. For the moment it's a pilot, but as a pilot, it's working fine.

Tech support is very good. We are in direct contact with the guys from Tel Aviv and it's very good. We're in touch by phone, email, and we have sessions together with them. It's much better than it was with HPE, in my opinion.

It could be, because we are a pilot project and one of the first here in Germany, that we have more direct contact. But this is working. I really like it.

We figured out that with our BDD approach, and what we planned with more modern technologies, and our shift-left approach, that ALM didn't fit. There was no chance to implement any Agile approach in ALM. We started to think about what else could be useful. It was pretty obvious that Octane was the right tool.

In ALM you do not have any flexibility to model the processes, to say how you would like to see new things like quality stories. With Octane you can add pipelines, and with the API you can add other tools and, therefore, other processes. All of that is not available in ALM. In ALM, you have a closed system and you have to live with what is given, while in Octane, you have the chance to add new stuff to the tool, like reports from outside, etc.

It was really straightforward. It was a pleasure to implement our approach with it, compared to ALM or to the older tools. It was really easy. I started from zero with Octane. I had never seen it before. It was brand new and I really learned it on my own, everything in there, including the setup and how to implement the processes, etc.

In terms of maintaining it, right now it's just one person. Once we scale it, I don't expect it will take many more people to maintain it because it's very easy to maintain. If it's set up well there shouldn't be too much work to do there. For the technical parts, we will still need only one person and, within the project - depending on the number of projects - we will need, perhaps, one guy who's taking care of it from time to time.

We have had some strong discussions in regards to JIRA, to use JIRA plug-ins and to get rid of the overall HPE/Micro Focus way, because of the money. We had some discussions about whether we could make it with open-source tools. But at the end of the day, we figured out that they're really not good, full test-management tools. The overall approach, with everything in one place in Octane, for the money, is more valuable.

Since we're not finished with the license discussions, I can't tell you the end result or numbers and figures but, in the end, it's more or less equal, from the money point of view: if you're using open-source with more consulting or if you use a tool like Octane, which costs some money, but you don't have a lot of work in terms of implementing and consulting, etc.

I don't deal with licensing and pricing, but it's worth the money, from my point of view, because it's very good. But that's all I can say about that.

We looked at a few. One we're still having look at is Xray but doesn't fit with our BDD approach. We also looked at ServiceNow. That's mainly for ticketing systems but they also showed us something about test management. It was very close to ALM, to the old way, so it was also not very useful for our process. Our support is working with ServiceNow but it doesn't fit with our project.

Think about your processes and the methods you're using for development and quality management and see if the tool fits. If yes, it could be a good idea to use Octane. I have presented Octane many times within our company and outside of the company, and I have had very good feedback and many questions about whether it is useful or not. "Can you really say it's the perfect tool?" Mostly I have said to them it's really good. If you work in Agile and if you work in BDD and Gherkin, I think it's the best tool on the market.

I have a pretty long history in testing. I started in 1999 and, since then, I have worked with all these products from HPE or, now, Micro Focus. I know all the history and the older tools and I'm really pretty happy that we have a tool now which is working in a more modern way, in a good, Agile way. It's pretty nice.

With respect to how our tools and processes are evolving to adapt to the change from traditional Waterfall development, for requirements we do not have a good tool to work with, but we have Octane for testing, we have JIRA for development, and we still have ALM for defect tracking and for working together with the other teams that are still working in the Waterfall process. So for synchronizing of defects, we are connected to ALM. We have IntelliJ for development, and we use it together with Cucumber and TestCafe for test automation. We have Git for all our results and for version control. We have Jenkins, as mentioned before and, for reporting, we are mainly using Octane. This is the overall tool landscape we have.

The biggest lesson about adapting to Agile for DevOps is that it is really important to have APIs, to have open interfaces to connect all of these tools together; to have the chance to implement the pipeline easily. We are no longer bound to only HPE or Micro Focus tools. We can work together with open-source tools. It was easy to implement such things in Octane. This was a great lesson.

For our releases, we still have a Waterfall approach. We have a live release every three months. It was a little bit tricky to put together the testing for Agile and for Waterfall so that we could do the quality assurance for both approaches in one tool. I've found a way that I can have sprints over a longer time for the UAT, using Octane. We have 40-day sprints and testing in one tool. It was really nice to have found a way to have them in one tool. This was also a good lesson, to see that both can work in one tool.

There's room for more features but, for a relatively new tool, it's very good. I would rate it at seven out of ten. If the features and enhancements we have requested come through, it will be a ten in the future. Given the maturity of the tool, that it's only one-and-a-half or two years old, seven is a very good number. I can give it a 10 when the Requirements Module is working better and when some other things are solved, some problems with implementation that need work. Then it will be a ten.

The most valuable are the Agile practice methodologies. We have Waterfall with ALM and we use Octane for our Agiles. That's our distinction between the two.

I like the visual interface. The way they've redesigned the interface over ALM. ALM is kind of old-school, but it's mature and functional. Octane presents the graphics and the feedback that people need immediately without drilling into the dashboards. That's probably the biggest selling point for our teams.

Two things. One is Agile. The other is the CI integration. We've always struggled bringing the development teams directly into ALM. ALI is a bridge, but it's cumbersome. The CI integration of the pipelines is what we're looking for right now. To bring us into the DevOps potential. That's the biggest draw right now.

Octane fits that niche that we never had. We need an Agile solution. We had other teams using other products that are semi-Agile, but we didn't have an approved standard. Octane gives us that. It's awesome.

The biggest challenge for us is to bridge the ALM practices for testing more directly into Octane. That's going to be a challenge because the methodology between Waterfall and Agile is so radically different. We're going to have a challenge with that, but we knew that going in. The testing is new and we have a lot of embedded testing practices with the old ALM approach.

So it would be good to have something in-between there. Some kind of a bridge or training, that is going to be what we're looking at now.

We have yet to see anything that doesn't work. It's awesome.

We've only got 20 live projects in there right now. So I don't see any issues with it. Until we can put some massive projects in there. We've taken one 65-gig project from Agile Manager and ported that into Octane. We don't see any degradation, but that was still prototype.

I've used them pretty much every day. It's the most responsive tech support, it's been awesome. That's another reason we're going to Octane, because of that immediate support. That feedback.

We used Agile Manager and it does not have the testing capabilities. We really needed that. We also need the business rules, we needed some of the workflow that's not in Agile Manager. We needed an Agile solution that had a lot of the same capabilities and business rules that ALM has.

We didn't see that coming in the Agile Manager, so as soon as Octane came out, we jumped on it.

In choosing a vendor what's important is communication. Show up. Talk with us. Build that relationship and then we'll talk product.

I was involved in it, yes, but I have to qualify that. It's SaaS. All I have to do is call Mike. I didn't have to do anything, really, other than start using it. It's intuitive as can be.

No, just HPE, Micro Focus. It's our standard.

Getting something new approved is a nightmare. It also makes our job easier. We tell them, "This is the standard," and we can move on. We're not deluded by looking at bunch of other options.

Invest the time. Invest the time. Learn what it can do. Right now, it's still being developed. It's an Agile tool being developed into Agile practices. Don't get ingrained in what you see today. Accept changes. If you truly are an Agile environment, you get that. If you don't get that and you want things to be finished before you get there, then you probably don't understand Agile. They kind of go hand-in-hand. It's an Agile tool being built Agilely and you've got an Agile practice. You should be able to put two and two together. If not, you need to stay in Waterfall.

Our use cases are test management, defect management, and release management. We also do quality management and we have started to put our Agile journey on it. That is something we started at the end of last year. We're putting more and more on it. We're doing Agile delivery and Waterfall delivery with it.

It provides us with a single platform for automated testing. We've integrated our automation testing with Jenkins to the pipeline module—parts of it, at least—and the other part is connected through the API. It makes the test you're executing very visible. It also enables you to centralize. When we report on a project basis, we're able to do it in one click for a given project. The graphs are standard for all the projects. You just click and you always have the same set of reports, tailored to that project. It fetches the data from that project. I don't need to click five times to find my report. I just click to the next project and my report is there with all the needed information in one view. 

That's what my release manager also loves about it. He doesn't have to click 10 links or 10 drop-downs to get a report. It really has it all together in one view. If we have a release we report it on a project basis, and we can also report on an overall release basis. The overall reports are also done with one click.

In addition, we use the solution’s Backlog and Team Backlog capabilities and the team is very much working together there, from the developers to the testers to the product managers. They're all working together in one space or one Backlog to deliver the functionalities or the features. This is a good thing.

Octane has also reduced manual testing time. We integrated a big part of the regression sets into the pipeline. There's room for much more. We've only scratched the surface.

And using it, we have been able to streamline a lot on the business side. We have business testing or acceptance testing, and for them it's less complicated and there is less effort needed to get their stuff done. It has reduced the cycle times which, in the end, reduces cost.

On the user side, what I like a lot is the reporting capabilities. There's no tool, to my knowledge, that gets anywhere close to Octane at the moment when it comes to the reporting capabilities. I can do everything with the reporting. There's nothing missing. I have all the options. I can create graphs, including graphs of several types and looks.

Octane provides out-of-the-box integrations to proprietary, third-party, and open source tools. The integrations are of high quality because we were easily able to integrate Jira with an additional tool. That connector tool is out-of-the-box and it's very easy to handle. We also integrated one of our in-house developed applications that has a rollout tool. The person responsible did it in one or two days with API connections. It was very easy for him. In addition, we integrated Confluence with Octane, using a self-developed script that is also based on the APIs. For people who know APIs it's very easy. 

Octane's Agile support at the team level is pretty good because it's very visible. The sorting and filtering are very advanced, which is something I miss on Jira.

There aren't major things that need improvement. It's more detailed things, minor tweaks and improvements. For example, updating items, sorting, bulk updates—these things could have a bit more flexibility, but it's still possible to do them. 

Also, for training, the proposed graphs in the dashboards could have some more explanation about what they're doing because not everyone is using the same metrics. This is more a training or knowledge thing, not a lack in the tool, and I already addressed it with my OpenText contact.

They improved some of the things I had on my list in the newest version. I haven't dug through the newest version fully yet.

We started to evaluate OpenText ALM Octane at the end of 2019. We did the kickoff in January of 2020 to plan all the migrations to it. We came from ALM QC.

It's very stable. We had one issue that was due to a faulty, outdated script that overloaded the system somehow. Apart from that, Octane is as stable as it gets. We haven't had any downtime apart from that outdated script.

The technical support is very good. Depending on the severity of your ticket, the feedback is almost immediate. And we can collaborate with them, show screens and share logs, and they come back with a solution. It has been a positive experience.

Our previous solution, ALM QC, was outdated. Our company started our Agile journey and we needed to be able to support that journey and the Waterfall journey as well. Octane offered this hybrid model which was the clear selling point for it.

The native support for Waterfall and Agile software development was very important in our decision to go with the solution because we knew that Waterfall and Agile will co-exist for quite some time, and the tool had to be able to manage both in parallel. Also, for the future, it will still support what we want. If the shift goes more to Agile and less to Waterfall, the tool still has to support both of the methodologies.

Because we came from ALM QC, and that tool was in use for quite some time, there were a lot of user-defined things and customization. Initially what we had to do was a cleanup on the QC side: what we wanted to take over and what we didn't want to take over. We really cleaned out stuff that wasn't needed anymore. That took one or two months. 

The actual installation of Octane was very quick and straightforward. The customization and configuration of Octane took about two months. That was because we were very new to the application. If I set up a workspace now, it's much faster.

We have 1,100 users and their roles are really across the company. We have project managers, developers, testers, release managers, and test managers. We also have business users and product managers on the Agile side. Any role you could think of is using it, apart from the C-level.

What I like a lot about Octane is that it's very easy to handle from an admin point of view. The maintenance is very low compared with ALM QC where it took several hours or days, even, to set it up and upgrade it. Those processes are very easy with Octane.

I compare it, still, with ALM QC, and there's definitely a return on investment on it. I see this leveraging more in the future.

The comparison is always with Jira, so the pricing of Octane is a bit on the higher side. But if you look at what you have to add to Jira, on the plug-in side, to have the same abilities you have with Octane, you're more or less even, or even ahead with Octane.

We only looked at Jira. We had some concerns about its reporting capabilities and its task management capabilities, as well as managing Waterfall and Agile in parallel.

You definitely need to prepare well, if you're going to implement it. Do a proper analysis of where you're coming from and what is still needed and what is not needed, and really kick out stuff that isn't needed anymore. It will make the whole migration to Octane easier when you have less historical data in it.

I see that our users like to add things and try new things because it's built in an open manner. When you add Python scripts and use the API connection, you have a lot of flexibility for doing certain things. I see some developers who like it and who like to experiment with how to work better on their side.

We have started a PoC on integrating the solution with our CI server for continuous integration and delivery. The CI/CD is working and we're fine-tuning it now. I hope it will give us a one-click approach where we can even execute the pipeline from the GUI, which will make it easy to use. My vision is that we have all the pipelines integrated in Octane and that we can trigger them from there to speed things up and have them visible for developers and for testers. This would also be a way they could collaborate more. We're not there yet. 

It has the potential to reduce integration costs by building a streamlined application delivery pipeline that is connected to all IDE, CI, and SCCM tools.

Octane can also provide a single, global ALM platform that supports all our Agile and Waterfall needs. We don't have all our Agile in yet, but it can. That's the vision: that we have them all in one tool. We're not there yet, but I see glimpses of hope. It has the potential to improve the quality and the speed. The potential is there.

It still has upside coming. Things are being developed. We are in the preferred partner program, so we see also the new features that are coming, which will facilitate daily work.

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.

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.

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.

What we're doing is a cloud migration program. We're migrating about 70 applications from on-premise centers to the Amazon Cloud. That migration is primarily using Octane to store manual test cases and for a manual backlog of user storage to migrate each application. We're also using Octane to record the results of automated testing and performance testing.

The integration points are very good. Octane gives us a window not only into our manual testing, but also our automation testing and our performance testing. We can see all results from all three streams of testing in one place. We've never done that before, until this past year. Whether that was possible with Quality Center or ALM.NET, I really don't know, but it's the first time we've ever done this. So the fact that it gives us that window into all phases of testing is where it's a bonus for us.

The whole thing is geared towards Agile deliveries. It certainly has a good GUI, it's good to look at. The features provide good impact. It lends itself very well to Agile deliveries.

So far the stability has been okay. The stability is: Is the server up and running? In the last year we lost access, maybe once, for a couple of hours. Because it's a SaaS product, we don't know why it came down. We just know that it became unavailable to us. But on the whole, it's been pretty stable. We're not intense users just yet. We will be. In six months' time, we won't be able to afford any downtime really. But we're not an intense user right at this moment.

We may have not noticed when it wasn't available. But in six months' time, that story will change. Obviously, as part of our DevOps pipeline, we will really expect it to be up 99.9999 percent of the time.

In that one occurrence, they reacted quite quickly. We raised a ticket and then had an instant response. They said, "We're looking at it." I can't remember what the actual resolution was. I find Micro Focus quite reactive to issues.

I think it would scale. We've not needed to scale too much yet, but it seems scalable to me.

I think that the biggest obstacle to scaling with this particular tool is the licensing. You predict what licensing you need for the year, a whole year, and you're stuck with that for that year, unless you pay more to scale up. That's always a challenge. The challenge is not the scalability of the solution but the scalability of licenses.

We've just upped our licenses to 25. We started off with ten. Once we get to steady state, in some six months' time, we'll have about 30 steady-state silences.

Regarding the increase in usage, we'll push more work through it. Right at this moment it's just one program of work. Once we're happy with the way we use it, the stability, we'll then push all our organization's work through Octane, rather than ALM.NET. At the moment, the majority of our work is going through ALM.NET. It's just this transformation program that I mentioned where we're using Octane. It's almost a proof of concept for us. If it works with that program, we'll make it work for all programs.

Tech support is okay. So far our experience with them has been positive. They're certainly quite quick to react to the initial issue. Because they've got this "follow-the-clock, follow-the-sun" support model, there have been times when we have raised a ticket and has gone over to a resolving group in South America, and there has seemed to be a time lag in getting our updates. That can be a problem but, because we're not an intensive user yet, I'm not sure if that would manifest itself a major problem.

The initial response seems to be good, but sometimes the follow-up is not quite as quick as you'd like it to be.

When we've asked for details, we've received details. They don't seem to hold too much back. When we've pushed them for detail, we've gotten it.

We were working with Micro Focus on our cloud transformation program. We included them and a lot of vendors, but we had identified the Micro Focus set of tools as the tools we should be using for our DevOps pipeline. That was made through a process of evaluation of other tools. At that point, we engaged Micro Focus and said, "Look, this is what we want to do. How can you help us?" At that time, Octane was just coming off the production line and they said, "Well, we've got this new product which might work better for you." They made that product available to us. So we looked at it at that the suggestion of Micro Focus, given that this new product was coming out.

We'd always had what used to be HPE before it was Micro Focus, so we'd always used the variations of HPE testing tools, ALM.NET and, prior to that, Quality Center. We did some research with industry reviews and, obviously, the Micro Focus set of tools were in the top quadrant. Because we had the relationship anyway with Micro Focus we decided to stick with that toolset.

It was a natural progression, plus the fact that the review sites had the set of tools in the top quarter for being the most integrated set of test tools. We were looking beyond test management tools. We were looking at automation and performance, and the recommendation from those sites was that Micro Focus had the richest set of integrated test tooling. That led our thinking quite a lot.

I thought the initial setup was pretty straightforward for us. We started off with ALM.NET on-premise. We then took the SaaS offering. So our initial challenge was to migrate our existing ALM.NET projects into the SaaS product. We then were made aware of Octane, which was made available to us quite easily, and we were able to start using it.

What we didn't do, because of various challenges with our program, was we didn't really get too involved early because we weren't ready. So although the tool was ready, we weren't ready to consume it. But in the last few months, we've made quite a few strides with that. We're now at the stage where we need to say, "What more can give this give us?" There's a lot we can do. What is it we want to do? That's probably where we are now.

Our implementations strategy for Octane was quite simple. Because we've got this program of work, which is a cloud transformation program, we used that program as a proof of concept with Octane. That program worked, which is lifting and shifting 70 business applications. They are being migrated from on-premise to cloud, and each one of those migrations, on an application-by-application basis, is being managed by Octane. So our implementation strategy was to use it for this program of work. Once we realized the good and the bad, we could then start implementing it across the rest of the organization.

The staff from our side required for deployment was none. For us, it was just a request to Micro Focus and then agreeing to pay for licensing. It's a URL, basically.

For administration within our organization, the overhead is that there are several admin tasks, such as creating new backlogs, creating users, and administering users. It's no more of an overhead than with any other test management tool. The admin side is still the same. You have to set up your folder structures, you have to set up the users, you have to disable users when they leave the organization. It's simplistic and it's quite easy.

Here, because we're quite a small organization, we've got three people with admin rights, and between them they handle requests as they come through. We've got a site admin and a project admin. It's a layered type of admin, as much as it was in the previous products. The site admin can do everything and project admin can do everything within that project.

The product was there for us. As soon as we requested it, it was made available, so there was no implementation, as such, for the product. It was down to us to make use of it, and start creating our backlogs, and our structures, etc.

We relied on the help we get from Micro Focus. There are some good online video tutorials from Micro Focus. We made use of those. We made use of Help topics on the product. Other than that, for any issues, we would raise a ticket with Micro Focus. We didn't actually take on formal consultancy.

I don't think we've reached the point of ROI yet. For return on investment, we're looking at about 12 to 18 months before we start seeing that return. Our return will come when we automate more testing, when we show those results in Octane, and start making more use of the Octane dashboard. That's when we'll see a return on investment.

It's expensive. HPE products, and now Micro Focus, have always been expensive. The license is not cheap, and it will always be a challenge, particularly for small organizations like ours.

It's a good product. You need to consider the cost of it. We didn't do too much comparison against other tools, but I always felt that this product didn't only give you a project view, it gave you a program view as well, which some of the other tools don't. With this tool, you've got a program. You can see multiple programs. If you set up your dashboards correctly, you can get a much wider organizational view. That's where we need to play a bit more with it, to get more out of that capability.

I would advise others to consider the expense, maybe look at other tools, to see if they can do what they want to do cheaper. For us, we felt it was worth the investment.

I don't think we're quite mature enough yet to be able to say that it has improved our workflow. Where we are now, we've proved the integration points, we know how we can use the tool, we know how it can benefit us. But what we haven't done is actually reaped the benefits of that just yet. But in six months' time, we'll see improvements to our workflows and we'll be making more use of the tool for that aspect. We're quite immature in our journey at the moment. Although we've had the tool for a year, we haven't started to use it in anger until the last few months, where we've input all those integration points. Now we've got a set of integrations where we can do exactly what we want to do and now we need to decide how best to use that to improve our workflow, etc.

We're introducing an automated pipeline. Our end-to-end DevOps pipeline starts with ServiceNow, where we will request an environment. That request will be picked up by Jenkins, go off to the Amazon cloud, and stand up that environment. Jenkins will then orchestrate a set of automated tests, using UFT, to make sure that environment is working, and it will pass results back to Octane. At that point, a notification goes back into ServiceNow to tell the requester that, "Your environment is available, and it's been delivered." That's the kind of pipeline we're delivering for each application that we might write. In theory, we'll automate as much of that pipeline as possible. We are on that DevOps journey. It's still a work in progress for us.

Regarding the biggest lessons learned so far from adapting tools and processes for Agile and DevOps, I think it's the culture, spreading the culture within your organization. Some people don't like change, they don't like new ways of working. So the cultural issue, the people issue, is a challenge. 

When it comes down to tools and technology, it's the integration points; doing some proofs of concepts to prove each integration point works and finding out where your limitations are. We found some limitations in what we want to do on the Amazon cloud, which we weren't prepared for. The lessons learned for me are: We should've done many, many proofs of concept, small proofs of concept, to prove each point of integration, and then bring all those small proofs of concept together. If I was to do this again, that's exactly what I would do: small proofs of concepts before trying to build anything in an end-to-end fashion.

In terms of how Application Lifestyle Management Tools can help with the transition from Waterfall to Agile, Octane was created very much with that Agile focus. It gives you that set of tools to create the environment, to create your backlog, to create your sprint, and to give cadence to that and give a reporting view of where you are at. Also, it's not just at the project level, you can do it at the program level. We need to start looking at things from a program level, and how we can expand out. It's the views it's giving you, and the tooling that it's giving you that fully support that Agile-type delivery. We've made it work for a Waterfall-type delivery as well. It's giving you everything you need, for whatever delivery you want: the project view and the program view.

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.