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.