Do a quick scan of tools in the market and dig into your needs. Especially for a project with a lot of users with different styles of working together, Octane is the best tool because of the shared space/Workspace concept. Management is able to get a total overview of all the projects or workspaces and the teams are able to operate in their particular styles. That would be my advice.

For small teams, there might be different solutions that are cheaper, JIRA for example, and tools that are more flexible. But if you need to run bigger businesses, Octane is the best because it's replacing a whole toolchain.

The solution can provide a single platform for all automated testing but it's a little different for us because of our strong dependency on hardware, like robots, for automation. We need to have a robot that presses a button, for example, for real end-to-end testing. It depends on the types of errors you're working with. ALM Octane is integrated and fully supporting every task. But on some levels, because of our special needs, we have to work with third-party tools and we then use Octane as a single point of truth for all the results.

Integration of ALM Octane with your CI server is possible and we are working on that so that we can use the features of Octane and connect it to our different departments and solutions. The idea is to try to streamline things and make Octane the central tool for those use cases. Although it's possible already to do this, we have to use some workarounds because of our tools and the way we use the solution. It takes time until the central tools are supporting various processes and, in the meantime, people develop their own processes and their own little tools and they want to stick to their working solution and not start all over again. This is going on in different departments and different areas of the company. So if you then try to integrate all this in a single tool, at the end of the day, you are taking away their "toys" and their "babies" that they invented. So it's a work in progress. But it's possible and it is on our agenda for this year.

The solution hasn't reduced manual testing time in our organization yet, since we are just starting with the integration of our test automation and Octane to create a workflow and process where everything is integrated. This is something we are working on. The first step was to replace the old ALM for a certain number of user groups. We now have more than 7,200 users working in Octane, and we have more than 1,000 concurrent users working in it. It takes time to develop this. But the goal for this year is to integrate it and to use it more and more efficiently. And then it will definitely reduce automated and manual work.

Micro Focus is an English company. We're a small US-based company that is a master reseller for all the Micro Focus products. I sell the product. I'm a vendor.

I’d rate the solution ten out of ten.

I rate this solution eight out of 10. 

I recommend the solution to those who plan to use it.

I really like the progress made by OpenText ALM Octane since I have seen many features being introduced lately. I believe that there are still some features left to be introduced in the solution. I would be happy to see some new features in the product. I would like to see the product offer some optimization to users, along with some improvements in terms of metrics and dashboards.

I rate the overall solution an eight out of ten.

A lot of people, when they pick up this tool, are focused on one specific aspect of it, like Agile planning. They're doing backlog management, release planning, sprint planning, etc. But I would suggest looking at the broader, end-to-end application lifecycle management tools, which includes hooking up into your Dev tools, integrating it into your quality lifecycle, and the pipeline module. That's especially true if your company is an Agile shop and you're doing a lot of automation. In that case, you need to look into Octane and really understand what it offers. I think a lot of people probably don't appreciate or don't understand, they're not aware. Keep that bigger picture, the end-to-end lifecycle, in mind and see if there's any other tool that fits like Octane.

I would rate it at eight out of ten, which is still a high score for me. It is still truly evolving. I work with Micro Focus and, looking at the product roadmap, there are a lot of good features coming.

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

I recommend using the free version before purchasing. 

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

I have familiarity with Micro Focus ALM Octane because I'm currently using it. I'm using the latest version of the solution.

As it's only been a month since Micro Focus ALM Octane was implemented, only three people use it within my company, in particular, administrators and engineers.

For the deployment and maintenance of Micro Focus ALM Octane, one experienced person is sufficient.

My company has plans to expand Micro Focus ALM Octane usage.

I'm still not sure if I'd recommend Micro Focus ALM Octane to others because I'm still exploring it.

I'm rating Micro Focus ALM Octane as seven out of ten because other products have better integration with open-source solutions versus Micro Focus ALM Octane.

I'm a customer of Micro Focus ALM Octane.

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.

I rate OpenText ALM Octane a ten out of ten. It is a great product considering ETL and DevOps methodologies. It integrates and synchronizes well with other tools as well. I advise others to understand the business requirements before making a purchase decision.

I suggest to those planning to use OpenText ALM Octane to ensure that the workflow and the tools that you use can collaborate and integrate with the product.

I rate the overall tool an eight out of ten.

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. 

My suggestion for those considering the solution would be to first understand their needs. In some cases, this tool may not make sense for smaller organizations. However, for medium or large organizations, using a tool that can provide a lot of value is definitely worth it. Careful consideration should be given to why they need this tool and what they are looking for, as there are now many options available. In the early days, there were not many options for a tool that could link requirements to testing and execution. Now, there are many combinations and smaller tools available. Depending on the organization's needs, they will have to decide whether this solution can help them.

There is a lot of competition, and there are many lightweight tools that are able to do whatever Micro Focus ALM Octane does. The other reason for my rating of the solution is related to some customers' perception of the tool being outdated. Some customers may expect the tool to have the latest features, such as built-in artificial intelligence capabilities. Overall, I rate the solution a six out of ten.

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.

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

I rate MicroFocus ALM Octane eight out of 10. It's a great product. If you want to integrate your business requirements with your testing and defect-management tracking, it works beautifully.

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.

ALM Octane is complex and difficult to use, so you have to be willing to train the people who are going to be working with it. I would rate it five out of ten. 

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

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

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

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

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

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

The way that we approach it is that we don't rush into a decision and say, "This is the tool that we have to use." One thing that's nice is that there's always an option for a SaaS trial for 30 days or 60 days. Micro Focus has been very kind to us and given us extensions on our trial versions so that we would have enough time to evaluate the tool and the SaaS version before we make a full, educated decision about how we want to move forward. That's a good place to start: Plan on getting a trial version and plan out your assessment, what your objectives are, what your requirements are for the tool, and then just get in there and start using it.

I use Octane in my day-to-day work, but I'm mostly an administrator of the tool's usage on our consulting projects.

With respect to how tools and processes are evolving to adapt to the change from traditional Waterfall, one of the things our organization is finding is that it's not a switch that you turn on - that you're "traditional" one day and you're "Agile" the next. So, having tools that are flexible enough to accept variability, and that are flexible enough to adjust to project teams transitioning and becoming more Agile as they go along, is important. Octane, because of some of the additional features that are there and that are not in some of the other Agile tools we've looked at - like the Quality module, the quality story, the ability to customize workflow and business rules, and also having the Requirements module - lets you still be a little bit traditional when you need to be, while you're learning to become more Agile. There's some transitioning that the flexibility in Octane lets you do, where other tools might be more rigid in enforcing pure Agile project management.

As for lessons we've learned about adapting tools and processes for Agile, I feel that's very similar to what I just said. It's this journey that people are on. Where we started was with very traditional project management tools and, as Agile became more the trend, we recognized the need to add more tools into our landscape that would support it better.

The way that we work is that, while we host all of these enterprise tools, we don't enforce that these are the tools that are to be used on projects. We have to be a bit more flexible than that. Recognizing the need to have enterprise tools available for project teams that couldn't find their own tools, or clients that didn't have their own tools, that's where we brought in AGM and then, eventually, Octane when it came onto the market.

The other thing that's helpful to recognize with this transition, is that you can't become Agile on day one, once you make the decision that's the direction you want to go. It's very good that we have the ability to integrate our more traditional project management tool with our Agile tool. Currently what we support for project teams that are doing a bit of both, what we used to call "hybrid," is their integrating of their Agile project management tool, like AGM or Octane into a traditional workplan tool like PPM so that they can see the full breadth of their project progress across both more traditional tasks and Agile tasks in a single place. We're bridging that gap by using multiple tools and integration.

In general, ALM tools help in the transition from Waterfall to Agile because you have a tool enforces some processes, and provides a little bit more rigor than you would have otherwise. Having those ALM tools available has helped us enforce some consistency and adherence to Agile processes.

To date, we've had 136 projects, that's 136 workspaces, and about 1,000 users.

In terms of increasing usage of Octane, we deployed AGM and ALM four or five years ago. The problem in our organization - and this is another thing we've talked to Micro Focus about, and they're hearing similar feedback from other places - is that people are used to what they know. If people have used AGM or ALM on a previous project, they're just going to go with that.

We do have some early adopters. People have been keen, they've heard about this new tool Octane, checked it out, and those early-adopter types were on the bandwagon pretty soon. There are some people that are lagging behind and kind of skeptical. We're dealing with the psychology of that. Part of that is knowing there is not really a great reason for us to continue supporting two tools that do very similar things. AGM and Octane have a lot of overlapping capabilities. We're looking at our strategy for how long we want to continue to maintain and support two tools that do the same thing.

We're trying to encourage people who are used to using AGM, or are leaning more that way, that they should come over onto the Octane side, because that is the direction that the vendor is going in. That's where the investment is going, and that's where all the new functionality is coming out. We're trying to increase adoption in a variety of ways to get those people onto the Octane side.

We have an assessment planned early next year to strategize when we might scale down AGM, and maybe even cut off provisioning new projects, but we don't know the timeframe of that yet.

In terms of maintenance of Octane, their roles are project manager-types, people who do the server administration, and DBAs. There's also a QA group and a PMT group that we enlist on a very short, annual basis to do our performance testing.

I would rate Octane at seven out of ten. There's definitely some functionality that I think could make our lives a lot easier, especially around the extraction of data and the reporting. Those things would really help us out. I'm conservative on rating things.

My advice, going on my experience to date with Octane, is to be sure you are ready to support the demands for licenses. I have found that once a team gets access, they will not go back to the previous tools and will want to convert everything. Make sure you have guidelines in place on the CoE's expectations so the teams actually use the tools for SDLC and not as a replacement for simple request tracking.

In terms of our biggest lessons learned about adapting tools and processes for Agile and DevOps, building templates and standards that have provided a lot of value in a Waterfall approach do not migrate well to an Agile practice. Previously, we focused on testing, mostly in isolation from requirements and development. Moving to Agile in Octane switched the primary usage to backlog (requirements) focus. The challenge has been to bring focus back to testing and quality delivery in concert with backlog management.

The challenges we faced with ALM Quality Center were the test and defect management capabilities. There was a difficult process in place to track and link requirements and releases. In ALM Octane we are finding the reverse. Requirements management, release, teams, etc. are exceptional, but we are finding the users are less focused on the testing and defect management capabilities.

We have 1,000-plus users using this solution in every role. Most are team members but we have admins and integration teams assigned to every role, including custom roles we've set up. In terms of staff for deployment and maintenance, we are on SaaS. Our CSM manages that side of things.

We have been using Octane since it was released, and maybe a little before that. Octane is a corporate standard and we see no reason to not continue migrating teams - that are ready - from Waterfall tools to Octane. We still support 3,000-plus users in Quality Center who could potentially migrate at some point.

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

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

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

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

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

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

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

Systems and technologies are evolving as well as methodologies.

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

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.

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.

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.

I would rate this solution as seven out of ten.

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.

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

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

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

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

It's 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.

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.

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

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

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

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

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

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

I would rate this solution an eight out of ten.

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

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