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.

Coming from an HPE Quality Center/HPE ALM background, in the company, I think Micro Focus has done a great job in redesigning the overall user experience. We've seen a big increase in the adoption of the tool itself. The amount of time we spend on training, in general, has definitely come down. People find it very intuitive.

The real value is that we're able to standardize, and project teams are more vested in, or interested in, actually doing their standard activities in the tool itself. The value is in the adoption, that people are willing to use it for the purpose for which it was put in.

We have gained some efficiencies. We had a challenge in standardizing our tools. Sometimes activities were tracked within the central depository, sometimes they were outside, on multiple tools. Standardizing on a single tool, and standardizing our process brings us value. It is definitely saving us some time because it's very simple from a user perspective and it's more efficient.

It can simplify testing by structuring it after the application modules that you are defining yourself, and these are both tests and defects connected, which helps you control the quality in different areas of your solution that you deliver.

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.

Octane has definitely improved the capability that we have for visibility within our tool set. The ability to report and see the current status on change, defect, and test runs on a spring by spring basis within our programs. Previous to this, change management was done in one system and testing was done in another system. Defects were in one of those systems, but they were like forgotten children and weren't really linked to anything. 

Octane has made everything a lot more visible. It's ability to relate everything together and create spider diagrams of change, the lifecycle of that change, defects, and the test status. These have made a massive difference to the visibility and our ability to trace back to the origin of a change, where it started, and see how it finished.

It's beginning to improve our processes as well. We are seeing some real improvements in the way we do things. We are becoming more agile in the way we do it because of that and in a way that stories are managed. Stories are given lifecycles as opposed to just being entities within a tool.

The visibility that we received from the ALM tool is that we can see a change through from its early requirements all the way through to development check-ins to the pipeline release then to the point that it's deployed. We can see the full lifecycle of the change within the ALM tool including integrations that we never before had in a change management tool. It's almost revolutionary for some people here to see check-in information appear against a user story in an ALM tool.

One of the things we're working towards is DevOps. With an Octane project, we have our automation, our requirements, our tests, our pipeline into build-and-deploy, and the ability to identify problem areas. It makes things quicker because it's more along the lines of an automated process. I would estimate it saves us 20 percent in terms of effort and time. We haven't gotten to Nirvana yet, which would be full automation, but we're trying to achieve that.

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.

Throughout the evaluation, we've sensed that we have better collaboration among these three roles, the business, the testers, and the testing automation engineers or the developers. From a functionality point of view, we have been able to execute more testing automation on this particular pilot team because of the integration between the tools.

These are things we can see from the daily work between the teams. It's a feeling that everything is moving a little bit faster, it's a little bit easier.

Right now, we have a lot of tools facilitating the BDD syntax but they are scattered. For example, the product owners are working with JIRA or other application products, like Confluence. The developers are working inside their IDE. And the testers are working somewhere else, for example, on ALM.NET.

We thought the possibility of having a single platform which can connect all three roles, centralize them into one platform, would be helpful. It's quite difficult because if you write the feature files first in JIRA, for example, you have to copy the content of the feature files to the testing tool. With ALM Octane, it is possible to have synchronization between JIRA and ALM Octane, if we are using both tools. But there's also the possibility that we use only ALM Octane for both the requirements management and the testing.

By clicking a button after we have the feature files in ALM Octane, we can send a message directly through the IDE plugin of ALM Octane - for example, for ItelliJ or Eclipse - to inform the testing automation engineer that this test is ready to automate.

In other words, it would allow us to keep each of the roles flexible. So the product owner could work in JIRA, the testers in ALM Octane, and the testing automation engineers in their IDE. But we wouldn't leave the consultation aspect behind.

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.

For our use case, it's brought our entire team into a single tool. We're all looking at the same real-time data. Our project management office has been able to set up dashboards for individual teams, and do comparisons by teams, of integration, and cross-team integration, burn-up, burn-down, and cumulative flow types of things. So from a PMO perspective, there is a really good overview, from how we've set up our dashboards, to know where each team is and how they're progressing and how much work they have that integrates with other teams. That's really helpful.

The feedback that we've gotten is that the way testing is closely tied into the product Backlog has made it more intuitive, or easier to manage the relationship between building out an application and testing it. In other tools, that is more segregated. The way it's designed in Octane, people have said it makes more sense to them, and that it's easier for them to understand their data and to maintain and test their solutions.

Octane provides the platform needed for teams to run Agile projects. Previous tools like ALM QC were modeled for Waterfall methodologies. Metrics are not relevant for us in this case as we are still moving from Waterfall to Agile and hybrid delivery.

Our Waterfall practices have been standardized and templated to provide cross-project metrics and reusable assets, such as tests and other libraries. Our Mobile and Solution Delivery teams are finding Octane provides the CI/CD and DevOps connections with development and infrastructure teams, connections that they had previously managed with brute force tools like SharePoint, Excel, and email.

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.

My team has benefited a lot from this solution. Sometimes it can be a massive, gigantic project where it's a migration from one system to another. Because we already have the requirements and the test kit setup on the system, it is easy for us to run regression.

The solution natively supports Agile-Waterfall hybrid software development at an enterprise scale. This is very important to us. Because even though the company wishes to go Agile, we still have projects which follow a Waterfall methodology. In order for us to accommodate both, we needed some sort of hybrid system. Because if we are using a fully Agile system, then the reporting might not be correctly extracted.

At the end of the day, teams are able to collaborate because we are working on one thing. One person can do their part of the job, then another person picks from there and carries on. So, it runs as a smooth process.

Even though there are other people who are not using the system, if we would give them access to the project management, then they would be able to trace where we are at any point in time.

We started from scratch because we didn't have any BDD approach. We used a more old-fashioned method of development, more Waterfall and so on. We were looking for a solution which would be a good tool for our new methodology. For us, this was a key benefit from Octane, to get rid of the old style. We are implementing Agile methodologies in DevOps, that's the main thing. We try to use shift left to test much earlier and therefore it's really helpful to have Octane and to implement the new approach with it.

Two things. One is Agile. The other is the CI integration. We've always struggled bringing the development teams directly into ALM. ALI is a bridge, but it's cumbersome. The CI integration of the pipelines is what we're looking for right now. To bring us into the DevOps potential. That's the biggest draw right now.

Octane fits that niche that we never had. We need an Agile solution. We had other teams using other products that are semi-Agile, but we didn't have an approved standard. Octane gives us that. It's awesome.

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.

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.

For one, it's the whole Agile framework itself. You're cutting the time, the wait stage, and all that. We wanted a tool. You could do Agile methodology on a whiteboard, by using Post-Its. But practically that is not going to work out because the teams are in different locations. For example, our development team is in India.

So we have to have an enterprise level tool which can support everybody. So now we can create the same "whiteboard" and the "Post-Its" in Octane, and everybody can see it around the world. That means the people who support our service, the development teams in India. And the functional team sitting here in the U.S. It's the "collaborator thing." That happens using the enterprise tool.

We had projects in which we had the Agile part in a specific tool and the testing parts in another tool and it was very difficult to synchronize all that together for a reasonable price. Of course, you can buy tools to synchronize the different tools together, but to buy synchronization tools is very expensive. You have to handle that and if something is badly synchronized, you have to redo it by hand. So to have all that included in just one tool really makes our life easier.

Another benefit is the integration with Continuous Integration tools. Before, we had to upload all the test results either manually or automatically, but we had to write the scripts for that. With Octane that's just native, included in the package.

Finally, it consumes fewer resources than the previous tools in Quality Center. We have the same number of users but with half the servers. It's really economical from that perspective.

The integration points are very good. Octane gives us a window not only into our manual testing, but also our automation testing and our performance testing. We can see all results from all three streams of testing in one place. We've never done that before, until this past year. Whether that was possible with Quality Center or ALM.NET, I really don't know, but it's the first time we've ever done this. So the fact that it gives us that window into all phases of testing is where it's a bonus for us.

It helps us go to the true DevOps model, which means we can do shorter cycle times. Go from releasing every month, to every day. It's got a nice clean interface that people don't mind using. It integrates into the developers IDEs, like IntelliJ, which means that everybody gets to work in the tool they want to work in. Then it easily integrates across, so everybody can see the information in any place they want to see it.

We implement most of our test automation projects based on Octane. Very compatible to what customers need and I can deploy very fast. The projects start working from day one even with default configurations. 

We can deliver to customers a holistic view over all projects... an integrated view. In a company most projects are interdependent, the status view delivered live on all of them is very important. This is a big asset for us.

Octane creates a gentle approach to Agile-based projects.

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.