OpenText Software Delivery Management Reviews

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

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

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

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

The solution is frequently updated with new features.

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

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

Micro Focus ALM Octane is stable.

I have found Micro Focus ALM Octane scalable.

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

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

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

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

We have used Jira previously.

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

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

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

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

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

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

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.

I work for a state government in the United States. So our business constituents have departments that use it. And we have analysts who build business cases in the ALM Octane for specific tasks or specific projects that we're working on. We create business rules for each project in ALM Octane. Then, when the developers finish coding and we're getting ready to test, we use ALM Octane again to test against the business rules we created. So that way, we know we're meeting our business objectives, our customer's requests, and what they want to be changed in our system.

It's more streamlined because we have it all under one umbrella. And once the business requirements and rules have been created, we can do test cases and apply them to the business rules. So we're able to make sure that the developers' code is tested thoroughly to meet the needs of the business.

It would help us if ALM Octane got FedRAMP-certified, so our government departments could use the cloud solution. That way our external consultants could access it. We've created a URL to get to it, but if it were FedRAMP-certified and service and had support in the continental United States, that would be better. In the government space, we need organizations or companies to be FedRAMP-certified, and the system must reside in the continental United States. The Micro Focus help desk and their environment are not located in the continental United States, so they do not meet the state's criteria for us to be on the cloud. I understand that the company is working on some FedRAMP certifications and is looking to do that because they cannot put all of their government customers in their cloud environment. It's not a technology issue. It's a security issue.

So we've been using Micro Focus for almost four years now, but we just recently migrated to Octane back in July of this year.

ALM Octane is very scalable. We have a great server team that we use to increase its space or size. We handle it internally, but it works great. 

We have worked with Micro Focus support, and they're very good. I'd say 9 or 10 out of 10. They're always available. And if they don't know how to fix an issue, they know to talk to. It may not be the person you're talking to or the person they've referred them to, but they know somebody who could help. So they know how to escalate within their organization.

So before July, we were using IBM DOORS Next Generation for business requirements.  Then we decided to consolidate the business requirements, testing, and defect management into one system, and Octane provided that solution for us. So we were able to decommission IBM DOORS Next Generation for business requirements after our July implementation to ALM Octane.

We looked at Micro Focus ALM minus the Octane solution about two years before they decided to go with DOORS Next Generation. And they selected DOORS Next Generation, but IBM's integration with Micro Focus wasn't very mature. So it required a lot of manual tinkering to get the two systems to talk together. Finally, after some analysis about how much time was being spent, staffing resources, etc., we just went with ALM Octane.

Setting up ALM Octane is straightforward because we were already using Micro Focus ALM for testing. We were implementing it in the business requirements area. That was four years ago, so I can't remember exactly how long it took, but it was a few months. I'd say maybe two to three months. We did it on our own with Micro Focus guiding us. And Micro Focus had a statewide user base at the time. Other departments were using it, so we were able to share what everyone was doing. I have two FTEs. One is in charge of the business requirements module, and the other oversees the test testing and defect management.

I think the cost of ALM Octane is comparable to other solutions. It's actually a little less than DOORS Next Generation, but I don't have the numbers in front of me.

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.

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.

ALM Octane is used to manage our software delivery. Currently, we are running the hybrid mode. We use traditional waterfall delivery as well as agile. 

• For waterfall delivery, it is managed completely. Then, we have our requirements and our test cases to cover those requirements as well as the defects. 
• For agile, we currently have only one team. So, all team activity happens in ALM Octane. Their backlog is broken down into user stories tasks, then covered by the test coverage.

We have installed it on a Windows Server on our systems.

ALM Octane natively supports waterfall, hybrid, and agile software development perfectly at an enterprise scale. 

1. If you look at the Requirement module, then we see all the defects and test cases related to waterfall. 
2. If we look at the Backlog module, we see what the agile team works on. 
3. If you want to see it at the component level, then imagine that we have a CRM system where a release project of waterfall makes a delivery and the agile team also makes a delivery on that component. 
4. We come to the Quality module, where if you select that component, then both streams would be represented there. 
5. If you select in the Quality module components, then we could see that, "Okay, this is linked to the defects from this source and that source. These are test cases covering that." 

This was one of the key aspects of why we took ALM Octane. 

With ALM Octane supporting agile, this reduces complexity and the need to manage multiple tools. We are still working on some automation that would further make us more efficient. So, we are building in-house tools to reduce the manual work.

Our user experience has been greatly improved.

In the current organizational structure, our development teams and testing teams are separate. With this transformation, I think the collaboration will increase, and we are on our way to put these teams closer.

We are very much moving towards DevOps in certain parts of the application. We are starting to develop these microservices and running a proof of concept where we want to integrate our Jenkins pipeline, which builds and deploys the application into Octane. For example, if there is a defect in the content, then what defects are being deployed through this pipeline? Octane really supports DevOps with the Pipeline module using the comment information in the items, along with integration from the IDEs. So, once our PoC is done, then we will utilize the DevOps features.

Currently, we have our hybrid delivery model, where waterfall still is a big part. So, if I look at ALM Octane from the module perspective, we are utilizing this requirement module. We took our day-to-day, grouping them by releases. Our requirements are stored in Confluence and ALM Octane. So, our project managers draw their requirements in Confluence, then we have a synchronization where requirements are brought into ALM Octane. Therefore, from the module perspective, the most valuable feature would be the Requirements module. 

We utilize dashboards for all their reporting capabilities to see where our software is from a quality point of view: test progress, defect trends, and so on. 

We are big fans of the Pipeline module, where we have our automated tests running on Jenkins and our pipeline is integrated into ALM Octane. 

Octane provides multiple plugins and integration with IDEs, so developers don't even need to log into ALM Octane, for certain scenarios. They only need to install the plugin into their development environment, i.e., Eclipse, Visual Studio, or IntelliJ. Then, they can sync their work items to this IDE where they can easily see what defects or user story is assigned to them. They can work directly from there by adding comments, changing the status, or even committing the code. This also applies to the pipeline for Jenkins. 

There are a lot of predefined reports. We can attach additional reports for users, like who worked on what defect and when, as well as what is the status of the release compared to the previous release. It is really endless. All the data is really linked together. Then, if all the data is linked together, there is an option to prepare reports out of it. We are very impressed with its reporting capabilities.

They provide all data integration. So if you have an edge use case, which you cannot do with what the tool provides, then you can set your data through all the protocols and even prepare it for the reports. I think they are very strong in this area.

On a team level, it is really good. We have received only positive feedback from our teams. It is visual, so there are different ways for teams to see their backlog. If they wish, it can be viewed like a list and a board, where you can look at the content per screen, release, or for the whole backlog.

The tool is very intuitive. However, it is still new, so you still need to learn and explore it, but that is a standard thing. Initially, we did receive some questions from teams, "How do I do this?" and, "How do I do that?" However, in very recent times, since it has been up and running, teams have enjoyed the fast, modern, new platform.

For the PoC, we have ALM Octane integrating with our CI server for continuous integration and delivery. We have it integrated with Jenkins. We haven't integrated our other server yet. We are still exploring the solution.

ALM Octane is working to soon provide comment information, so we would really be able to see what piece of code was committed for a user story or feature. We are really looking forward to this, because it's going to give us a bit more traceability and transparency.

They don't support all IDEs yet. We have Visual Studio code, which is not supported, and loved by our developers. This integration is missing. We also had to do our own in-house integration with the Confluence. That is also something that they could add. 

There are small things, like hiding different columns when it comes to the board. Currently, whatever workflow items you have defined in the board, you can collapse them, but a collapse line still appears. These small things would make a difference.

In certain areas, ALM Octane has a limitation how many items can be displayed. So, if I group something, then I'm limited to the number of items which I can see. Also, if I want to export in Excel, there is a limitation onis lines. I know it's 5000. Maybe the number is quite high, but if they could improve on those limits, that would be good.

We did a migration around Midsummer. That was about six months ago.

It is very stable. With our current setup, we haven't seen any performance issues.

Very little maintenance is needed. No one does it full-time. We have five people who have the admin rights, then two people who act as a backup but don't really do anything.

It is scalable. We can add additional nodes without a lot of effort, if it is required. There is an option to scale from a license point of view. From a hardware point of view, we can also add multiple nodes to support additional loads.

We have about 1,000 users. 

We have an excellent guy who helped us with the whole migration project. We have already built a good relationship with him, so much that we don't always go through the official channels. He still takes our questions via email if we need the clarification on certain things. Additionally, the official OpenText support channels are also good. We raised a couple of incidents, which were addressed by the team. 

In the past, we had ALM Quality Center to manage our waterfall deliveries. Once the company took the decision to do the transformation to agile, we needed a tool that could support both waterfall and agile, but not compromise functionality. This was a key factor why we took on ALM Octane. We knew that the transition to agile would not happen overnight and that we might be in the hybrid model for a while, which is the exact reason why we took on ALM Octane.

It is very much integratable. This was a piece that was critical for us because ALM Quality Center was used by our company for more than 10 years, and it was very easy to integrate. Before we could migrate to ALM Octane, we needed the integration to be in place for a new tool. There are different ways to integrate, through the REST API, plugins, or the MF Connect tool, which also comes with ALM Octane.

Because we were coming from a very old Quality Center version, we have become more efficient because the work can be done faster.

The deployment was straightforward. The documentation clearly states the requirements regarding what hardware is required. Additionally, all the installation and deployment guides are good.

The deployment went through phases. First, we installed the system, which was pretty fast. After that, we migrated all the data from Quality Center, which was an additional task.

The upgrade was super fast. We were so impressed. We ran a test first, but after that, it took maybe 90 minutes altogether. That includes the backup of systems. Before the upgrade, we backed up our Elasticsearch because ALM Octane comes with Elasticsearch, and in our case, it runs on Unix machines. So, we backed up Elasticsearch, the data repository for all the attachments, etc., then took a snapshot of the database and the Windows machine, which was the longest part. Some of the snapshots, we did in advance, and some of the snapshots we did just prior to the upgrade. 

We did two upgrades at once because we missed the previous one. The upgrade to 15.1.20 took about 10 minutes, then we did some checks and everything was working fine. We then did the further upgrade to 15.1.40, which was another 10 minutes. 

One person with a bit of hardware knowledge can do the deployment. Because we did a migration project, we had a team of four from release management, but this wasn't our full-time task.

We also had support from OpenText.

The testing team has said that can work more efficiently and that the setup of the testing at the beginning of the release is faster.

We already had Jira in-house, but its testing capabilities were insufficient and not scalable enough for our needs.

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).

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

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

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

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

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

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

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

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

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

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

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

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

From the stability perspective it's okay.

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

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

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

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

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

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

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

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

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

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

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.

Its user experience made us a lot happier than using other tools, making it easier for non-IT teams to work together with IT teams.

Octane provides us with a single platform for all automated testing. Our test management is a lot more transparent and successful because it includes the team (the non-IT user and the developers). We are more streamlined and running a lot faster. The single platform for all automated testing has 100 percent affected collaboration between development and testing teams because everything is all in one place.

Octane integrates with your CI server for continuous integration and delivery. This makes us go faster, providing overall transparency during stages or phases.

The solution provides a single, global ALM platform that supports all our agile and waterfall needs. This has improved the overall quality of our DevOps by a lot.

The user experience is a lot better than any tool that I have used before. Overall, it is great. It has a smooth interface, which is very user-friendly. It makes it easier to work together and have more transparency and customization, which is very good. There are a lot of features where you can add fields, input individual fields, and input rules, like templated rule-based interaction between entities. 

The Backlog management is really interesting, because it is all in one place. You don't have a feature here and a feature there, instead you have the Backlog and testing using different backup items, like user storage features and tasks, all in one place. In addition, we are able to write documents, which we can transfer to backup items. Then, we can test them in the same solution without switching tools, or even switching from one part of the tool to another part, because it is all in one place.

We use the solution’s Backlog and Team Backlog capabilities. They make our DevOps processes easier through transparency and asset collaboration.

It could use just some small improvements. I would like additional features, like planning features, user story mapping, or connection to collaboration tools. 

We have been using it for two years in a client company. We have also used it for several of our teams as well as IT related product development.

We have used it now for two years, but only in the last six to 12 months have we really been going all in.

The stability is perfect. We haven't had any issues.

We are not using the most recent version. There are two more updates, and we are already thinking about updating to the newest version.

The scalability is excellent. I don't think there is a limit.

We use it quite extensively. We have about 30 teams working on it with approximately 10 projects, and we are definitely expanding.

The technical support is really good. I would rate their support as a nine out of 10, as there is always room for improvement.

We do use the community that is offered. This is a very good point for identifying issues in terms of how we can use additional features.

We switched from Jira. The main reasons that we switched to Octane:

1. Provides a single tool.
2. A lot smoother user experience.

The initial setup was absolutely perfect and very easy. It was fast getting into the work. We were up and running in a very short amount of time. We switched from one tool to another in days, which is very good. 

We did it ourselves. Just a couple of people were involved in the deployment.

Octane has reduced manual testing time in our organization.

The solution has reduced our testing costs.

It has reduced integration costs by building a streamlined application delivery pipeline connecting to all IDE, CI, and SCCM tools.

The solution has helped us to produce releases faster. 

We did not really evaluate other options. We were introduced to Octane and found it to be a good idea.

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.