OpenText Software Delivery Management Reviews

We use OpenText ALM Octane as a Quality Hub within our development cycle. It meets our strict audit requirements, particularly those mandated by Dutch Bank for the financial sector.

OpenText ALM Octane is a new product with full development ongoing, where new ideas are launched regularly. Its ability to generate audit evidence with a single click is a significant advantage, as it saves considerable time and money compared to manual processes. This efficiency is especially valuable for audits required by financial regulators.

There is room for improvement in OpenText ALM Octane's flexibility. While it aims to be as flexible as possible for a large enterprise application, sometimes there are limitations that may not meet specific organizational needs. Furthermore, support can always be improved.

We have been using OpenText ALM Octane for almost four years.

OpenText ALM Octane is a stable product without any issues related to latency or performance.

There are always potential limitations with scalability, but OpenText ALM Octane is currently scalable enough for our needs. We can expand the number of servers and resources as required.

We have a very direct line to support and frequently communicate with OpenText's R&D about ideas and resolving issues. However, customer support can always be improved as there is always some room for enhancement.

The installation of OpenText ALM Octane is relatively straightforward compared to other products like Quality Center. However, we need to install additional components such as ElasticSearch, which adds complexity.

We experience significant time and money savings with OpenText ALM Octane. The ability to generate audit evidence with a single click saves ten days of work for ten people, enabling them to focus on other tasks. Quantifying precise ROI is challenging because it depends on end-user usage.

OpenText ALM Octane is an expensive product. However, it offsets costs by saving time and money, thus creating a balance between expenses and benefits. Our organization with over 1500 users sees savings and ROI.

Overall, every product can be improved, and OpenText ALM Octane is no exception. There is room to enhance flexibility, scalability, and support. We do not use AI features due to regulatory restrictions from the Dutch government. I would rate the overall solution as an 8 out of 10.

I have used the solution in my company since we were developing a training information system.

In terms of how the tool has helped improve our company's workflow or how our organization functions, I would say that we have had the CI/CD pipeline going in and doing the development. We would also do the testing, specifically manual testing.

The tool's price is high, making it an area where improvement is high.

I have been using OpenText ALM Octane for over twenty years.

It is a stable solution. Stability-wise, I rate the solution a ten out of ten.

It is a very scalable solution. Scalability-wise, I rate the solution an eight out of ten. Only a handful of people used the tool in our company. We probably have about 30 users.

I never had to use the solution's technical support. If some problems appear in the tool, my team solves them.

I stopped using Micro Focus. IBM, who is the developer for our company, uses OpenText ALM Octane.

I rate the product's initial setup phase a ten out of ten.

I am not on the developmental test team, and it was done on a contract basis. I work in the government as a PMSS contractor, so we do operational testing. We weren't involved in the tool's setup and product configuration.

The solution is deployed on an on-premises model.

The tool's price is extremely high. When I was using Micro Focus, there were ten licenses, costing around 1,38,000, which was outrageous.

I started off with Micro Focus, and I think it was a failure since I did not like the test scripts that were generated. Everything was like a Word document, while a lot of people liked Excel files with images, which is a major reason why we are moving from OpenText ALM Octane and going with Tricentis qTest Manager.

With OpenText ALM Octane, the development team didn't have enough licenses, so they were being kicked out every few minutes. I have not really worked extensively with our development team at all except for going in and pulling my test cases and verifying the defects. Most of my work was related to HP Quicktest Professional and Micro Focus ALM, which were used to meet all my requirements, like in the area of traceability.

To others, I can say that they need to pick a tool that suits their development process best. I spent almost twenty years using OpenText ALM Quality Center, so I knew it inside and out. Going with ALM Octane, I saw how it is a totally different piece since it has a lot of nuances that you have to get familiar with in the long run.

I rate the tool a ten out of ten.

My company has several scrum teams, so we use OpenText ALM Octane for sprint planning. My company also uses OpenText ALM Octane for test management, quality management, requirements management, deployments, engineering purposes, and some automated testing.

The most valuable feature of the solution is that it is a one-tool solution, meaning you have everything you want in one tool, so you don't need to switch to other tools.

I think the area of release management in the tool is an area of concern where improvements are required. In general, the connection between releases and scrum teams needs improvement, as it could be optimized owing to its linkages, making it very uncomfortable as soon as you have strong teams or scrum teams that work with different items over several releases.

In future product releases, the solution needs to focus a bit more on the metric part. The product's dashboard is a metric for productivity and process control.

I have been using OpenText ALM Octane for four years. I use the solution's latest version.

It is a very stable solution. Stability-wise, I rate the solution a ten out of ten.

I don't see any limitations in the product's scalability. Scalability-wise, I rate the solution a ten out of ten.

There are more than 1,000 users of the product in my company.

The solution's technical support team is responsible and helpful, but in our company, we don't require much help in relation to the product as we are able to manage it by ourselves. The solution's technical support is good.

I have experience with different tools, especially Microsoft. I have experience with different tools, especially Microsoft. My company switched to OpenText ALM Octane from Microsoft as it is considered to be a single solution for every use case.

The product's initial setup phase was straightforward.

The solution is deployed on an on-premises model.

The time for the product's deployment phase is something that depends on how much of the product a user wants to use. In my company, we actually indulge in the product's onboarding process team by team and project by project, meaning it's not about just implementing the product all the time but moving in a step-by-step manner.

Around ten people who take care of administration and engineering areas in our company take care of the deployment and maintenance of the product.

I would say that it is an affordable product. There is an annual service fee, which is one of the additional payments to be made apart from the standard licensing costs attached to the solution.

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.

In my company, I don't specifically work on OpenText ALM Octane, but my team works on it. My company uses OpenText ALM Octane as a test management platform.

Since I work for a software company, we use it for the management of test scenarios, how many tests to run against certain features, what are the test results, how long the resolutions or the fixes take, and when we can stop testing the features. The product helps in terms of collaboration and coordination between different teams.

The most valuable features of the solution are its ability to manage test scenarios, test results, and test automation, which are its primary functionalities.

Improvement-wise, I think that the tool needs to be made more flexible and easy to integrate with the rest of the tools in the SDLC ecosystem. There are some challenges when we want to integrate the tool with other products, and it takes time for a team to figure out how to do it.

I have experience with OpenText ALM Octane for a year and a half. I am a customer of the solution.

It is a stable solution. Stability-wise, I rate the solution a nine out of ten.

I haven't seen any significant requirements in my company regarding the scalability aspect of OpenText ALM Octane.

Scalability-wise, I rate the solution an eight to nine out of ten.

Around 250 people, consisting mostly of QAs and software engineers in my company, work on the solution.

I rate the technical support a seven out of ten.

Neutral

I rate the product's initial setup a seven on a scale of one to ten, where one is difficult, and ten is easy.

The solution is deployed on an on-premises model.

I rate the product price an eight on a scale of one to ten, where one is cheap, and ten is expensive. The product is neither cheap nor expensive.

I don't recall the names of the products my company had evaluated against OpenText ALM Octane in the past. The reason why my company chose OpenText ALM Octane is because we were using Micro Focus in our environment.

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.

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

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

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

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

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

I have been using it for three months now. 

It is a stable product. It performs well. 

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

I used Rally. 

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

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

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

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

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

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

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

We definitely use it as our one-stop solution. 

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

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

The platform's most valuable feature is pipeline integration or continuous integration services. It can fetch insights about various deposit points after synchronizing with Jira, IBM, or other tools. It gives visualization through dashboards and reports updates quickly and easily.

The product's requirements management feature needs enhancement in terms of functionality. Also, the release management feature needs expansion.

We have been using OpenText ALM Octane for ten years.

I rate the platform's stability a ten out of ten.

I have worked with around 400 OpenText ALM Octane customers. It works well for synchronizing data.

We had a good experience working in the support team's R and D department. However, they could provide more technical resolutions.

Positive

We used HPE Micro Focus ALM Quality Center for a significant amount of time. From a competitive point of view, no comprehensive tools could cover ALM functionalities better than HPE and OpenText. Almost 80% of enterprise companies use OpenText as a well-integrated solution. It doesn't require the technical expertise required to work with open-source tools. Also, it provides good support services.

The initial setup process is straightforward. The platform has well-defined, out-of-the-box workspaces and projects incorporating good practice workflows.

The product is highly priced compared to other tools. However, it offers substantial value. There is a distinction between OEM pricing and the final pricing for customers. They could understand the delta between the two and work towards a favorable outcome.

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.

Micro Focus ALM Octane is primarily used for test management, specifically to manage all testware in a single location. It also allows linking requirements to tests and tests to defects, ensuring defects are traced back to their original requirements. With ALM Octane, users can manage requirements, allowing for the execution of appropriate tests on the code. If a defect arises, it can be linked back to the test case and requirement for effective resolution.

Regarding features, the ability to work on the whole life cycle management, especially to manage the whole software testing life cycle, is the most valuable in Micro Focus ALM Octane.

In terms of improvements, it would be beneficial for Micro Focus ALM Octane to have the ability to interface with newer page tools that support DevOps for operations and testing. Currently, Micro Focus ALM Octane is considered an old-world tool in the industry and lacks the perception of being a new-age tool among its customers. Changing this perception is necessary to improve the reputation of ALM Octane in the industry.

I have experience with solutions from Micro Focus since my company has had a partnership with Micro Focus for more than ten years.

It is a very stable tool. The tool has been in the industry for so many years. Stability-wise, I rate the solution a nine out of ten.

The number of individuals participating in the deployment process varies. Our company provides testing services, employs 34,000 individuals, and many of our clients utilize Micro Focus ALM Octane. This implies that many people use this tool, after considering 34,000 end-users from our company's end who are using Micro Focus ALM Octane.

For deployment, the number of required tech engineers depends on the size of the project. For installation, one or two people may suffice. However, for usage, there will be many others who need to use it.

The tool itself does not require any maintenance. However, it may require customization based on the specific needs of each customer. Workflows may need to be customized to meet the unique requirements of each customer.

It is a scalable solution. Scalability-wise, I rate the solution a nine out of ten.

Since our company uses the tool for a lot of our customers, we get the best and premium support. Also, all our customers get premium support from Micro Focus if they buy the licensing for the tool via our company. I rate the technical support an eight out of ten. I rated it eight since Micro Focus' technical support needs to understand that there could be specific problems with the customer that they need to understand because, at every place, it doesn't work the same way as there may be changes in the workflow or there may be customization requirements. So, it takes technical support time to understand and give a solution to the users.

Positive

I work with QA Testing Tools from Tricentis and Rally by Broadcom. A competition to Micro Focus ALM Octane would be Jira and Visor's combination.

The solution's initial setup process is reasonably easy. On a scale of one to ten, where one is difficult, and ten is easy, I rate the initial setup an eight out of ten, considering its ease of installation.

There are various options to deploy the tool. In the company that I worked for, we did not use much of the tool. We were only providing this tool for our customers. So, mostly the solution was deployed on-premises even though there were options to deploy the solution on the cloud. The deployment process can be carried out in three to four days or a week maximum.

The pricing of the tool falls in the mid-range zone. When you compare it to other similar tools, I would say it's on the expensive side. The licensing costs for the tool are not straightforward and vary based on several factors, such as the volume of licenses, duration, geography, and customer. The price may become lesser if there is a higher volume or longer duration. Therefore, giving a straightforward one-line answer regarding the price is impossible.

I rate the tool's pricing an eight on a scale from one to ten, where ten is very expensive.

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.

I like the fact that you can use it on top of Jira. 

Let's say for example, that if you have a DevOps team that is used to Jira, they can continue to use any of the Jira solutions and then have Octane layered on top of it from the business buyer's viewpoint to better use it more effectively.

There is no question that everything can improve.

I like their smart analytics; perhaps they should continue to expand and improve there because it's a fantastic start. And I enjoy the testing, especially the automated testing capabilities, so just keep improving on what they have.

I have been working with Micro Focus ALM Octane for one year.

I am reviewing the latest version.

Micro Focus ALM Octane is a stable solution.

Because of HPE's support, I would feel far more comfortable with Micro Focus.

Micro Focus ALM Octane is a scalable product.

We have approximately 500 clients who are using this solution.

They are large enterprises and digital transformation, IT engineers, more business-oriented than DevOps-oriented.

We have not contacted technical support.

We are working with the Hybrid version, but It even extends to on-premises. It is both the on-premises and cloud versions.

The initial setup is straightforward.

I believe it depends on the circumstance, getting it up and running seems to be rather simple. It appears to be suitable for standing up in a bigger setting.

If I compare it to Jira, for example, and you are in a complex environment, you have to ensure that everything is updated and all of the plugins, and everything works every time there is an update, but you don't have that problem with Micro Focus' Octane.

We received assistance from a third-party consultant.

Because I am making recommendations for a client, I lack firsthand deployment experience. I am merely talking to them and assisting them in making decisions.

My clients have seen a return on investment. I can't quantify it for you, but they believe that because it is cohesive and can be used across the enterprise in a simplified manner, it reduces the total cost of ownership, which might be translated into a return on investment.

In my opinion, it's good value for the price that you pay.

I have some experience with Jira and Micro Focus ALM Octane, but I am mostly reviewing them to give a recommendation for a client.

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.

Octane is a relatively new solution for us. We needed better tooling than we previously had and Octane gave us extra flexibility. Our primary use case is for cross-project program reporting and dashboards. We are customers of Micro Focus and I'm a company director. 

The dashboards and metric reporting are valuable features for us. From a development perspective, we use Jira and Zephyr. To stay agile, we need to ensure that our Jira data is feeding into our ALM projects. It's about the real-time integration between the two and bringing that information across accurately. 

I haven't been impressed with the reporting from a requirements matrix and a traceability perspective. ALM has always lacked in this area. They come at it more from a Waterfall testing perspective, and less from a Sprint-based perspective. It's in those areas that we use Jira with some of our development teams. We ran into roadblocks due to the sheer number of users, around 1,500 people using the tool, carrying out testing, and ensuring that people understand the requirements.

I think they need to look at ways of innovating and finding the wow factor with more flexibility and agility in development, but they've never really been good at handling that which is why we stick with Jira. There hasn't been much investment in the tool and there are definitely some areas that can be improved upon.

I've been using this solution for about six months. 

The stability is fine and they give you the capability that you need to run a good quality engineering program. It's what they've been providing more or less for at least 20 years; perhaps it's time for some innovation.  

There's no problem with scalability. 

We don't deal directly with Micro Focus but with one of their support teams through another vendor. We've never had an issue. 

ALM is a little pricier than Zephyr Enterprise. Because of our familiarity with ALM and the fact that we had all the integrations, it was easier to resume using it. 

We compared Zephyr Enterprise with ALM and decided to go with ALM because we have another provider that already had integration with ALM. If we'd gone with Zephyr, it would have required some technical integrations with their APIs and some of our testing tools. From a capability perspective, the two solutions are pretty on par with one another. If an organization is evaluating capabilities versus investment, then they might prefer Zephyr.

I rate this solution eight out of 10. 

We are using ALM Octane for electronic component testing and validation. We have a few departments where they are developing their software and using JIRA projects and exchanging results with Octane. 

About 80 percent of the users are not in software development itself, but are in software testing. The software is developed by external companies and we are just doing the integration testing. We are putting the components together from five different suppliers, and then doing the integration testing. Is the software working in real life, together, from the different control units of different vendors? It is a staged process. We check if things are working in the different parts of the system, like the engine components, drive train, navigation, and infotainment systems. If things are working in those different areas, we put everything together and test it in a complete car.

As a result, we have lots of test cases. We have automated tests and a test automation tool that is controlling complete car-wrecks and the like. So it's not only a mouse pointer on a screen. It's controlling robots opening and closing doors, for example. 

Our main focus is efficient planning of tests. We cannot run all the tests we have every single week, because lots of the stuff has different variants for Europe and the U.S. and China. So we have to have very sophisticated test planning. A lot of attributes are needed for this and for all the runs, whether manual or automated. We have what we call a very large problem management process to work on the defects with the 100-plus suppliers that are delivering different control units and, therefore, software packages.

We use Octane's Backlog and Team Backlog capabilities a lot. For example, we use them for errors that occur in software that we are not developing ourselves, where we are just doing the integration testing. In such cases we are using user stories to order teams to test a certain number of test suites or test cases. We can use it straight away, out-of-the-box, without breaking or adding something to the tool. Using Team Backlogs means our teams can use all the features that come with Octane, for our benefit, without doing anything else. In the past, if you compare it to the old ALM solution, lots of teams had to store their tests and results in ALM.Net and use JIRA as a parallel system. They were manually copying and pasting links into both tools to control their workloads. Users were used to working with user stories as a work order, and that is now integrated in one tool, which is a huge benefit.

It has also reduced our testing costs. I don't have the numbers, but we're speeding up a lot. Just the waiting time we had with the old ALM when logging in was about one minute. If you multiply this by 5,000 users who are logging in on a single day you can calculate very large savings, very fast.

The key feature is the usability. It is fast to learn and easy to use. It's very intuitive to work with. Most of the important functions are available via a few clicks, compared to other tools where I have to open a sub-menu and then a sub-menu and another sub-menu, and then press a button.

The native support for Waterfall, Hybrid, and Agile software development at enterprise scale was one of the reasons why we changed to Octane. In the development process we're creating the requirement specifications which are then handed out to a supplier, including Bosch, Continental, Alpine, etc. They then develop control units with software and we have to link our tests against those requirements to check if everything is implemented. This is a very important task. It's required by law. For example, for autonomous driving, we have to prove that the car is not, by default, running into trees. We are proving that by test cases that are passed. While that is still Waterfall, it's not Agile, we are using the Agile methodologies more and more to control our workload. For example, we are using a user story in test management to order teams to test a certain number of test cases.

In terms of integrations to proprietary, third-party, and open-source tools out-of-the-box, it has a very powerful REST interface. We can interact with other tools. OpenText also offers synchronization tools, OpenText Connect Core, which has out-of-the-box interfaces to industry standards tools. For everything else, you can use the powerful REST interface, which is both good and bad. It's good for creating an interface but sometimes our engineers use the REST interface to do things they should not do. But that's because engineers are always doing fancy stuff.

The elements in filtering need to be improved, meaning the number of filters I can use in widgets or in the grid views in parallel. There's a limitation which bothers a lot of our users. Filtering in text, or having a complex filter is limited. In a given field, for example, I can use a filter only once. I cannot say, "Include the values 1, 2, and 3, and exclude value 17." This is not possible but we have requested it often.

And in general, widgets should be more flexible and more sophisticated, with the ability to layer two different widgets. There is also room for improvement in the amount of test cases which are available for certain filter conditions and a given widget, versus what was worked off already.

Also, when it comes to getting reports out of it, and maybe this is a little bit specific to the automotive industry, there are certain requirements by law where we have to export the test results for the final software delivery and create PDF reports which are stored for 15 or 20 years. Creating reports in PDF, or PowerPoint which then become PDF at the end of the day, is something which could be improved a lot. We're working on it with OpenText in every single release as new features are added.

We have been using ALM Octane on a production scale since the middle of 2018. We started digging into the different tools about one and a half years prior. At that point our idea was to change from ALM to whatever other tool. We decided to go with Octane in early or mid 2017.

We are trying to use the latest and greatest version. We are now updating to 15.0.60, the so-called "Beatles" release, because of one technical issue that we solved together with OpenText. But in two to three months we will be on the latest and greatest "Depeche Mode" version which will be 15.1.40.

It's stable, out-of-the-box, with very few errors. And if we get an error message, very often it's because of the complex rules we have implemented, ourselves, in Octane. But in general, the usage of Octane is very good, the quality is very high, with very few errors and bugs, and with high reliability even on a large scale. We are close to being the largest Octane instance for OpenText.

The scalability is pretty good. We did some load tests in advance, before making the decision, pro or con, on Octane. With Octane we are in a very good position. We expected to have some 5,000 users by the end of 2019/beginning of 2020 working on Octane. I believe it can go up to 2,000 users working in parallel. We hope to be powerful enough, with the architecture and everything else we set up, to meet users' expectations of performance.

We are involved in further step-by-step expansion of our use of Octane. For this year, we are planning to extend the native Octane usage of test automation, the DevOps module. We are introducing it and maybe we will be able to replace some home-grown and other tools and to integrate them into Octane to have the benefit of Octane. It would be helpful to have everything in one place for the monitoring and reporting possibilities. Our processes and needs are changing from time to time, and this is always reflected in the test management tool.

I'm very proud of the opportunity that OpenText offered to our team, to be something of a design partner. We have a very strong relationship with R&D and are able to discuss user wishes and our needs directly with them. They listen very carefully and try to deliver solutions for our problems and enhancement requests. It is amazing to see how fast and how stably things come together, even if some users are complaining because their single feature request has been open for two years. But that's because we have more important ones. It's an awesome relationship.

You also have to take into consideration that Octane has become an industry standard. Lots of different companies are using it. From that point of view, you get to know how complex the work is for OpenText, and how valuable a good relationship is. I'm very thankful for being part of this kind of working together and improving the tool.

And it has often turned out that our requests and wishes have had a huge benefit for other customers.

The benefit of this design partnership, which is unique, is a plus for us. We are able to influence the tool and get features, especially within the timeline that we need them. That's one of the biggest advantages.

We knew we needed to go with Octane for a couple of reasons. From the business side, there were some requests which ALM could not cover, in terms of data storage, etc. Since we have so many test cases, and given how versioning and base-lining work in ALM, it would require so much storage that we were not using the versioning in ALM. This was one of the biggest pain points from an ISO perspective in terms of testing. Also, operation maintenance was hard. We were running the biggest ALM.NET instance in the world, according to OpenText. We had the most users, the most data, and the most complex VBA workflow code in a single instance of ALM. This needed to be migrated smoothly to Octane.

In addition, Internet Explorer, which is not the finest tool, was removed from our company's IT at the beginning of 2020. There were a lot of smaller reasons which lead to the need to change to a different tool, to a more flexible tool, to a more powerful tool. For example, the Autonomous Driving guys were going to be adding tons of test cases and automated tests, which would cause ALM, in the configuration we were in, to crash in the future. That was clear, and it was clear to our management as well. We only had a small time window to change to a different system.

For us, it was a very complex setup. It was not only setting up a server, installing Octane, and doing configurations. Our plan was to have a shared Workspace concept with six or seven Workspaces. We did have a major challenge in doing all the configuration stuff, defining methods and processes. We also had to connect at least ten major tools or databases, which are synchronizing information into Octane, or which are used for the special methods of test planning and test automation; pulling information from Octane and running them on our test benches in semi-automated cars.

That was a very complex process.  There were some small problems and some bigger problems but we found solutions for all of them.

Because we have some 70 to 80 suppliers that are part of an automated defects exchange, our development, our testers, are reporting defects and those defects are exchanged with those 70 to 80 suppliers. So it's a very complex situation we are in.

Of course, users have to learn different things compared to ALM.Net, the old version of the tool. But we're getting good feedback from the users that as soon as they are used to the idea that they have to use a different tool, they are learning how to use it very fast.  There are fewer obstacles in the tool, in this regard, compared to others. Even if you're a JIRA user, you have to overcome that, "I have to use a different tool" issue. There are people who are doing this very easily and with a smile, while some are just trying to stick to the known tools. But that's the change process.

For deployment and maintenance of the tool, there was a major team of experienced IT guys and process guys from our side, about 25 people, supported by about 60 other people just for the special processes of the different development departments. We call them "key users." They are collecting information and reporting it to the core team. For maintenance, it's a team of six people who are implementing changes requested by the core team. Depending on the workload, on average, maintenance is done by three people. There were numerous software developers working on the interface tools, perhaps some 30 IT guys working on the different tools we needed to launch with Octane.

I was not part of the cost negotiations. But the purchasing guys confirmed that OpenText offered the best pricing to us.

We started analyzing which tool we should use for the future a few years ago, and we started digging into Octane very early. 

Options we considered included JIRA, which is used by a lot of small teams. There is a standard toolchain around but with the amount of data and information we need to run, JIRA was very easy to strike from the list. We dug into IBM and PTC Integrity. We looked into ALM Octane vs codeBeamer ALM from Intland. We did some comparisons but ended up with Octane.

With JIRA and the toolchain, you cannot run a business like ours, doing car development, using a lot of plugins to get the needed functionality in one tool. You have so many small companies providing those plugins. What if the company providing one of the tools or plugins you're using collapses or doesn't support a new JIRA version? So this was not an option.

PTC is also using different tools to support the full functionality of requirements, test cases, team management, the backlogs, tests and defects, and so on.

codeBeamer was on the short-list and was the biggest competitor to Octane. But from our perspective, Octane did much better in performance. Octane is not able to do as many relations between the data objects as codeBeamer, but performance was the key factor for us. When you compare Octane to codeBeamer ALM, the UX concept is very good. What's also very important is to have good capabilities for getting reports about the system out of Octane in real time. The reporting engine, the widgets, and the dashboards are a huge plus.

This is still an area where we have lots of feature requests at OpenText to enhance things even further. We would like it to be more flexible for the users. We have lots of user-defined fields and lists so users are requesting more capabilities for enhancing this area or would like the possibility of filtering their work items.

We were setting the foundation for the next eight to ten years. We had to have that in mind, as well as the increase in data, the increase in users, the increase in data objects and rules, and the complexity of development which is divided into different pieces. To cover all this in one single tool led us to Octane. Cost and license fees were also a big issue. The two solutions, codeBeamer and Octane, weren't that far apart but, here as well, Octane was first.

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.