OpenText Software Delivery Management Reviews

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

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

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

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

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

Micro Focus ALM Octane is a stable platform.

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

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

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

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

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

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

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.

We use Octane to track our testing plan for projects.

Octane works well with the Jira portfolio to track the project with two methods: Agile and Waterfall. We can track all the testing in Waterfall or Agile and synchronize it with Agile tools.

The limitation of Octane is that we can't do a release outside of the sprint. We can only plan the release in the sprint. With Agile and JIRA tools, we can plan the release outside the sprint and do a global release of all the projects from the sprint. It would be helpful if Octane had a portfolio follow feature so we could follow the project portfolio. We need the all-view of a project to track it step-by-step and stay on deadline. 

We started using Octane two years ago.

Octane has been stable so far.

Octane is scalable. We're looking to scale up in the next year.

The end-user in charge of testing could easily deploy Octane, onboard new users, and train new users.

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

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.

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.