Micro Focus ALM Review

Enables management of all the important assets and metrics


What is most valuable?

The overall task management. Managing all the assets and metrics.

What needs improvement?

I'm not familiar with all the changes, but they definitely have to be more DevOps friendly. They have to certainly be more open source friendly. That's the world we live in, where we can cut costs away from large-scale vendor contracts and service contracts. The ability to seamlessly integrate and provide more capability for those, managing those infrastructures and solutions, is going to be critical historically.

A lot of the vendor products - not just HPE or, in this case, Micro Focus, or whomever that I've dealt with over the years - were much more proprietary, much more exclusive. And what we're finding now is that the world doesn't work like that. Particularly as you move left and shift towards DevOps, application teams now don't consume from a central resource, they consume based upon decisions made internally to that application team.

Ultimately, what they need is flexibility. So any vendor product needs to have that intrinsic in its fiber, to be able to adopt open source, and integrate basically into almost anything, to expand out the choices available to an application; to make the decisions that need to be made independently at the time that they need to make them.

Not having looked at the latest, ALM Octane, just coming from the old world, at the time that it was necessary to implement a test management system to gather more information, metrics across different teams, different platforms, it served the purpose.

Things change constantly these days. There's a lot more going on. There are a lot more integrations available. I think if we're looking at the legacy owned product, I think its kind of come and gone as far as its ability to do what you need to do in a DevOps world. Any solutions in the future - I know ALM Octane is the heir apparent to the old infrastructure - it's going to have to be more DevOps friendly. It will need to be able to enable the consumers, the application's users who ultimately become the developers, to see the value in a more organized test management practice, versus more of a kind of hidden, under the sheets unit testing.

It's actually a whole trajectory of different solutions, different tests, that need to follow the pipeline for those folks. Anything that's not DevOps friendly, that's not DevOps easily consumable, to make the case for a more formal test management practice, is really going to end up by the wayside at the end of the day.

For how long have I used the solution?

11 years.

What do I think about the stability of the solution?

My experience with the solution is that it has been fairly stable. What lies underneath is what creates the instability at the end of the day, the architecture that you are providing the solution on top of. I think once you figure out a viable, scalable approach to it, then the software itself, at least in my experience, has been very stable in running a test management operation.

What do I think about the scalability of the solution?

It has met our needs. Just as long as you have the right architecture from the old days of physical server hardware to more of the newer stuff, which is VMware within datacenters - more virtualized.

And certainly the next rage for everybody is moving into Cloud infrastructure. So things are becoming much more self-service. You're getting model scaling. You're getting the things that are making the system more maintainable. But from a scalability standpoint, you want to be able to scale to the needs at the time that you need them. The Cloud certainly provides that capability.

How is customer service and technical support?

I think like every company, they're changing the landscape. Support, in my experience, has been pretty good. There are always challenges based upon the routing/tier structure of who gets the issue first, how it gets routed, how it gets filtered down to the specific expertise that you need. That depends on your acumen as far as knowing your tooling, knowing your approach, what that's going to be.

Somebody who is very savvy, will obviously have frustrations coming into a tier-one support desk. Who they really need to go talk to at the end of the day may be somebody, and it will vary by company, like a tier-three, real low-level, very experienced resource support tech who fixes those issues. So it's going to vary based upon the customer's competency versus how they are routed through a support desk.

What other advice do I have?

Testing is going to be testing. And the same challenges that you have in any of the different industries are going to be the challenges that you have in the ours, the insurance and financial industry, as well.

You know from DevOps to Agile, to Shift Left to Cloud, to managing your test assets efficiently and effectively, industry is really not going to make a difference.

I've been in a number of different sectors over the years. I've been in QA about 25 years, and having been in the natural gas industry, financials, insurance, HR systems. They are all pretty much the same challenges around testing. So I don't see a discrepancy in terms of the application you're testing. It's almost agnostic to the challenges that are innate with trying to test, within any type of development environment. Now, it just happens to be a more self-service DevOps model, where application teams make those decisions. But there's still always going to be those QA challenges.


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

Sign Up with Email