What is your primary use case for Micro Focus ALM Octane?

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

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.

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.

We are using Micro Focus ALM Octane for agile purposes and integration with ALM.

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.

We use Micro Focus ALM Octane for test management.

It's for monitoring the application lifecycle for quality and testing in an agile methodology.

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.

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.

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.

Implementation of SDLC in large companies based on Agile methodology, with accent on test automation. Migration from VModel projects to Agile

We use Octane to track our testing plan for projects.

My primary use case is as a test management tool.

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.

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.

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.

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.

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

We are only using the Quality testing module of Octane to test newly developed mobile solutions or changes. For example, if someone wants to deploy a new promotion of a cheap bundle for 1 GB of 50 ram. Once that goes through the project management and comes to us, we use mostly these three Octane modules: Backlog, Quality, and Pipelines.

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 Micro Focus 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 Micro Focus. 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.

We use ALM Octane for lifecycle management and for testing.

View the comparison document and quality of the document for informational and sharing purposes.

We have a relatively splintered tool set and a number of tools which could not connect all of those things together. Therefore, the use case for ALM Octane was that we were trying to create a single version of the truth. A single source of everything to change within the IT department. I work in the programs management department. We are using the latest version of the product because we are cloud-based. We receive all the deployments as they are released.

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

I work for a section of our company where what we do is host enterprise tools that our consulting projects can use. Potentially, as we get more and more users, we can have hundreds of projects at a time. We're not a typical use case where we have one way that we're using the tool. The tool is being used on various consulting projects. Our use cases vary drastically. We have some people who have told us they just use it for testing, there are some people who just use it for defect management. People are familiar with other tools, like JIRA and ALM and even AGM. Octane is new, so some people are trying to take baby steps into adopting it. Day-to-day, how we typically use it, and how we're promoting it should be used, is for Agile project management with manual testing, including release management, sprint management; end-to-end type of use. We use it to manage our releases in sprints. Other teams within my group also use it for testing and defect management, and that's how we promote it, and train our consulting project teams to use it.

It's an Agile tool for our project-based test management.

We are in the middle of a pilot, an evaluation. We have been evaluating the software for about 13 months. Our focus, at the beginning of the evaluation, was to probe a BDD approach with Gherkin to help us track the end-to-end process from requirements to test automation, without leaving quality aspects behind. That's the first use case. The second use case is that we want to optimize the traceability and integration within the Continuous Integration and Delivery process.

We're using it for test management, to write test cases and we have put it into an overall approach which is called BDD, Behavior-Driven Development. Within BDD we're using Octane to manage all tests, to plan and do test automation. We're doing test automation with IntelliJ, together with TestCafe, which is a pretty nice test-automation tool. We have Jenkins with a pipeline connected to Octane, working the whole process. The main intent is to have a quality solution. Our development is working in JIRA, which means that we have split it. We import user stories from JIRA to Octane and start working from there on our testing.

It's hard to say what our primary use case is. There are so many new changes and options. From the perspective of the general organization, it's the shared space/Workspace concept that is of major interest. From the architecture side, with Elastic and Oracle storage, it gives us fast filtering and it's fast at finding information. On the process side, it gives us the option to control or organize workflow by user stories and tasks, within the different teams.

Our primary use case is using it as a single application lifecycle management tool, meaning all the way from our original planning, requirements, doing backlog management, user stories, test lifecycle management, defects, in a single tool. We consolidated. In the past, we used more than one tool. Our ultimate goal is to have this as our global standard. Our primary use case was to move away from other tools and standardize on Octane.

We use it for Agile: Requirements, backlog, and testing for 80 apps, including SAP and Teamcenter.

We use it for application lifecycle management.