We just raised a $30M Series A: Read our story

Micro Focus ALM Octane OverviewUNIXBusinessApplication

Micro Focus ALM Octane is the #3 ranked solution in our list of top Enterprise Agile Planning Tools. It is most often compared to Jira: Micro Focus ALM Octane vs Jira

What is Micro Focus ALM Octane?

Micro Focus ALM Octane helps organizations implement a “quality everywhere” approach and improve Agile and DevOps development and testing processes to improve the flow of work across the software delivery value stream. You can tightly align quality efforts from development to release, employ a broad range of tests anchored by automation, and continuously monitor and improve for increased throughput. Micro Focus fosters an open approach so that quality is visible, traceable, and continuously improved. By synchronizing quality and testing with Agile and DevOps processes, risks are mitigated early in the software delivery value stream – speeding the way for faster delivery and improved customer satisfaction.

ALM Octane facilitates a tailored and scalable approach for large enterprises. You can deploy your way and minimize infrastructure needs with deployment options spanning on-premises, SaaS, and public cloud (Amazon Web Services and Microsoft Azure Marketplaces). Similarly, various licensing options can tailor the features to meet specific needs with support for thousands of concurrent users in geographically disperse locations.

Micro Focus ALM Octane is also known as Micro Focus Octane.

Micro Focus ALM Octane Buyer's Guide

Download the Micro Focus ALM Octane Buyer's Guide including reviews and more. Updated: October 2021

Micro Focus ALM Octane Customers

Orange, Airbus, Haufe Group, Kellogg's, Claro, Bon Secours, World Wide Technology

Micro Focus ALM Octane Video

Archived Micro Focus ALM Octane Reviews (more than two years old)

Filter by:
Filter Reviews
Industry
Loading...
Filter Unavailable
Company Size
Loading...
Filter Unavailable
Job Level
Loading...
Filter Unavailable
Rating
Loading...
Filter Unavailable
Considered
Loading...
Filter Unavailable
Order by:
Loading...
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Search:
Showingreviews based on the current filters. Reset all filters
JS
Principal Consultant at SACS Inc
Real User
Assists with adopting CI/CD in an Agile environment

What is our primary use case?

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

How has it helped my organization?

Octane creates a gentle approach to Agile-based projects.

What is most valuable?

The most valuable feature is CI/CD integration, and it is a good fit into the Agile lifecycle.

What needs improvement?

Improvements could be made by way of additional integrations across the lifecycle.

For how long have I used the solution?

Three years.

What is our primary use case?

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

How has it helped my organization?

Octane creates a gentle approach to Agile-based projects.

What is most valuable?

The most valuable feature is CI/CD integration, and it is a good fit into the Agile lifecycle.

What needs improvement?

Improvements could be made by way of additional integrations across the lifecycle.

For how long have I used the solution?

Three years.
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Steven Tompsett
CDA Engineer at Hastings
Real User
You are never more than three clicks away from where you need to be

Pros and Cons

  • "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."
  • "We've only had a few stability issues. Generally, we have issues following any deployment they do, so if they do a deployment on a Sunday, then we may have a couple of issues on a Monday or Tuesday."

What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

  • Octane is built on the SAFe framework, which is the agile methodology that we are currently following.
  • The capability that it has for so many out-of-the-box integrations is a fantastic feature. 
  • The very clean, easy to use UI that it promotes.

What needs improvement?

The reporting side of ALM Octane could do with a few areas of improvement. There is not enough flexibility in the way that we can cut up the data to report on certain things. For instance, with test information, we can't split that up by team, so it's quite difficult to see what coverage each team is currently working on. Some tech managers and scrum managers want to see the testing which going on within their team, but it is difficult to see. We only get a more holistic overviews of that.

I come from a testing background, and think the testing could be improved. 

For how long have I used the solution?

Less than one year.

What do I think about the stability of the solution?

It is a very stable platform. We occasionally see areas that come up with a more client side, so they're not blanket across everyone. Sometimes people use the wrong browser. The product clearly states that it doesn't support IE, but then who would support IE, as it is end of life. 

We've only had a few stability issues. Generally, we have issues following any deployment they do, so if they do a deployment on a Sunday, then we may have a couple of issues on a Monday or Tuesday. However, their support and willingness to react and resolve issues for us has been second to none. They've been low impact to the point where it has not damaged anyone's perception at all.

What do I think about the scalability of the solution?

We have 220 users on it. I have spoken to clients who have 3000 users on it. It's relatively scalable. We haven't seen any performance issues at all as we have ramped up the amount of data that we have on it or the amount of users. Our users include scrum masters, developers, testers, product turners, subject-matter experts, and business intelligence analysts.

In terms of usage going forward, we will rollout to our operations department. We'll get Ops using the same platform, so that should be another 60 to 70 users. The benefits of this would be that we would have more work concentrated all in the same place. Therefore, we can have a lot of crossover between other departments which aren't currently on ALM Octane that we can get onto Octane. This would make it work better and make it easier to manage because it would be a single place for work to be referred between teams, as opposed to having to go to a different tool if someone needs something hardware or software related to be created. 

How are customer service and technical support?

For a company of Micro Focus' size and delivering this large of a tool, their engagement with me has been unbelievable. It has been to a point where I have never experience engagement like this from a software house. I speak to developers and architects. I speak to people who actually care about the issues that they are speaking about. I don't just get someone in a call center who is logging a ticket, and says, "Someone is looking into this." Then, the ticket disappears into the abyss for three months. It's really nice to see and have intimate feedback on your suggestions or queries. That relationship has been almost as valuable as the tool.

The technical support, help desk, or service desk where you log a ticket on their service platform has the ability to turn around an issue quickly and is very reactive. 

I logged an issue on Monday afternoon, and within 12 hours, it was fixed. They did a deployment on Sunday, where they made changes to the history area of every ticket. Then, on the Monday, that history had vanished. We noticed the history had disappeared. The history for every single change that we had in ALM Octane was gone. I logged a ticket with them late in the afternoon on a Monday, then by 9:00 in the morning the next day, our history had been restored. Whenever they do a deployment, if we have issues, it takes them no longer than three or four days to resolve that issue and deploy a fix for us.

One of the biggest strengths of the community that developed Octane is they are so willing to listen to their customers and learn, then improve the tool that they have delivered. They try and make it fit for the customers who are using it.

Which solution did I use previously and why did I switch?

We were using Enterprise Tester and Rally (CA Agile) for change management. We switched from Rally to ALM Octane because of the lack of integrations and lack of drive to see Rally improve (from the company) because Rally is now owned by CA Technologies, and technically called CA Agile. CA has multiple other products that do the same thing as Rally. They have sort of acquired Rally, and it almost gives the impression that they will end of life Rally at some point, then take the user base and put them onto the tools that CA have. 

Also, Rally's age is a factor. Rally was one of the first scrum-based agile tools. It did a lot of things very well in its early life. It's been overtaken by newer agile tools now. The last reason was because Rally was not our choice. It was a tool that was pushed onto us by a third-party integrator when we brought them onboard to help us deliver a large program, so we just ended up with it. When you don't bring in a tool yourself and don't integrate it yourself, it ends up being a little bit of a mess on the administration side. There was a lot of stuff in it that had no home, no direction, nor desire to ever be completed, and had not been managed correctly. Thus, the administration to cover the tool was enormous.

We switched because outgrew the Rally tool with our process. It had gone beyond the capabilities of Rally.

People are generally happy with the position that they are in now in comparison to the position that we were in when we were on Rally. The administration is certainly a lot better now that we're on ALM Octane purely because people have a desire to not want to end up in the same situation, thus people are more conscientious of what they're doing.

How was the initial setup?

The initial set up was very simple. The tool from getting our license to starting to use it, there is not a lot to do. We have evolved with the tool, as the tool has gone on, but we started using it straightaway. There was nothing that we needed to do to make that tool work. We have taken a very step based approach. We started using it, then we developed some changes in the way the workflow flowed. We have added additional fields here and there, where we decided we needed to do so. Then, we added additional bits of functionality through other bits of integrations as we've been seeing the need or when we know we've embedded it in processes with other things. We've rolled things out slowly. It seems slowly to us, but it's actually not taken that long.

There is not a deployment. It's literally they give you access. They go, "Your licenses are ready," and you login. That's it, then you start using the tool.

The planning phase for me was a year long project, getting everyone on the system and all the data migrated. Initially, it was about creating a need, because no one knew they needed a new tool until someone looked into it. I identified the need and problem, did the analysis, made the recommendations, presented the options, made the recommendations, and collected the requirements. There were a lot of requirements. Then, I went out and engaged with our InfoSec Department and our procurement process. I officially got sponsorship from the directors in about March for the project who saw it and put some money aside to be able to do it. It was a fairly smooth process from start to finish, but it was hard for me because initially there was no need for it. I created the need for it, then from that point on, it was a very smooth process.

I was the single person driving that process, but then it was a member of staff from procurement. I touched base with multiple areas of the business that would have been using it to gather requirements, so nine scrum masters for half an hour each. Architects were all advisory. Contract specialists/managers to do the contracts. We had our legal team. I was the single resource that drove the process, created the documentation, and found the supplies.

I am the person now maintaining the system. It shouldn't take more than me, but it probably won't be me forever. The only reason it requires maintenance at the moment is because of misuse, so it's not like things go wrong with it all the time. It's more of a case of that it's self-sufficient and I can go through and review the work that people do, ensuring they are using the tool and populating it as we would like them to, thus we can get quality data out of it. 

What about the implementation team?

We purchased it via a supplier. Octane is being supplied by EOH Europe for us. I have worked with them in the past. They were happy to put us in touch with Micro Focus. We already have a couple of other tools through EOH, so we already had an existing relationship with them.

Working with EOH Europe was fantastic. My contact at EOH was very helpful. He has always been there to help with the multiple questions that I ask all the time about various different things, not necessarily related to Octane, but about anything that they supply us.

My biggest challenge as the integrator has been about changing culture. The tool does what it does. That is all. It has received a very positive reception by the majority of the people that use it. 

Changing the culture means improving the way that we do things, our processes, and the way that we do this is by having communities. We have a community to address concerns, misunderstandings, and conversation points that people bring, then we try and improve the practices that we do by trying to get everyone aligned to the same practices.

What was our ROI?

It's a bit early on to see improvements in times and deliveries. Our entire company has only been using the product since December of last year, so we don't have enough trend data.

We will see ROI once we have the automation suite connected up to Octane. We will then have the ability to report on automated testing versus manual testing and the ability to see those tests automatically parsing with the tool. When Octane shows us when our CI process fails and shows us what the story that failed, we will have return on investment. Because we will have not the overhead of having to do an investigation of having to find out what the change was, because Octane will tell us all of that information. 

What's my experience with pricing, setup cost, and licensing?

For what it does, it's very reasonably priced. I like the licensing model as well, because it's very flexible. You can scale licenses up and down for short periods of time. 

In terms of pricing, it's comparable to what we had previously. It's not priced at the higher end of the scale by any means. It's priced nicely, in the middle of the market. For what you're getting, it's a very good tool.

Which other solutions did I evaluate?

It went through official procurement process where we went out to tender with seven different suppliers. We had responses from five of those suppliers. We had demos from five of those suppliers. We followed three more through, then we eventually selected Micro Focus ALM Octane. At which point, we started demoing Octane and ran it through 2018 whilst we were doing contract negotiations and signing contracts, which was probably the single hardest part of the entire thing. 

Four of the seven vendors that we looked at were Micro Focus, CA Agile (incumbent), VersionOne, and Jama. 

We went with ALM Octane because of its functionality and it is presented very cleanly and simply. You are never more than three clicks away from where you need to be in Octane. Another reason that we went for ALM Octane as a tool is because of our relationship with Micro Focus as a company.

ALM Octane has a cleaner version than VersionOne, which is a little busier.

What other advice do I have?

If you're looking for a tool which will complement a CI or DevOps process, where you want to have a single point of visibility or a single version of the truth, and see all of the stuff that happens through that journey, Octane is the tool which will to give you that.

The biggest lessons learned: When you start focusing on a new tool that prides itself on having a very tight process to make things visible, you learn how other people don't necessarily follow its processes as tightly as you would expect them to.

Using the SAFe framework helps our workflow patterns. We have been using SAFe for about four to five years, and we've actually been using it properly for maybe two and a half to three years. We're still not perfect by any means, but we are definitely pushing forward in the right direction to become more focused on delivering the true version of that methodology. Although ALM Octane doesn't do every element of that methodology yet, they are endeavoring to clean up a lot of those areas. They are trying to mop of some of the methodology that SAFe works on adding in things. We have seen quite a lot of new features recently that have been specifically focused towards SAFe, which has been really positive for us.

ALM Octane has improved our use of agile, but we still do some waterfall stuff. We will always carry on doing some Waterfall stuff until certain systems fall out of use because we have old systems and those old systems don't lend themselves to agile.

ALM Octane has presented us the opportunity to push forward with a true CI/CD approach, which is where we want to get to. 

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Learn what your peers think about Micro Focus ALM Octane. Get advice and tips from experienced pros sharing their opinions. Updated: October 2021.
542,721 professionals have used our research since 2012.
AG
Programme Test Manager at a energy/utilities company with 1,001-5,000 employees
Real User
Gives us a window into our manual, automation, and performance testing; we can see results from all three streams in one place

Pros and Cons

  • "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."

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What is most valuable?

    The whole thing is geared towards Agile deliveries. It certainly has a good GUI, it's good to look at. The features provide good impact. It lends itself very well to Agile deliveries.

    For how long have I used the solution?

    One to three years.

    What do I think about the stability of the solution?

    So far the stability has been okay. The stability is: Is the server up and running? In the last year we lost access, maybe once, for a couple of hours. Because it's a SaaS product, we don't know why it came down. We just know that it became unavailable to us. But on the whole, it's been pretty stable. We're not intense users just yet. We will be. In six months' time, we won't be able to afford any downtime really. But we're not an intense user right at this moment.

    We may have not noticed when it wasn't available. But in six months' time, that story will change. Obviously, as part of our DevOps pipeline, we will really expect it to be up 99.9999 percent of the time.

    In that one occurrence, they reacted quite quickly. We raised a ticket and then had an instant response. They said, "We're looking at it." I can't remember what the actual resolution was. I find Micro Focus quite reactive to issues.

    What do I think about the scalability of the solution?

    I think it would scale. We've not needed to scale too much yet, but it seems scalable to me.

    I think that the biggest obstacle to scaling with this particular tool is the licensing. You predict what licensing you need for the year, a whole year, and you're stuck with that for that year, unless you pay more to scale up. That's always a challenge. The challenge is not the scalability of the solution but the scalability of licenses.

    We've just upped our licenses to 25. We started off with ten. Once we get to steady state, in some six months' time, we'll have about 30 steady-state silences.

    Regarding the increase in usage, we'll push more work through it. Right at this moment it's just one program of work. Once we're happy with the way we use it, the stability, we'll then push all our organization's work through Octane, rather than ALM.NET. At the moment, the majority of our work is going through ALM.NET. It's just this transformation program that I mentioned where we're using Octane. It's almost a proof of concept for us. If it works with that program, we'll make it work for all programs.

    How are customer service and technical support?

    Tech support is okay. So far our experience with them has been positive. They're certainly quite quick to react to the initial issue. Because they've got this "follow-the-clock, follow-the-sun" support model, there have been times when we have raised a ticket and has gone over to a resolving group in South America, and there has seemed to be a time lag in getting our updates. That can be a problem but, because we're not an intensive user yet, I'm not sure if that would manifest itself a major problem.

    The initial response seems to be good, but sometimes the follow-up is not quite as quick as you'd like it to be.

    When we've asked for details, we've received details. They don't seem to hold too much back. When we've pushed them for detail, we've gotten it.

    Which solution did I use previously and why did I switch?

    We were working with Micro Focus on our cloud transformation program. We included them and a lot of vendors, but we had identified the Micro Focus set of tools as the tools we should be using for our DevOps pipeline. That was made through a process of evaluation of other tools. At that point, we engaged Micro Focus and said, "Look, this is what we want to do. How can you help us?" At that time, Octane was just coming off the production line and they said, "Well, we've got this new product which might work better for you." They made that product available to us. So we looked at it at that the suggestion of Micro Focus, given that this new product was coming out.

    We'd always had what used to be HPE before it was Micro Focus, so we'd always used the variations of HPE testing tools, ALM.NET and, prior to that, Quality Center. We did some research with industry reviews and, obviously, the Micro Focus set of tools were in the top quadrant. Because we had the relationship anyway with Micro Focus we decided to stick with that toolset.

    It was a natural progression, plus the fact that the review sites had the set of tools in the top quarter for being the most integrated set of test tools. We were looking beyond test management tools. We were looking at automation and performance, and the recommendation from those sites was that Micro Focus had the richest set of integrated test tooling. That led our thinking quite a lot.

    How was the initial setup?

    I thought the initial setup was pretty straightforward for us. We started off with ALM.NET on-premise. We then took the SaaS offering. So our initial challenge was to migrate our existing ALM.NET projects into the SaaS product. We then were made aware of Octane, which was made available to us quite easily, and we were able to start using it.

    What we didn't do, because of various challenges with our program, was we didn't really get too involved early because we weren't ready. So although the tool was ready, we weren't ready to consume it. But in the last few months, we've made quite a few strides with that. We're now at the stage where we need to say, "What more can give this give us?" There's a lot we can do. What is it we want to do? That's probably where we are now.

    Our implementations strategy for Octane was quite simple. Because we've got this program of work, which is a cloud transformation program, we used that program as a proof of concept with Octane. That program worked, which is lifting and shifting 70 business applications. They are being migrated from on-premise to cloud, and each one of those migrations, on an application-by-application basis, is being managed by Octane. So our implementation strategy was to use it for this program of work. Once we realized the good and the bad, we could then start implementing it across the rest of the organization.

    The staff from our side required for deployment was none. For us, it was just a request to Micro Focus and then agreeing to pay for licensing. It's a URL, basically.

    For administration within our organization, the overhead is that there are several admin tasks, such as creating new backlogs, creating users, and administering users. It's no more of an overhead than with any other test management tool. The admin side is still the same. You have to set up your folder structures, you have to set up the users, you have to disable users when they leave the organization. It's simplistic and it's quite easy.

    Here, because we're quite a small organization, we've got three people with admin rights, and between them they handle requests as they come through. We've got a site admin and a project admin. It's a layered type of admin, as much as it was in the previous products. The site admin can do everything and project admin can do everything within that project.

    The product was there for us. As soon as we requested it, it was made available, so there was no implementation, as such, for the product. It was down to us to make use of it, and start creating our backlogs, and our structures, etc.

    What about the implementation team?

    We relied on the help we get from Micro Focus. There are some good online video tutorials from Micro Focus. We made use of those. We made use of Help topics on the product. Other than that, for any issues, we would raise a ticket with Micro Focus. We didn't actually take on formal consultancy.

    What was our ROI?

    I don't think we've reached the point of ROI yet. For return on investment, we're looking at about 12 to 18 months before we start seeing that return. Our return will come when we automate more testing, when we show those results in Octane, and start making more use of the Octane dashboard. That's when we'll see a return on investment.

    What's my experience with pricing, setup cost, and licensing?

    It's expensive. HPE products, and now Micro Focus, have always been expensive. The license is not cheap, and it will always be a challenge, particularly for small organizations like ours.

    What other advice do I have?

    It's a good product. You need to consider the cost of it. We didn't do too much comparison against other tools, but I always felt that this product didn't only give you a project view, it gave you a program view as well, which some of the other tools don't. With this tool, you've got a program. You can see multiple programs. If you set up your dashboards correctly, you can get a much wider organizational view. That's where we need to play a bit more with it, to get more out of that capability.

    I would advise others to consider the expense, maybe look at other tools, to see if they can do what they want to do cheaper. For us, we felt it was worth the investment.

    I don't think we're quite mature enough yet to be able to say that it has improved our workflow. Where we are now, we've proved the integration points, we know how we can use the tool, we know how it can benefit us. But what we haven't done is actually reaped the benefits of that just yet. But in six months' time, we'll see improvements to our workflows and we'll be making more use of the tool for that aspect. We're quite immature in our journey at the moment. Although we've had the tool for a year, we haven't started to use it in anger until the last few months, where we've input all those integration points. Now we've got a set of integrations where we can do exactly what we want to do and now we need to decide how best to use that to improve our workflow, etc.

    We're introducing an automated pipeline. Our end-to-end DevOps pipeline starts with ServiceNow, where we will request an environment. That request will be picked up by Jenkins, go off to the Amazon cloud, and stand up that environment. Jenkins will then orchestrate a set of automated tests, using UFT, to make sure that environment is working, and it will pass results back to Octane. At that point, a notification goes back into ServiceNow to tell the requester that, "Your environment is available, and it's been delivered." That's the kind of pipeline we're delivering for each application that we might write. In theory, we'll automate as much of that pipeline as possible. We are on that DevOps journey. It's still a work in progress for us.

    Regarding the biggest lessons learned so far from adapting tools and processes for Agile and DevOps, I think it's the culture, spreading the culture within your organization. Some people don't like change, they don't like new ways of working. So the cultural issue, the people issue, is a challenge. 

    When it comes down to tools and technology, it's the integration points; doing some proofs of concepts to prove each integration point works and finding out where your limitations are. We found some limitations in what we want to do on the Amazon cloud, which we weren't prepared for. The lessons learned for me are: We should've done many, many proofs of concept, small proofs of concept, to prove each point of integration, and then bring all those small proofs of concept together. If I was to do this again, that's exactly what I would do: small proofs of concepts before trying to build anything in an end-to-end fashion.

    In terms of how Application Lifestyle Management Tools can help with the transition from Waterfall to Agile, Octane was created very much with that Agile focus. It gives you that set of tools to create the environment, to create your backlog, to create your sprint, and to give cadence to that and give a reporting view of where you are at. Also, it's not just at the project level, you can do it at the program level. We need to start looking at things from a program level, and how we can expand out. It's the views it's giving you, and the tooling that it's giving you that fully support that Agile-type delivery. We've made it work for a Waterfall-type delivery as well. It's giving you everything you need, for whatever delivery you want: the project view and the program view.


    Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    Jennifer Plourde
    Enabling Manager at a financial services firm with 10,001+ employees
    Real User
    Our entire team now has a single tool to look at the same real-time data, but we need more detailed and smart reporting

    Pros and Cons

    • "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..."
    • "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."
    • "People really how easy it is to customize. In some previous tools, that has been very limited, or you had to know how to write code to do some of the customizations, or it was very confusing. Going back to the user interface, they've made the customization of the tool, the workspace settings, very easy for people to figure out and use."
    • "There's a trend in our requests to have the ability to export data, en masse, out of Octane. There are capabilities within Octane to export data, but there are specifics around test suites and requirements and relations, as well as certain attributes, that we would like to be able to export easily out of Octane and into a database or Excel."
    • "We have some requests to beef up the manual testing abilities and the ability to report on testing progress. All the basics are there, but there's an issue of maintainability. For example... once you plan a test and it creates a run, more particularly a suite run, you can't edit the suite run afterward... That that is not realistic with how people work. Mistakes are made and people are humans and we change our minds about things. So the tool needs to allow for a bit more flexibility in that testing area, as well as some better widgets to report on progress."

    What is our primary use case?

    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.

    How has it helped my organization?

    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.

    What is most valuable?

    Very generally, the feedback that we've received is that people really like the user interface overall. It's intuitive to use, it's easy to learn, people like the usability features, the user experience. 

    Another thing that people really like about Octane is how easy it is to customize. In some previous tools, that has been very limited, or you had to know how to write code to do some of the customizations, or it was very confusing. Going back to the user interface, they've made the customization of the tool, the workspace settings, very easy for people to figure out and use. We've gotten a lot of good feedback on that.

    In general, I think people really like the Team Backlog and the capacity bucket for each individual team member. They like that ability to track capacity and progress very easily that way, by individuals.

    What needs improvement?

    I work pretty closely with Micro Focus, particularly on ALM Octane. Right now we have a backlog of some 60 or 70 enhancement requests, varying in priority from very high to low.

    In general, there's a trend in our requests to have the ability to export data, en masse, out of Octane. There are capabilities within Octane to export data, but there are specifics around test suites and requirements and relations, as well as certain attributes, that we would like to be able to export easily out of Octane and into a database or Excel.

    One of the things that a lot of our project teams have complained about is the simplicity of reporting that's available in Octane, and that they have to export data out of it in order to create the types of reports that their PMO or their client wants to see. Octane provides solutions around OData, and integration into reporting tools, but what people really want is smart and good reporting, advanced reporting, within the tool. They don't want to have to go out to another tool for reporting.

    In general, we also have some requests to beef up the manual testing abilities and the ability to report on testing progress. All the basics are there, but there's an issue of maintainability. For example, one thing that we brought up to them recently was: Once you plan a test and it creates a run, more particularly a suite run, you can't edit the suite run afterward. It locks you in, and we're saying that that is not realistic with how people work. Mistakes are made and people are humans and we change our minds about things. So the tool needs to allow for a bit more flexibility in that testing area, as well as some better widgets to report on progress.

    For how long have I used the solution?

    One to three years.

    What do I think about the stability of the solution?

    Overall, we haven't had any issues with stability. There are two things that do come up.

    It seems like we have issues with Elastic, the integration to it. Intermittently we have these issues where global search isn't working, or widgets aren't populating, so there's something a little bit unstable with that integration. It could be on our end, or it could be something with the setup, I'm not sure.

    We're also having performance issues. It's not really stability, but we do see some slowness in the system and in our performance testing, so we're working with Micro Focus on that to figure out how to resolve those issues.

    What do I think about the scalability of the solution?

    The performance issues that we have come about when we have load on the system. We're trying to figure out if the source of those issues is the environment, and what the optimized settings would be for the environment: memory size, number of disks, things that we're doing in our performance testing, etc. But we're also looking at the software to see if there are any issues there.

    We are working with about 180 to 200 concurrent users, which isn't a terribly high number. We're looking at all sorts of angles but we're currently in the middle of it, so it's hard to tell what the source of the issue is.

    Micro Focus has definitely been good about helping us out with all of that, giving us advice, hardware related, on what our settings should be. Maybe we're not sized exactly correctly. According to Micro Focus - they also, of course, do their own performance testing - and they haven't seen the results that we have.

    How are customer service and technical support?

    Because we're a partner and we've been working with them for years,  we'll have quick calls twice a month, at least for Octane, to talk about new enhancement requests that are coming up, providing them with feedback on the tool as we're hearing it from our project users, and to review our highest priority requests and their statuses and if they have been included in their release planning for upcoming releases.

    We have a pretty good dialogue going back and forth with them, so we know when to anticipate the functionality that we're looking for is going to get delivered. That helps us when we're making decisions around which upgrades to take.

    Tech support does a pretty good job. Sometimes it's a little frustrating because they're the Level 1 support, the helpdesk support. They often are trying to rush us to close out tickets. I understand that they've got metrics, but that part is a little bit frustrating.

    When we get it escalated, when we're working with their research and development or with the customer service contacts that we have, they're much more amenable to our requests. They like listening to what we need and the type of support that we're requesting. They take us pretty seriously when we escalate and have high priority issues, and they really try to get us resolutions as fast as they can. We definitely appreciate that.

    Which solution did I use previously and why did I switch?

    We have ALM implemented and we're still using AGM. We are making the switch to Octane because we implemented AGM with integration to ALM so that we could have Agile project management and a manual testing tool for our project teams. The nice thing about Octane is that it doesn't require integration. Integration always introduces a potential for points of failure. If you can house those capabilities within a single tool, why not go in that direction? It provides ease of use, less maintenance, etc.

    Also, this is the direction the vendor is going in. Several years ago, our organization made the decision to go with HPE, now Micro Focus, for the majority of our suite of enterprise tools. We're following the direction that the vendor is going, but also recognizing that there are advantages to the tool that has good capabilities. We're not blindly following them, we're doing our assessments and saying, "Hey, this looks like a good thing for us." Of course, if it requires fewer tools, less maintenance, less setup, we'll go in that direction. That's how we made the decision to go with Octane.

    There are other things that we haven't deployed yet, but the advantages of the direction they're going in for integration into the DevOps world to support CI and CD, that's a direction we want to go in. I'm on the Agile solution team, but we have the testing solution team, so they're very interested in those types of capabilities as well. Octane is opening that door for us to get more and more functionality hubbed in a single tool.

    How was the initial setup?

    I don't do the software installation or that side of things, but in terms of our implementation strategy, we have four environments in which there are seven servers. In our lower environments, our base environment, we have one server that gets installed. 

    We don't have any integration that we support currently, so it's a standalone environment. We do integrate into an Elasticsearch farm, as well as to LDAP for user creation, password validation, etc. We have those basic types of integration setup, but we don't have integration to other tools such as DevOps tools, yet. We are currently working on integration to PPM, and that's going to be deployed in the next couple of weeks.

    Once we get up to our stage and production environments there are multiple servers on a load-balancer, so that adds an extra degree of complexity to the setup. They're also externally exposed to the internet so that our clients and external users can have access to the tools.

    What about the implementation team?

    It was just us and Micro Focus.

    Which other solutions did I evaluate?

    We did not evaluate other options before choosing Octane. At that point, we were in pretty deep with HPE. But before we chose HPE as our vendor for the bulk of our enterprise tools, we did an evaluation of different vendors, different suites of enterprise tools that we could possibly host, before we made that decision to go with ALM and AGM and UFT.

    What other advice do I have?

    The way that we approach it is that we don't rush into a decision and say, "This is the tool that we have to use." One thing that's nice is that there's always an option for a SaaS trial for 30 days or 60 days. Micro Focus has been very kind to us and given us extensions on our trial versions so that we would have enough time to evaluate the tool and the SaaS version before we make a full, educated decision about how we want to move forward. That's a good place to start: Plan on getting a trial version and plan out your assessment, what your objectives are, what your requirements are for the tool, and then just get in there and start using it.

    I use Octane in my day-to-day work, but I'm mostly an administrator of the tool's usage on our consulting projects.

    With respect to how tools and processes are evolving to adapt to the change from traditional Waterfall, one of the things our organization is finding is that it's not a switch that you turn on - that you're "traditional" one day and you're "Agile" the next. So, having tools that are flexible enough to accept variability, and that are flexible enough to adjust to project teams transitioning and becoming more Agile as they go along, is important. Octane, because of some of the additional features that are there and that are not in some of the other Agile tools we've looked at - like the Quality module, the quality story, the ability to customize workflow and business rules, and also having the Requirements module - lets you still be a little bit traditional when you need to be, while you're learning to become more Agile. There's some transitioning that the flexibility in Octane lets you do, where other tools might be more rigid in enforcing pure Agile project management.

    As for lessons we've learned about adapting tools and processes for Agile, I feel that's very similar to what I just said. It's this journey that people are on. Where we started was with very traditional project management tools and, as Agile became more the trend, we recognized the need to add more tools into our landscape that would support it better.

    The way that we work is that, while we host all of these enterprise tools, we don't enforce that these are the tools that are to be used on projects. We have to be a bit more flexible than that. Recognizing the need to have enterprise tools available for project teams that couldn't find their own tools, or clients that didn't have their own tools, that's where we brought in AGM and then, eventually, Octane when it came onto the market.

    The other thing that's helpful to recognize with this transition, is that you can't become Agile on day one, once you make the decision that's the direction you want to go. It's very good that we have the ability to integrate our more traditional project management tool with our Agile tool. Currently what we support for project teams that are doing a bit of both, what we used to call "hybrid," is their integrating of their Agile project management tool, like AGM or Octane into a traditional workplan tool like PPM so that they can see the full breadth of their project progress across both more traditional tasks and Agile tasks in a single place. We're bridging that gap by using multiple tools and integration.

    In general, ALM tools help in the transition from Waterfall to Agile because you have a tool enforces some processes, and provides a little bit more rigor than you would have otherwise. Having those ALM tools available has helped us enforce some consistency and adherence to Agile processes.

    To date, we've had 136 projects, that's 136 workspaces, and about 1,000 users.

    In terms of increasing usage of Octane, we deployed AGM and ALM four or five years ago. The problem in our organization - and this is another thing we've talked to Micro Focus about, and they're hearing similar feedback from other places - is that people are used to what they know. If people have used AGM or ALM on a previous project, they're just going to go with that.

    We do have some early adopters. People have been keen, they've heard about this new tool Octane, checked it out, and those early-adopter types were on the bandwagon pretty soon. There are some people that are lagging behind and kind of skeptical. We're dealing with the psychology of that. Part of that is knowing there is not really a great reason for us to continue supporting two tools that do very similar things. AGM and Octane have a lot of overlapping capabilities. We're looking at our strategy for how long we want to continue to maintain and support two tools that do the same thing.

    We're trying to encourage people who are used to using AGM, or are leaning more that way, that they should come over onto the Octane side, because that is the direction that the vendor is going in. That's where the investment is going, and that's where all the new functionality is coming out. We're trying to increase adoption in a variety of ways to get those people onto the Octane side.

    We have an assessment planned early next year to strategize when we might scale down AGM, and maybe even cut off provisioning new projects, but we don't know the timeframe of that yet.

    In terms of maintenance of Octane, their roles are project manager-types, people who do the server administration, and DBAs. There's also a QA group and a PMT group that we enlist on a very short, annual basis to do our performance testing.

    I would rate Octane at seven out of ten. There's definitely some functionality that I think could make our lives a lot easier, especially around the extraction of data and the reporting. Those things would really help us out. I'm conservative on rating things.

    Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor. The reviewer's company has a business relationship with this vendor other than being a customer: Partner.
    TL
    Senior Software Engineer with 10,001+ employees
    Real User
    Gives us all the tools for Agile testing and test management, and predictive analysis could be a game-changer

    Pros and Cons

    • "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."
    • "When I manage projects that are being created in ALM, I have a standard template, but I don't have a template for them in Octane. I literally have to create the project from the ground up every time, which for an administrator, is a nightmare solution"

    What is our primary use case?

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

    How has it helped my organization?

    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.

    What is most valuable?

    The most valuable features include the predictive analytics, being able to trace everything, and having all the tools for testing and test management in an Agile environment.

    What needs improvement?

    The problem with Octane is that if I'm in ALM and I need to go into this Agile process, and I have been using Micro Focus ALM, when I go to Micro Focus Octane, all the things that are in ALM are not all working in Octane. For example, the template feature: When I manage projects that are being created in ALM, I have a standard template, but I don't have a template for them in Octane. I literally have to create the project from the ground up every time, which for an administrator, is a nightmare solution. It could take you upwards of two to three days to set up a project, and then you have to try and make sure it has all the same stuff as the previous projects. You literally have to have this massive checklist to make sure you create all the same fields, you put all the links, you put all the dropdowns to make sure all this stuff works for the projects.

    If I'm jumping from ALM to Agile, I'll go into Octane and create a new project template form, but I have to actually document creating that because I have to create every individual piece of that project - all the pages, all the fields, all the drop downs. I have to duplicate all the work, each time I have to add a new project in Octane.

    It's very complicated. When I set up new projects, it takes multiple days, and then it's fraught with mistakes, because it's a manual process for setting these things up. I have multiple people trying to do it and I'm going to have all kinds of errors Typically, for ALM, it takes any one of us minutes to create a new project. I can create a new project in about 15 minutes, at the most. And I can guarantee you the project that's created is identical to all the other projects that I have created, because it's a template. In Octane, I literally have to create every field value, every field, every form, every workflow, manually, each time, which always ends up with a problem.

    I've talked to them about it. They say it's on a list to be looked at. I would think that would need to be at the top of the list.

    Another issue is that one of the things I do is link all these things together. Octane has a Synchronizer tool. The only problem was, it didn't work with all the fields. They just upgraded it to work with multi-select fields. I haven't had a chance to test it yet.

    I worked with their engineers on this. I don't know how they could have not done this. There are not that many different field types that you would create. A text string or a single dropdown or a multi dropdown, or a numeric field. They had everything but the multi-select field. All the rest of them worked but multi-select didn't. In my projects, about one-third of my fields are multi-selects. When I tried to get the systems to work using Octane, I couldn't get them to work. I had to use another tool for the projects that needed multi-select. I put those projects in JIRA because JIRA worked.

    For how long have I used the solution?

    One to three years.

    What do I think about the stability of the solution?

    You've got it up and working. It's stable. Other than the problems that I talked about, it works. I haven't run into any other major issues.

    I did have one project switch out of Octane, back into JIRA, because of the way that it displays status. If you are in the Octane test area, and you have defects and test results and user stories, and you want to see a user story, if you have different workflows for defects and for test, what you see on your task board is all three tool items on one page. Say you had a work in progress with a vertical line of task records. You would see a work in progress for user stories, a work in progress for test, and, a work in progress for defects. So from the board, you see three work-in-progress verticals, and you say, "Oh, that's a problem. Which one is it? It doesn't say." The only way to get rid of those is to hide them. They're still there, but you have to hide them.

    I struggled with trying to get it fixed for the users. They kept making changes to workflows and every time they'd make a change, I'd have to go in there and try to figure out how to hide it. I think the design of those boards could be better.

    What do I think about the scalability of the solution?

    I'm in SaaS. If it slows down, I just call them. They increase something, whether its memory, CPU, or disk space. Scalability is pretty much a non-issue.

    How are customer service and technical support?

    The support is good. They have worked very well with us, in getting things addressed. I work pretty heavily with the development staff and they are quite open and easy to work with. They do try to get the solutions addressed as quickly as possible.

    We do have some big issues that we are struggling with, the template feature and the multi-select and the synchronizing. We were moving in a positive way to move people from the old tool to Octane until we ran into those issues. Now we're actually going backward. They got the multi-select fixed, but, unfortunately, I've got to erase some bad taste in peoples' mouths to get them to come back.

    Which solution did I use previously and why did I switch?

    The way we brought it in is that we have a Flex agreement with Micro Focus for a large list of products. Because we had ALM, Octane was included. If I have 200 licenses of ALM, I have the equal amount of Octane. If use one, I get the other.

    How was the initial setup?

    We have the SaaS. The system was all set up and working through the Micro Focus SaaS team. For me, it was just a matter of getting access to it. They said, "Here, put in your user ID and password," and that's how long it took.

    What was our ROI?

    The biggest ROI, compared to any other tool out there, looks like it will be the predictive analytics. I don't have it fully implemented, but from the demos I've seen, it is pretty amazing. Getting that fully set up and implemented is, in my opinion, a game-changer. It could make the tool top of the market. 

    What's my experience with pricing, setup cost, and licensing?

    It's pretty pricey, one of the most expensive ones on the market.

    The value depends on if you use all the features that it has. It comes with a lot of features. The difference between the license structure of ALM and Octane versus JIRA, is that you get everything with ALM and Octane. All the plug-ins that come with them pretty much come with the product. You may have some one-offs that you have to buy outside the product but it pretty much all comes with the product.

    For JIRA, you buy the pieces one piece at a time. If you only use three of the pieces, you only have to pay for three of the pieces.

    If I used all the features of the tool then the price of the tool would probably be fair. I've been doing this for 45 years and I don't think there's a tool on the market that anybody uses fully.

    The good thing with ALM and Octane is you get all the features and you don't have to add anything else. If you want to see what the others are, you have them to use.

    With JIRA, you need those three things and you buy those three things and, most of the time you don't go looking to see if you can use something else. Maybe two of those things could help you immensely with something else, but typically you don't go looking for them because they may cost more money and you may not have it.

    Everything in the tool is good, but then it's expensive. The mindset, now, is go Agile. And go Agile means go cheap, at least in the executives' minds. But, in reality it's not.

    You're fighting the "JIRA monster" because all the new developers in schools today use JIRA. When they come out on the marketplace they know JIRA and they like to use it. They don't know Octane because it's a new tool and it's still in its beginning, growing pains. You really have to have a perfect scenario that convinces them to leave what they know to go to what they don't know. I fought tooth and nail to get people to start using Octane here because we had a license, meaning it didn't cost anything more than we were already paying. I couldn't get anybody to come see it. I couldn't get anybody to use it. What I started doing was selling it to new people, people who hadn't been involved with JIRA before. They took it and they like it, except for the one team that left because they didn't like it.

    Which other solutions did I evaluate?

    When you compare ALM Octane vs JIRA, it's different than JIRA where you have the core product and then you have to buy all of the add-ons to do what you need to do. Octane tends to have everything you need.

    What other advice do I have?

    Octane is really good about synchronizing data. Synchronizer is a really good tool to get people who are into any other tool using it quickly. Regardless of where you're coming from, you use Synchronizer to synchronize the data, as opposed to trying start new or migrate. This is a quick way of getting data over and being able to manipulate it so that it's usable in the new tool. If you're going to ALM to Octane, as long as you can get all the fields to come over, it's quick. I took two projects and it worked within hours of getting it set up. When I ran into the problem of multi-select fields, that was pretty much a roadblock; but a simple project to a simple project, it worked fine.

    In terms of our tools and processes evolving to adapt to the change from traditional Waterfall development, it requires a retraining. When you're going from ALM to Octane, in an Agile process, everything is completely different. You have to train all the users on how to be Agile, you have to train all the developers on how to develop in Agile. You have to realign your whole organization by resource and resource assignments.

    Then, you have to develop your change control, your change management process, because that all changes. Also, your configuration management teams all have to change. It's a complete upheaval of literally the whole organization, to go from Waterfall to Agile. And, for tooling, everything you do, everything you knew before, has to change. Your tools, your process, your planning, your resource allocation, everything has to change. It's a very big process and it will take a long time, and we haven't achieved it yet.

    The biggest lessons we've learned, so far, during this transition is that it's bigger than we thought it was. However, I'm still the owner of the tool and, for me, a tool is a tool. You have a screwdriver, and maybe you come up with a nicer screwdriver, but it's still a screwdriver. You still have to screw a nut into an object. The same thing with the testing tools. I still have requirements, I still have tests, I still have test runs, I still have defects. It's just how you process those things within the overall organization, how you address your processes. From a Waterfall process to an Agile process, everything is smaller. As opposed to a six-month delivery and test, where you're addressing thousands of defects, and thousands of test cases, in an Agile process, you're dealing with tens of them instead.  It's much smaller everything because you're working in two-week sprints as opposed to six-month or 18- month cycles or releases. 

    In terms of the tools that you use, it's how they fit, how they get you to meet the objective quicker, and how much training has to happen. Some tools require more training than others because they're not logically thought-out processes for creating records. Octane's usability is more logical and step-processed, where you start with one record and it drops down to the whole thing as it explodes out into all of the different areas. Comparing it to JIRA where, if you don't know how to use JIRA, it's not very logical and you have to hunt and find things. In Octane, it gives you the big menu ribbon that has everything from left to right. So, you see how the process flows.

    Regarding ALM tools in general, they're struggling with it and it could be because they themselves are on the same road that everybody else is on. But, they're a little bit behind. Agile has been around for a while. JIRA is the ALM of tools: ALM was the tool for test management for Waterfall, where JIRA is the tool for the Agile process. 

    Octane is trying to play catch-up. The design of the tool is a little different. JIRA gives it to you in pieces, so you get the core product and you have to add on things to make it actually work, where Octane gives you everything.

    We're in the process of going to this process. Right now, the larger side is JIRA. We have four projects using Octane. We can only hope it can replace JIRA.

    We currently have fewer than 50 users in Octane. Their roles include BAs, testers, developers, and administrators. We don't require any staff for maintenance because it's all SaaS. The only resource utilization for us is setting up user access to Octane. Ninety percent of that is either the SaaS organization or the users themselves. Because we go through a portal, they have to set themselves up as a user on the portal, and then our support staff just grants them access to Octane and sets them up with a role. I'm the owner of the tool set and the support and maintenance.

    Overall, I rate Octane a strong eight out of ten. The tool works and it works well if you're only on the Octane side. It does what it needs to do. It doesn't claim to be the easiest configuration tool, but utilization of the tool and its support for what your project needs seem to work quite well. All the things that they're giving you are everything you would need in projects. It's when you get into the integration piece, when you get into the more complex pieces... that's why I give it only an eight.

    Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    it_user683523
    Senior Expert IT Test Service Management at a financial services firm with 1,001-5,000 employees
    Real User
    We are seeing better collaboration among the business, testers, and testing automation engineers

    Pros and Cons

      • "The Requirements Module could be better, to build up a better requirements process. There's a huge improvement from ALM.NET to Octane, but it's still not really facilitating all the needs of the product owners, to set up their requirements in Octane."
      • "Because JIRA is a leading tool for both development and requirements management - everybody is using JIRA - I'm pretty there will be a use case where people are trying to connect between ALM Octane and JIRA. The back-end configuration of the synchronization with JIRA could be simplified. The architecture is really complicated. We required a lot of machines to build the cluster and the configuration was not really clearly described within the documentation. This may have something to do with the fact that the software is pretty new."

      What is our primary use case?

      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.

      How has it helped my organization?

      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.

      What is most valuable?

      It's hard to say which features are the most valuable because all the features are really fantastic. What distinguishes the ALM Octane from ALM.NET is, first, the Pipeline module because with the Pipeline module you are able to integrate with the CI server.

      The second point is the support for the BDD Gherkin syntax. It's valuable because the point of BDD, I'm talking about the "culture," is to optimize the collaboration between the business - the product owners - the testing, and the development. We are pushing them to speak the same "language."

      What needs improvement?

      First, the Requirements Module could be better, to build up a better requirements process. There's a huge improvement from ALM.NET to Octane, but it's still not really facilitating all the needs of the product owners, to set up their requirements in Octane.

      Second, because JIRA is a leading tool for both development and requirements management - everybody is using JIRA - I'm pretty there will be a use case where people are trying to connect between ALM Octane and JIRA. The back-end configuration of the synchronization with JIRA could be simplified. The architecture is really complicated. We required a lot of machines to build the cluster and the configuration was not really clearly described within the documentation. This may have something to do with the fact that the software is pretty new.

      I addressed this with the vendor, but a solution was not really provided. However, I saw just today that they are creating a collaboration platform for people who are evaluating ALM Octane. That's a good start to facilitate this but, as I said, because the software is pretty new - it's only two or three years old - I expect that some things are not really completely optimized. I'm pretty sure it's going to be better in the future.

      For how long have I used the solution?

      Trial/evaluations only.

      What do I think about the stability of the solution?

      In terms of performance, I haven't had any complaints. It's really performing well. But I'm not really qualified to judge it because, for the last 13 months, we have only been working with a handful of people, with one team, some 20 users at most. For 20 users it has been really stable. We'll have to see after we have, say, 2,000 users working all at once in ALM Octane, how the software actually performs.

      How are customer service and technical support?

      For this particular software, the support is very good. We have direct access with an R&D colleague from the provider. They are not only reacting to our requests but also providing some insight and tips about the tool.

      Which solution did I use previously and why did I switch?

      I wasn't really looking proactively for a new solution at that time, two or three years ago. We were aware of the limitations that ALM.NET has, that's it's too rigid, too complicated, and the user interface is not too user-friendly. There was an announcement from Micro Focus, that they were going to release a new tool that would be the next generation of ALM. That was the first time that I heard about this software.

      How was the initial setup?

      It was pretty straightforward. Everything was written in the documentation, down to the smallest details. The package was as an RPM package which was good for our administrator in doing the installation. The only thing that bothered me was the configuration of the .YML file. It was actually really simple, according to what they described about what to configure there, but there were some delicate points that we had to pay attention to. Other than that, everything was really good.

      The installation itself only took our administrator a few minutes. If I hadn't had problems with the .YML configuration, it probably would have taken me a couple of hours to complete the installation.

      The onboarding, the transition from the old tool to the new, is quite a challenge though. We have been using ALM.NET for ten years or more. We are still finalizing the pilot, but our thought is that if we go to Octane, we would prefer to go with a greenfield approach. It's not that we're going to migrate stuff from ALM.NET to Octane. We will just start fresh, from scratch, in Octane. 

      The reason is that the tool provides really good functionalities for us, especially for testing. It's good to take a chance. There will be a review process and we'll try to really integrate the process with the tool.

      For us, the initial setup involved three to five people, until the application was ready to be used. We have been maintaining it for 13 months with two people, myself and the consultant.

      What about the implementation team?

      For the deployment, for installation and configuration, we did everything by ourselves.

      But we are working with a third-party, a consultant, for the customization. Compared with ALM.NET, ALM Octane doesn't have a full scripting capability, so everything is really defined as business rules. This is quite a change for us. Therefore, we need a partner to provide us with some guidance and tips.

      The consulting firm we're working with is profi.com AG. Our experience with them has been really good. I have no complaints.

      What was our ROI?

      You have to take into account all the costs. Right now, we are using ALM.NET. If we decide to go to ALM Octane we will have migration costs, we will have costs for integrating other tools. If we stay with ALM.NET or go for open-source tools, we have to evaluate the same cost factors.

      My guess is, if we go to ALM Octane, and considering all the features that ALM Octane provides, with the open architecture, that would mean we don't have to buy more plugins. We could gain some financial advantage from implementing ALM Octane.

      What's my experience with pricing, setup cost, and licensing?

      It will be as expensive as ALM.NET, if not more expensive. But here's a good tip: If you have ALM.NET, you are able to share your licenses from ALM.NET to Octane. You just have to define a dedicated number of licenses on ALM.NET and then you can share them with ALM Octane, with some configuration effort. This is something that you have to take into account, that there is a possibility of such license sharing that could decrease your costs.

      Compared to open-source tools, the price the ALM Octane is definitely higher, in terms of the licensing cost.

      Which other solutions did I evaluate?

      We are doing a lot of other evaluations; for example, the possibility of using direct JIRA backends for testing. In addition, but not in the same magnitude as our evaluation of ALM Octane, we're still looking at the possibility of holding on to ALM.NET longer.

      What other advice do I have?

      As I said, it's best to involve all the stakeholders, for faster implementation, because it's new software and they need to be on the same page and have the same understanding of the software's concepts. In addition, assess what you need, your process, and if the tool can fit into that process.

      What we did was create a requirements catalog, with a list of all the requirements from the non-functional point of view and the functional point of view. Then we started to evaluate the software based on these requirements, which were created together with the stakeholders. We had interviews with them. That was very helpful because, in the end, you have to see that the tool is providing value for you, based on your requirements.

      I would recommend that you do a pilot with a team that is mature enough to work on the tool. Instead of just looking at webinars, it's better to have a pilot with a team that is really able to work on the tool. That way, they can really see, first hand, how the tool is working, if it's going to be able to be integrated with the process.

      We are trying to implement Agile methodologies in DevOps right now. In terms of how our tools and processes are evolving to adapt to the change from traditional Waterfall development, it's quite difficult because we have been working with the classic Waterfall method forever. It's not just about the tools, it's about the process first, and that the people have to be on board with it. In my role, what I can provide is delivering one tool that is able to support this transformation.

      We are evaluating the possibility of Octane replacing ALM.NET because ALM.NET does not really support Agile software development and continuous testing and because the workflow process, itself, is too rigid. In addition, the effort involved in the maintenance of the application is really big. That is especially true when talking about the software updates. And then, ALM.NET has a complex UI, it's not user-friendly. In addition, there's no lightweight integration possibility between ALM and open-source tools. 

      If we look at these features that ALM Octane provides, and that ALM.NET doesn't have, that is one thing that we can contribute, from the tooling point of view, to support the transformation. But you cannot easily say that the transformation of the whole organization depends on just one aspect, like tooling, because it also involves the process and the people.

      When it comes to the biggest lessons learned about adapting tools and processes for Agile DevOps, I think it is really important, in the scope of evaluating ALM Octane for a transformation, to have all stakeholders on the same page, and to have their opinions and experience included. In addition, define the process first and then go on to the choice of tool.

      Regarding how ALM Octane can help us with the transformation from Waterfall to Agile, we'll still have both methodologies. We're not cutting off one method. We'll have to live with Waterfall and Agile. But for me, Octane will be like concentrating on the core competence, meaning we eliminate waste in managing the software application, for example, by simplifying the workflow. That is important.

      One issue that people forget, when comparing, is that if we are going to update the ALM.NET software, we need at least three hours to do it. With Octane, it took me one minute to update the software. That kind of waste with ALM.NET can be avoided.

      The second issue is that it's important to consolidate information, especially from the testing, defects, and requirements areas. Right now, with ALM.NET, it's not possible to integrate it easily. Everything is possible. You can always do something to create integration between two tools, but it's going to take a lot of effort and resources. In the end, it's all about money. If we are able to consolidate information under one roof, by using ALM Octane and its lightweight integration feature, that will help us with the transition from Waterfall to Agile or, at least, from Waterfall to both methodologies.

      After we are done with the evaluation, the next step will be to deploy it for the organization. We are piloting this software with one scrum team. The next step will be to bring more scrum teams on board with us.

      I rate it an eight out of ten and, for a new product, that's quite good. Overall, it's really good software. I haven't seen anything like this in a long time. But there are some limitations right now: What I mentioned about the architecture of the JIRA synchronization, that it could be simplified; and the documentation could be better. Those are small things that could have been better from the beginning. Other than that, I really have no complaints about it. Those are just some configuration and set-up things that could be better. If those factors are eliminated, I would give it a ten.

      Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
      Gerd Fladrich
      Test Manager at a financial services firm with 1,001-5,000 employees
      Real User
      Helped us implement Shift Left testing but the Requirements Module needs work

      Pros and Cons

      • "A valuable feature is the pipeline, so that we can now connect to Jenkins and then have all the results from testing, from external, in the tool, so that we can see the whole approach from there. Also, We can work with labels so we have better filtering solutions than in ALM. And it's much smarter and leaner to use than ALM."
      • "Also, while there is a Requirements Module in Octane, it is very plain. It's okay to have some requirements described there, but it's not really following the whole BDD approach. I would like to have more features for requirements in there."

      What is our primary use case?

      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.

      How has it helped my organization?

      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.

      What is most valuable?

      The most valuable feature of Octane, in comparison to ALM, is the whole Agile approach, that we can run it with the sprints and have it better connected to the whole development process.

      The other feature is the pipeline, so that we can now connect to Jenkins and then have all the results from testing, from external, in the tool, so that we can see the whole approach from there.

      Many things are nice so it's hard to say what is best; for example, the way it's organized. We can work with labels so we have better filtering solutions than in ALM. And it's much smarter and leaner to use than ALM.

      What needs improvement?

      There is a lot of room to implement new things. I would like to have more possibilities for doing test automation directly in Octane or to see UFT scripts within Octane. The implementation within ALM of UFT was much better than in Octane because I can only see the results from our test runs in Octane, but not the test itself. With Gherkins in there, that's fine, but I do not really have a hand on the scripts themselves. I can follow the pipeline jobs in Jenkins, but I can't see what's really happening there. So I would like to have some more information about that in Octane.

      Also, while there is a Requirements Module in Octane, it is very plain. It's okay to have some requirements described there, but it's not really following the whole BDD approach. I would like to have more features for requirements in there; not as much as in ALM because in ALM it was a mess, it was too much.

      There is a whole lot of room to improve.

      What do I think about the stability of the solution?

      It's very stable. Over the last one-and-a-half years, we have really not had an issue. It's fine. We only have a handful of people who are working with it so far, but for them and for us it's okay. 

      We have a very small team. Some are working from Croatia and we have a team here. We have a maximum of three or four concurrently using it. In the future, we will have many more. For the moment it's a pilot, but as a pilot, it's working fine.

      How are customer service and technical support?

      Tech support is very good. We are in direct contact with the guys from Tel Aviv and it's very good. We're in touch by phone, email, and we have sessions together with them. It's much better than it was with HPE, in my opinion.

      It could be, because we are a pilot project and one of the first here in Germany, that we have more direct contact. But this is working. I really like it.

      Which solution did I use previously and why did I switch?

      We figured out that with our BDD approach, and what we planned with more modern technologies, and our shift-left approach, that ALM didn't fit. There was no chance to implement any Agile approach in ALM. We started to think about what else could be useful. It was pretty obvious that Octane was the right tool.

      In ALM you do not have any flexibility to model the processes, to say how you would like to see new things like quality stories. With Octane you can add pipelines, and with the API you can add other tools and, therefore, other processes. All of that is not available in ALM. In ALM, you have a closed system and you have to live with what is given, while in Octane, you have the chance to add new stuff to the tool, like reports from outside, etc.

      How was the initial setup?

      It was really straightforward. It was a pleasure to implement our approach with it, compared to ALM or to the older tools. It was really easy. I started from zero with Octane. I had never seen it before. It was brand new and I really learned it on my own, everything in there, including the setup and how to implement the processes, etc.

      In terms of maintaining it, right now it's just one person. Once we scale it, I don't expect it will take many more people to maintain it because it's very easy to maintain. If it's set up well there shouldn't be too much work to do there. For the technical parts, we will still need only one person and, within the project - depending on the number of projects - we will need, perhaps, one guy who's taking care of it from time to time.

      What was our ROI?

      We have had some strong discussions in regards to JIRA, to use JIRA plug-ins and to get rid of the overall HPE/Micro Focus way, because of the money. We had some discussions about whether we could make it with open-source tools. But at the end of the day, we figured out that they're really not good, full test-management tools. The overall approach, with everything in one place in Octane, for the money, is more valuable.

      Since we're not finished with the license discussions, I can't tell you the end result or numbers and figures but, in the end, it's more or less equal, from the money point of view: if you're using open-source with more consulting or if you use a tool like Octane, which costs some money, but you don't have a lot of work in terms of implementing and consulting, etc.

      What's my experience with pricing, setup cost, and licensing?

      I don't deal with licensing and pricing, but it's worth the money, from my point of view, because it's very good. But that's all I can say about that.

      Which other solutions did I evaluate?

      We looked at a few. One we're still having look at is Xray but doesn't fit with our BDD approach. We also looked at ServiceNow. That's mainly for ticketing systems but they also showed us something about test management. It was very close to ALM, to the old way, so it was also not very useful for our process. Our support is working with ServiceNow but it doesn't fit with our project.

      What other advice do I have?

      Think about your processes and the methods you're using for development and quality management and see if the tool fits. If yes, it could be a good idea to use Octane. I have presented Octane many times within our company and outside of the company, and I have had very good feedback and many questions about whether it is useful or not. "Can you really say it's the perfect tool?" Mostly I have said to them it's really good. If you work in Agile and if you work in BDD and Gherkin, I think it's the best tool on the market.

      I have a pretty long history in testing. I started in 1999 and, since then, I have worked with all these products from HPE or, now, Micro Focus. I know all the history and the older tools and I'm really pretty happy that we have a tool now which is working in a more modern way, in a good, Agile way. It's pretty nice.

      With respect to how our tools and processes are evolving to adapt to the change from traditional Waterfall development, for requirements we do not have a good tool to work with, but we have Octane for testing, we have JIRA for development, and we still have ALM for defect tracking and for working together with the other teams that are still working in the Waterfall process. So for synchronizing of defects, we are connected to ALM. We have IntelliJ for development, and we use it together with Cucumber and TestCafe for test automation. We have Git for all our results and for version control. We have Jenkins, as mentioned before and, for reporting, we are mainly using Octane. This is the overall tool landscape we have.

      The biggest lesson about adapting to Agile for DevOps is that it is really important to have APIs, to have open interfaces to connect all of these tools together; to have the chance to implement the pipeline easily. We are no longer bound to only HPE or Micro Focus tools. We can work together with open-source tools. It was easy to implement such things in Octane. This was a great lesson.

      For our releases, we still have a Waterfall approach. We have a live release every three months. It was a little bit tricky to put together the testing for Agile and for Waterfall so that we could do the quality assurance for both approaches in one tool. I've found a way that I can have sprints over a longer time for the UAT, using Octane. We have 40-day sprints and testing in one tool. It was really nice to have found a way to have them in one tool. This was also a good lesson, to see that both can work in one tool.

      There's room for more features but, for a relatively new tool, it's very good. I would rate it at seven out of ten. If the features and enhancements we have requested come through, it will be a ten in the future. Given the maturity of the tool, that it's only one-and-a-half or two years old, seven is a very good number. I can give it a 10 when the Requirements Module is working better and when some other things are solved, some problems with implementation that need work. Then it will be a ten.

      Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
      Venu Cherukuri
      Lead Solution Architect at a consumer goods company with 10,001+ employees
      Real User
      The real power of this tool is how comprehensive it is, the breadth of what it covers

      Pros and Cons

      • "We looked at all the market-leading tools, but we did not find anything quite as comprehensive as ALM Octane. When I say comprehensive, it's not just a single tool for Agile planning, backlog management release, sprint planning, etc., but it also has a built-in, comprehensive quality management module. It also has pipelines where we can hook up with our DevOps ecosystem/toolchain."
      • "There is an opportunity for them to do a little more with the dashboarding. We still feel that HPE Quality Center/HPE ALM reporting is very powerful. We talked with R&D, and there are some things on their roadmap, but at the same time, their strategy is to connect Octane with visualization tools such as Power BI."

      What is our primary use case?

      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.

      How has it helped my organization?

      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.

      What is most valuable?

      We did an extensive market scan and evaluation before settling on Octane, even though we've been an HPE customer and Micro Focus customer for many years. When we wanted to get into Agile planning tools, we looked at all the market-leading tools, but we did not find anything quite as comprehensive as ALM Octane. When I say comprehensive, it's not just a single tool for Agile planning, backlog management release, sprint planning, etc., but it also has a built-in, comprehensive quality management module. It also has pipelines where we can hook up with our DevOps ecosystem/toolchain.

      The real power of this tool is how comprehensive it is, the breadth of what it covers.

      What needs improvement?

      To the credit of Micro Focus, we are very actively working with their product management team and the R&D team as well. When we looked at this tool, inevitably we draw comparisons to, or parallels with, the HP ALM or the legacy ALM tool.

      From that perspective there are some features that we find are missing, probably for a valid reason: Because it's a next-generation tool, some of the legacy stuff has been removed, and it has a newly designed user-experience. But that being said, there is an opportunity to do a little more with the dashboarding. We still feel that HPE Quality Center/HPE ALM reporting is very powerful. We talked with R&D, and there are some things on their roadmap, but at the same time, their strategy is to connect Octane with visualization tools such as Power BI.

      Our perspective of the drawbacks or the limitations comes from drawing comparisons with HPE ALM. Some of those limitations are probably by design and for a reason. That being said, the product management and R&D teams are working very closely with us and we are giving them a lot of enhancement requests.

      For how long have I used the solution?

      Less than one year.

      What do I think about the stability of the solution?

      We have not encountered any stability issues with it yet. We have an on-premise ALM Octane, it's not a SaaS version. We host our own hardware. We did the implementation by ourselves. So far, the application is fairly stable.

      What do I think about the scalability of the solution?

      The usage is going up pretty fast. There will probably come a point where we need to scale. The new architecture for Octane is quite different than HPE ALM. It allows us to scale. We're not quite there yet.

      We have over 3,000 users, about 85 concurrent. It's a globally active application. It goes around the clock. We have North America, Europe, Asia-Pacific, and Latin America.

      How are customer service and technical support?

      The tech support is pretty solid. I've never had any problems. We start with the tech support and, if it's very technical, it sometimes goes beyond them all the way up to the R&D team. 

      Overall, the support experience has been excellent. The reason I say this is that they bring all the possible resources and people to the table, all the way up to R&D, which is the top team from a support perspective. Support is not even that team's primary role, but they still get involved to help us out. They've been outstanding. I'm very pleased.

      We have a customer-success manager allocated to us who is constantly trying to understand where they can help us. With Octane, we've seen a great deal of engagement at all levels of the support team. They are going the extra mile to help us and support us.

      I also really love how they have enhanced their online help, how comprehensive and user-friendly it is. They give standard examples. The help refreshes with every release, it's very dynamic. That has been a pleasant surprise.

      Which solution did I use previously and why did I switch?

      We were using HPE Quality Center, which was sort of a predecessor. We are currently moving out of Quality Center and completely standardizing on Octane. We also briefly used CA Agile Central and JIRA, in small pockets. We decommissioned them, and Octane became our standard tool across the Enterprise.

      We started with the goal of having one tool across the enterprise. Octane met most of our requirements. We did not want to have two different tools for Agile and Waterfall and then have to start integrating them and managing two applications and the training on them, etc. Our primary position was to standardize on one application and we decided Octane was going to be it. Then we slowly planned and moved everything out of Quality Center into Octane.

      How was the initial setup?

      I don't want to call it complex, but it was different. The initial setup felt a little complex just because it's a different architecture, and we were also doing it on-prem. If it's a SaaS, obviously, you don't even have to worry about setting it up.

      One thing we have noticed, since we have done two upgrades, and we're getting ready for the third one, is that the upgrades have been so simple and easy. In the previous legacy platform, upgrading was a project for us. There was a lot of planning, a lot of people were involved, and there was a lot of downtime. 

      For Octane, we get quarterly upgrades and we lag for a couple of weeks and then start upgrading our environment. That's been a huge difference. That way, we are not staying on an older version for many months or even years. We just upgrade as soon as the versions are available from Micro Focus.

      Which other solutions did I evaluate?

      We looked at six tools as part of our evaluation, when we were looking for an Agile ALM tool. We looked at CA Agile Central, VersionOne, JIRA, TFS, Agile Manager, and Octane.

      We did have very extensive requirements and they scored very closely. JIRA was our number two, Agile Central was number three, and VersionOne was our number four. Agile Central scored more, the highest, but Micro Focus allowed us to share licensing between HPE Quality Center and Octane. That was the primary reason it was a no-brainer for us to get started with Octane. Apart from our hardware and implementation costs, there were zero costs to begin with.

      Most of the other tools that we evaluated were very comparable. You could pick any of those tools on any day. But for our use cases, for our specific needs, and the costs and scoring, we zeroed in on Octane.

      What other advice do I have?

      A lot of people, when they pick up this tool, are focused on one specific aspect of it, like Agile planning. They're doing backlog management, release planning, sprint planning, etc. But I would suggest looking at the broader, end-to-end application lifecycle management tools, which includes hooking up into your Dev tools, integrating it into your quality lifecycle, and the pipeline module. That's especially true if your company is an Agile shop and you're doing a lot of automation. In that case, you need to look into Octane and really understand what it offers. I think a lot of people probably don't appreciate or don't understand, they're not aware. Keep that bigger picture, the end-to-end lifecycle, in mind and see if there's any other tool that fits like Octane.

      I would rate it at eight out of ten, which is still a high score for me. It is still truly evolving. I work with Micro Focus and, looking at the product roadmap, there are a lot of good features coming.

      Disclosure: I am a real user, and this review is based on my own experience and opinions.
      MS
      ALM platform architect at a transportation company with 10,001+ employees
      Real User
      We now have standardized practices providing cross-project reusable assets including tests

      Pros and Cons

      • "Backlog management is the most valuable feature. This was a capability that was missing or difficult to achieve in ALM Quality Center."
      • "Octane, from an administration perspective, is very limited. The application is improving with each release but what is missing is the ability to manage users and workspaces. I would also like "usable" reporting for more than a few workspaces. Also still missing is the ability to copy a workspace or get data in or out, except for limited REST calls."

      What is our primary use case?

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

      How has it helped my organization?

      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.

      What is most valuable?

      Backlog management is the most valuable feature. This was a capability that was missing or difficult to achieve in ALM Quality Center.

      What needs improvement?

      Octane, from an administration perspective, is very limited. The application is improving with each release but what is missing is the ability to manage users and workspaces. I would also like "usable" reporting for more than a few workspaces. Also still missing is the ability to copy a workspace or get data in or out, except for limited REST calls.

      For how long have I used the solution?

      One to three years.

      What do I think about the stability of the solution?

      As early adopters, we began using Octane before the ink was dry on the first release. Since the first release, we have seen nothing but added capabilities and feature/functionally improvements. We have not experienced a single instance where something was removed or deprecated. That said, we do find they like to move buttons around and hide things in different drop downs now - but there has never been a loss in capability.

      What do I think about the scalability of the solution?

      We have projects and teams with several hundreds of users and tens of thousands of records (requirements, tests, etc.). There are risks with not being able to copy a workspace to test changes to the CI/CD or pipelines, so that is a miss. The reporting is limited to a few thousand records so we've had to request an override to the limits - but Micro Focus delivered on this immediately, once we stated the case.

      How are customer service and technical support?

      I've worked with the SaaS team and Micro Focus R&D on many aspects for initial setup, bridges, and complex four-system conversions. The technical experts are some of the best I've worked with in more years than I can admit to.

      Which solution did I use previously and why did I switch?

      Octane was brought in to be the standard SDLC platform in concert with QC. We replaced VersionOne, Jira, and several in-house solutions since I've been with the company.

      How was the initial setup?

      We are on SaaS. Setup and deployment were immediate and required no effort on our part, except to make the request. This was also true for staging environments for a PoC.

      Initially, our implementation strategy was to enable a trial period of six months to one year. The community response was so overwhelming that we went into a production mode within the first quarter and began setting up and migrating teams within the first year. Even emphasizing that the platform at that time was essentially a PoC, teams adopted it, even with the risks, and never looked back.

      We work directly with our Micro Focus CSM. The technical team, including R&D, is first-class.

      What was our ROI?

      The only quantifiable ROI is the license cost savings converting from VersionOne and JIRA. With about 200 users for each platform, the ROI calculations are based on what was paid for the previous solutions.

      What's my experience with pricing, setup cost, and licensing?

      I highly recommend the flex licensing model. With flex, we can ramp up or down to accommodate demand changes for roll-outs or PoCs, etc., as needed. It is especially useful for our performance and load testing areas.

      Which other solutions did I evaluate?

      We evaluated solutions from ServiceNow, VersionOne, Jira, and multiple in-house solutions.

      What other advice do I have?

      My advice, going on my experience to date with Octane, is to be sure you are ready to support the demands for licenses. I have found that once a team gets access, they will not go back to the previous tools and will want to convert everything. Make sure you have guidelines in place on the CoE's expectations so the teams actually use the tools for SDLC and not as a replacement for simple request tracking.

      In terms of our biggest lessons learned about adapting tools and processes for Agile and DevOps, building templates and standards that have provided a lot of value in a Waterfall approach do not migrate well to an Agile practice. Previously, we focused on testing, mostly in isolation from requirements and development. Moving to Agile in Octane switched the primary usage to backlog (requirements) focus. The challenge has been to bring focus back to testing and quality delivery in concert with backlog management.

      The challenges we faced with ALM Quality Center were the test and defect management capabilities. There was a difficult process in place to track and link requirements and releases. In ALM Octane we are finding the reverse. Requirements management, release, teams, etc. are exceptional, but we are finding the users are less focused on the testing and defect management capabilities.

      We have 1,000-plus users using this solution in every role. Most are team members but we have admins and integration teams assigned to every role, including custom roles we've set up. In terms of staff for deployment and maintenance, we are on SaaS. Our CSM manages that side of things.

      We have been using Octane since it was released, and maybe a little before that. Octane is a corporate standard and we see no reason to not continue migrating teams - that are ready - from Waterfall tools to Octane. We still support 3,000-plus users in Quality Center who could potentially migrate at some point.

      Disclosure: I am a real user, and this review is based on my own experience and opinions.
      it_user458409
      Test Community Manager at Orange
      Vendor
      Integrates all the tools we need into one solution and connects to CI systems

      Pros and Cons

      • "The most important feature is the integration among all the different features in just one tool: Agile management system, requirements management system, test management, defects management, automatic test execution. Really, if you're looking at other tools, you will never find all that integrated into just one tool with all the traceability, with all the elements in just one place."
      • "Globally, I don't see many major points of improvement. It's mostly plenty of little things, and it's weird to me that they are not in the product yet. They are really details, but they're annoying details... Today, in the tool, we've got plenty of assets we can handle, like requirements, user storage, defects, tasks and so on. And to all of those elements, we can add comments. We can add comments to any asset in Octane but not to tasks. It's just impossible to understand why it's not available for the tasks because it's available everywhere else. Similarly, for attachments, you can attach files absolutely everywhere except on automated runs, which is, again, awkward. I don't understand why on this element, in particular, you cannot do it. It's little touches like that."

      What is our primary use case?

      We use it for application lifecycle management.

      How has it helped my organization?

      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.

      What is most valuable?

      The most important feature is the integration of all the different features in just one tool: Agile management system, requirements management system, test management, defects management, automatic test execution. Really, if you're looking at other tools, you will never find all that integrated into just one tool with all the traceability, with all the elements in just one place. For me, that's one of the main advantages of Octane.

      What needs improvement?

      Globally, I don't see many major points of improvement. It's mostly plenty of little things, and it's weird to me that they are not in the product yet. They are really details, but they're annoying details. I'm sure all these features will be included in Octane in the following month or year because I talked with their R&D so I know they're working on it. But it's just awkward that some points are not there yet. 

      Let me just give you an example. Today, in the tool, we've got plenty of assets we can handle, like requirements, user storage, defects, tasks and so on. And to all of those elements, we can add comments. We can add comments to any asset in Octane but not to tasks. It's just impossible to understand why it's not available for tasks because it's available everywhere else.

      Similarly, for attachments, you can attach files absolutely everywhere except for automated runs, which is, again, awkward. I don't understand why for this element, in particular, you cannot do it. It's little touches like that. 

      The Kanban boards are pretty easy to use and easy to configure. The only thing is that you cannot set a specific color for a specific card, depending on the value of the field. It's a really simple feature, very easy to implement because I implemented it in some other tools that I wrote. So I know it's easy to do. It would be really nice to have that, from a user-experience point of view, but we don't have it yet.

      It's really little touches here and there that are missing.

      For how long have I used the solution?

      One to three years.

      What do I think about the stability of the solution?

      We started from the very beginning with Octane, the very first versions that were released by Micro Focus, and the quality was really high from the beginning. We haven't had any major issues. It's mostly those small enhancement requests we are asking of them. But otherwise, it's working.

      What do I think about the scalability of the solution?

      We haven't put scalability in place yet because of what I explained earlier. Previously, we had two servers for our Quality Center system platform and, with the same number of users, we've got just one application server with Octane. We haven't used the scalability yet.

      How are customer service and technical support?

      We don't have a contract directly with Micro Focus. We bought our licenses through a partner, so we are not supposed to have direct support from Micro Focus. However, I personally know people from R&D, so I get support from them directly, although it's not the official way to do it. However, all the questions I've had have been answered very quickly and they are very efficient about it. So I expect that if I had a contract directly with them it would work like that. So support has been very good.

      Which solution did I use previously and why did I switch?

      We were using the Quality Center Solution from HPE before and, in that solution, we had no way to handle Agile projects. That's one of the reasons we decided to move to Octane, which includes an Agile management system with the test management system and requirements management system that are available in Quality Center. Octane has more features than QC, especially for Agile methodology. It also has all the features to connect with the Continuous Integration tools, and that's very important when moving to DevOps.

      Quality Center is totally obsolete today and Octane has all the new features we did need like Agile management, full web GUI, and connection to the Continuous Integration systems, as well as many others.

      How was the initial setup?

      The initial setup was in between: not very complex, not so simple. Medium.

      What was our ROI?

      We are currently in something of an "in-between" situation because we are still using the old tool and moving to the new one. We have a transition period in which we need to maintain both tools at the same time. It's a difficult period with more work because we have two tools instead of one. We need time to move from the old to the new one. We will stop Quality Center, the old tool, in one year. At that point, things will be much easier and much more cost efficient than before, for several reasons.

      First of all, Octane is automatable with APIs, so we have automated everything that we can for the users: project creation, user management, and the like. With everything automated via the APIs, we don't have to invest in people to support our users. That makes it cost-efficient.

      Secondly, it's cost-efficient in terms of the platform. As I said, we use half the servers compared to what we needed for QC.

      Also, a project in Octane can handle everything that is needed. We don't need to have two or three tools to handle different things.

      It's also efficient because we have less training for users, and there is less expense for synchronizing data between one tool and another.

      Putting all that together, it's really more efficient.

      What's my experience with pricing, setup cost, and licensing?

      Pricing is the weakest point. It is expensive, but the tool has plenty of features. The main problem we have is that the pricing is very high compared to some other solutions.

      Which other solutions did I evaluate?

      We evaluated several solutions. One is called the Tuleap, which is open-source. Globally, it's a software development forge. The problem with that solution is that it's lacking test management, primarily. Then we tested another open-source solution made by a company named Henix, called Squash, which is a good solution, especially for open-source. It's just missing an integrated Agile management system. We also looked at JIRA but it does not have a test solution system and I don't like Atlassian politics very much.

      What other advice do I have?

      Just jump in, go ahead. Don't try to understand everything before starting. The tool is really easy to understand for users. We don't even give training to our users today, they just jump into the tool and use it and they immediately understand how to use it, so it's very cost efficient for us. We need very few people to do training. Don't hesitate to use it, whatever your development methodology is. 

      You have no obligation with Octane. There are plenty of features but you can use just a few of them and, after a while, when you get used to it, you can use new ones, and so on. You don't have to use everything at once and to understand everything at once to use the tool. You can just build on what you're doing and, month after month, use new features. Just go ahead and use it.

      There is a free trial of the SaaS solution, so users can jump in and use the free trial to understand how the tool works, to see what it looks like, and so on.

      I rate this solution at eight out of ten. I'm mostly positive about all the technical aspects. It's just loaded with features. It's very efficient. It works well, there are very few bugs. I don't rate it higher mainly because of the price.

      Disclosure: I am a real user, and this review is based on my own experience and opinions.
      MS
      ALM platform architect at a transportation company with 10,001+ employees
      Real User
      Presents the graphics that people need immediately, without drilling into the dashboards

      What is most valuable?

      The most valuable are the Agile practice methodologies. We have Waterfall with ALM and we use Octane for our Agiles. That's our distinction between the two.

      I like the visual interface. The way they've redesigned the interface over ALM. ALM is kind of old-school, but it's mature and functional. Octane presents the graphics and the feedback that people need immediately without drilling into the dashboards. That's probably the biggest selling point for our teams.

      How has it helped my organization?

      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.

      What needs improvement?

      The biggest challenge for us is to bridge the ALM practices for testing more directly into Octane. That's going to be a challenge because the methodology between Waterfall and Agile is so radically different. We're going to have a challenge with that, but we knew that going in. The testing is new and we have a lot of embedded testing practices with the old ALM approach.

      So it would be good to have something in-between there. Some kind of a bridge or training, that is going to be what we're looking at now.

      What do I think about the stability of the solution?

      We have yet to see anything that doesn't work. It's awesome.

      What do I think about the scalability of the solution?

      We've only got 20 live projects in there right now. So I don't see any issues with it. Until we can put some massive projects in there. We've taken one 65-gig project from Agile Manager and ported that into Octane. We don't see any degradation, but that was still prototype.

      How are customer service and technical support?

      I've used them pretty much every day. It's the most responsive tech support, it's been awesome. That's another reason we're going to Octane, because of that immediate support. That feedback.

      Which solution did I use previously and why did I switch?

      We used Agile Manager and it does not have the testing capabilities. We really needed that. We also need the business rules, we needed some of the workflow that's not in Agile Manager. We needed an Agile solution that had a lot of the same capabilities and business rules that ALM has.

      We didn't see that coming in the Agile Manager, so as soon as Octane came out, we jumped on it.

      In choosing a vendor what's important is communication. Show up. Talk with us. Build that relationship and then we'll talk product.

      How was the initial setup?

      I was involved in it, yes, but I have to qualify that. It's SaaS. All I have to do is call Mike. I didn't have to do anything, really, other than start using it. It's intuitive as can be.

      Which other solutions did I evaluate?

      No, just HPE, Micro Focus. It's our standard.

      Getting something new approved is a nightmare. It also makes our job easier. We tell them, "This is the standard," and we can move on. We're not deluded by looking at bunch of other options.

      What other advice do I have?

      Invest the time. Invest the time. Learn what it can do. Right now, it's still being developed. It's an Agile tool being developed into Agile practices. Don't get ingrained in what you see today. Accept changes. If you truly are an Agile environment, you get that. If you don't get that and you want things to be finished before you get there, then you probably don't understand Agile. They kind of go hand-in-hand. It's an Agile tool being built Agilely and you've got an Agile practice. You should be able to put two and two together. If not, you need to stay in Waterfall.

      Disclosure: I am a real user, and this review is based on my own experience and opinions.
      it_user739560
      Senior manager IT at a transportation company
      Vendor
      It's a lightweight and powerful tool for implementing Agile methodology

      What is most valuable?

      It's the most powerful tool to do Agile framework. It's very lightweight, and the tool itself is built based on Agile methodology.

      My favorite feature is the user interface, how easy it is. And also how the modules are segregated in Octane. It is based on the Agile framework so it looks exactly like how you would develop your applications using the Agile framework. You get into user stories, you get into Epics. Everything has the same names so you don't need to interpret what is what. You can get into it right away.

      I say to our customers, "You can just get into the tool, and just follow the process." That means you are doing the job, like you got into the Agile methodology.

      I like the flexibility that I have working with them, starting from licensing it. The SaaS aspect, the hosting that they are doing, the way they respond to our requests, the way that I can escalate. And the way that we are working with R&D right now.

      How has it helped my organization?

      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.

      What needs improvement?

      I can't say, as I'm not completely technical. But we do have someone working with R&D directly.

      We provide them feedback after they asked us for it. We are meeting once a month with the R&D team. And then we'll send them the list of things that our customers are asking for, or which are missing from ALM. And they will tell us, "Oh, this is coming in this release. That is coming in that release." And if there is something that is missing they will say, "Yep, we will include that in our next release." They take feedback from us and then do it.

      I have some problems with the way they license things because HPE is a hardware-come-software organization. I think that will be solved by moving to Micro Focus. Yesterday I had a meeting with the executives and I told them the same thing, that I hope this is one area that I want them to be improving. This whole licensing issue, it's so complicated. They agree. They wanted to set it as one fits all. But hardware is different than software.

      What do I think about the stability of the solution?

      Right now it is pretty stable. The thing is, it is continuously improving every two or three weeks, they are releasing new features in Octane. We are one of the customers who started way before it was as a prime-time tool. So we are educating our customers telling them there are things that are coming. Also, we work directly with R&D to know what is new, what is coming.

      For example, last month, we didn't have the testing module at all. In ALM we have the testing module. And our customers are so into ALM.net, and when they didn't have the testing module they freaked out. But we said, "Don't worry. It's coming." And it came within a couple of weeks. They got hooked up and they started working.

      The product is stable. Whatever they release, it is stable.

      What do I think about the scalability of the solution?

      We haven't tried scaling yet because we just started and we have about 20 projects in there which are not such big projects. But we haven't had any issues so far. We have confidence, after using ALM for so long, in scalability, the way HPE - before Micro Focus - are doing it. We hope that, they will do the same thing.

      How is customer service and technical support?

      We are directly dealing with R&D in most scenarios. For example, one of the things is we are struggling with is to get some of the reports we want. It's not that flexible to get the reports because we are SaaS and we don't have direct access to the database to see how many users are live at a point.

      But tech support are good. They are responsive.

      How was the initial setup?

      It's straightforward. Because it's a SaaS application, we got access to the server. And then the URL was sent and we started using it. So it's that straightforward.

      Which other solutions did I evaluate?

      When Octane came to us it was a beta program. They said, "This not prime time yet." We evaluated a couple of other tools, like JIRA, which is one of the other tools that we have in our organization right now.

      But the integration between JIRA and ALM wasn't there. JIRA is not our standard, actually. But we do use JIRA because developers really like it. What we wanted to have is the integration between tools. Right now we are using AGM in our organization, which is integrated with ALM.

      So that's where we thought that Octane - even though it was a beta version at that time - we would take it and do a PoC and see if it works. And we thought it's really good because there is a lot of investment being done on the tool from Micro Focus.

      We like how simple it is. It's easy for people to understand. Self-taught and they can work on it. A lot of our internal customers are using the tool even without formal training. They are self-teaching by going through all the resources. So we evaluated it and finally decided that it would be good to use Octane. We made that our strategy.

      Comparing Octane and JIRA, I don't really know what the advantages are from JIRA. For Octane, it is primarily the integration with all the other tools that we have right now. And, as I was saying, it's simple to use.

      And the changes - the way they are building the tool - we are part of the team which is building the tool. So we can always provide our input and make changes. We don't have that with JIRA. JIRA is there, but it's not used as a lifecycle management tool at all. We wanted to have a lifecycle management tool. So that's the reason.

      What other advice do I have?

      When selecting a vendor, it depends on the product and how much they are investing in building that product. We don't get tools because we just like the tool. There has to be the need for the tool itself. It's important that they are able to support us and that they have good customer feedback or references.

      If you are looking for any Agile tool, I would definitely recommend ALM Octane. Not only because it's a Micro Focus tool, but the way that they're investing in the tool. And the ease of use. Our customers were scared before, but now they are loving it. It's a really simple tool. And it's more powerful.

      Disclosure: I am a real user, and this review is based on my own experience and opinions.
      WW
      Qa manager at a tech services company with 1,001-5,000 employees
      MSP
      Enabling us to go to a true DevOps model, which means shorter cycle times, quicker releases

      What is most valuable?

      The fact that it works on all the different browsers, it easily integrates into all the other tools, and that it looks like it will work with our pipeline 2.0 with a kind of DevOps in mind.

      How has it helped my organization?

      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.

      What needs improvement?

      It's the idea of, how do you share testing microservices across different projects? Today things are separated into different projects. I want to understand what the vision is of how you're supposed to test those across, because everything's interrelated now. You're not just testing for one project or for one application. Many of the applications have shared services. How are they gonna do that?

      The next thing is, how do you test deployment objects? So after you're done testing your stories, your features, you want to build a deployment object. I want to take those same tests in automation, and then rerun them, and understand, now I've tested them, but now it's a deployment object, and I've included all the code, and it could include scripts and database changes.

      What do I think about the stability of the solution?

      The stability is good. Granted it is a new product; we use the SaaS version of it. But it's been relatively stable, and we haven't had too many issues. They are releasing new versions of it almost every six weeks, and we really haven't noticed problems with that.

      What do I think about the scalability of the solution?

      I imagine it should scale very well. We're using it kind of in a limited basis now, but going forward we're going to use it for a very large project with up to 100 testers. Because we're using the SaaS solution, and because we used the ALM HPE QC product before, and SaaS, I don't see any reason why it can't be scaled the same way. So, not too worried about the scaling.

      How are customer service and technical support?

      Yes we use the tech support. We use the ticketing system through the tool. We also talk to our customer success person, and generally speaking, the support's been pretty good. The development team also sometimes reaches out to us and asks us, are there any features we'd like to improve, or if there are any issues with the products. It's pretty interesting. I never talked to the actual developers of a product before, and been asked what we're looking for, so that's pretty cool.

      Which solution did I use previously and why did I switch?

      I'd gone to the Discover Conference in the summer, and saw them talk about Octane. And they presented it right at the moment that we were really looking for something. Half of our group that do the testing are on Macs, and were having to go through the Citrix clients to get into HPE QC. Everything they said just hit right on what we were trying to do with DevOps, and the fact that they developed it using DevOps principles, and they "drank the Kool-Aid" that they're trying to sell the product to be used for, was very compelling to us.

      How was the initial setup?

      We did the SaaS version, so if anybody has loaded up Octane SaaS, you just put in your email and request a version, that's basically the setup. So it's just as easy as implementing any kind of open source tool, maybe even easier, because you have built-in support right there. It's extremely easy to do.

      Which other solutions did I evaluate?

      We looked at JIRA with Zephyr. We built our own internal one in ServiceNow. We also looked at something called TestRail. We went with Octane, just because of the reputation of HPE. It looked like everything they were doing was going the right way. We did an evaluation between Zephyr and Octane, and we really liked the interface in Octane. We just weren't really happy with JIRA, we were already using our own storyboard that we built in ServiceNow, so it really didn't make sense, and Octane just seemed like a much better choice.

      What other advice do I have?

      When selecting a vendor, I think what's important is being able to scale to enterprise. Somebody that's going to be a partner, and somebody that's flexible and willing to help us. Some of the open source tools are great, but when you're dealing with an enterprise of $10 billion, you really want that real, dedicated support that you get from a dedicated corporation.

      Regarding Octane, there are some features that it still needs, but apparently they are in the roadmap. I've given it to our most "open source" kind of DevOps developers, and they said, "Well, it's actually a pretty good tool." And these are the guys it was impossible to get into a test tool before. So just based on the adoption, it just seems like it's going to be much easier. So I'd rate it much higher in that sense.

      I would say, you can go out and get a free trial of it, demo it. The integrations are extremely easy. Just try it out in parallel with production, and see how you like it. I think it's something worth looking at, and then understand the roadmap. And if you're truly going through a DevOps transformation, then this is a tool that's gonna align with what you're trying to do better than a lot of the tools out there.

      Disclosure: I am a real user, and this review is based on my own experience and opinions.