OpenText ALM / Quality Center Reviews

I am the QA Manager, so we use it to score all our test cases, results, defects, and reporting, which is very important. We're able to produce a number of reports and graphs. This helps us a lot when working with our clients.

We're doing a lot of agile work and using a number of different agile tools. Agile integration, as right now it does integrate with version 1.0, but I'm not sure about its integration with some of the other agile tools.

We've been using it for about five years.

It is stable. We've really had no downtime experiences. We've had good experiences with it.

It is scalable. We're actually moving onto the SaaS product. We're looking at that right now.

Tech support has been very helpful when we've had some questions or issues. They've been very responsive.

I'll find out over the next couple of months as we are looking to do the first upgrade since I have been using it.

It's a very good tool. We use it throughout the company. There are just some integration points which could be a little better. But if they're out there, I don't know about them. Maybe having the knowledge and knowing about them would help as well.

Definitely the testing. My app test case organization, being able to organize it, and standardize a quality program.

Definitely ease the complexity of the tool: the upgrading part of the tool. It needs to be easier.

Also, it needs easier integrations. I know one of the big reasons we did upgrades to the ALM upgrade license was because you could use Octane, which Tasktop is giving free for a year. That helps integrate with some of our other tools. I think as our organization, one of our biggest challenges is, we have all of these different tools, and getting them to talk to each other. To really have a whole encompassing pipeline, that is our challenge.

Five years.

We don't really have downtime, but we do have where it crashes here and there. So, stability is not great, but okay.

It does not meet our needs. The product is very geared towards waterfall. Very stable, standard things, and as an organization, we want to be innovative. We want to try new things, and it just doesn't seem to do that easily.

It's okay. We've had to escalate things a few times to get answers, but they have provided them in the end.

Setup and upgrades are complex.

Probably one of my biggest issues with the product is that it's so complex and hard to do. We even paid $30,000 for a consultant to come in. One year in, then we wanted this upgrade again, and they wanted to have a consultant come in again. I'm like, "We just did!"

So, we decided, "We're going to try it without it," and so far it's going well, but the complexity of it seems to be daunting to engineers, not like other tools that they implement and upgrade.

The most valuable thing is the flexibility of the customized options. That makes it more powerful than any other tool. We can customize based on the project and on how we want to control the testing.

We used to have 10 different Excel spreadsheets for one project. Then, we switched everything: paper, Excel, etc. to be done in ALM. There is no outside noise and everything is done under one umbrella.

The canned report site could be improved. You can get your report but you have to do some stuff. If the project doesn't have a good, strong user, they don't get these reports. If we have more canned reports from the ALM site, this will solve some issues.

We have been using the ALM call center since the Mercury times, so the last 10 to 12 years.

It's very stable. In last 12 years, we've probably had two/three downtimes. But, nothing concerning their application.

Yeah, it is scalable. 10 years back, we started with five users. Now, we have 38 confirmed licenses. Over the years, we have grown from having just a few projects to having more than 25 large projects.

Our experience with the HPE support was not great. We have not used Micro Focus yet. Based on that, we switch to a consulting firm, Melillo, for the support because we were not getting direct answer from the HPE support, therefore we switched because of that. Now, we get a better service. Hopefully, with Micro Focus, it will be better.

If someone is doing the setup for the first time, it might be a little complex for them. However, if you are continuously upgrading, then it should be fine, because all of our upgrades we have done in-house. We never went to a company to get that bit done. If you plan it right, you can have the upgrade very smoothly done, so the user isn't affected.

Most important criteria when selecting a vendor: support and stability of the product. These are the two most important things to us. We want to have continuous improvement, because there are places to improve; we also don't want rapid changes, because they do affect the user, so that balance is important.

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

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.

11 years.

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.

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.

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.

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.

Test management and reporting. Those are the two most important things. I tell my customers that the two main reasons they have ALM:

• Quality management, project management from a QA perspective - testing, defect management, how testing relates back to requirements.
• And reporting to make good business decisions in the future.

When I was a customer, it improved my organization because I was able to manage, to enforce standards on building tests, executing tests, and manage centralized reporting.

Now, I translate that over to my customers from various levels of the spectrum from complete, "We have no idea what to do to, we're doing stuff but we know we need to change," to "We've got some stuff and we just want to tweak what we're doing now."

I'd like to see the idea of users being flushed out more, so not just, "This defect is now assigned to a particular person," or "This person is assigned to execute a test."

I want to see the users expanded out to teams where you have five users and the sixth user is the manager, so the manager can roll the idea of somebody being responsible and accountable. The idea of things being assigned to a team of users and users belonging to that team. There are ways of getting around this in the tool because it's very customizable, but I'd like to see that separate from the idea of using security groups, which is one way of getting around that.

I'd like to see the concept of teams put into it.

ALM has gotten more stable over the years. It's a stable app. Like any other large, complex application, you run into things every now and again. We have a system to report things and get them taken care of.

I have customers that are small and customers that are enterprise-wide. So I'm able to deploy it in both kinds of environments and customize the tool, depending on size and level of maturity, for any kind of customer. Also within any vertical as well.

I have used tech support. Mostly because I'm with a consulting company and we also support ALM. We have our own internal support organization that people can get into.

In terms of Micro Focus support, because I'm a more advanced user - I've been using this tool since version 7 - I typically don't get a whole lot from first-level support. I tend to want to go right up to second, third, or even directly with the development organization. So I'm more the outlier, edge-case kind of person compared to most customers out there.

Once I get to the people that are at the level that I know I need to deal with, they're good. I'm also dealing with the people on the other side of the ocean, working directly with people who may have actually coded ALM to begin with.

When I became a customer in 2000/2001, when I first started, I was involved in the decision to purchase the solution. Now, as a professional services consultant, that decision has been made and I'm going in there to either deploy, upgrade, or help them use ALM to best suit their needs. In some cases I help them figure out what it is they need to have ALM do for them or how to customize it best.

When I was a customer, we were not using another solution. We were completely manual and I was a department of one. I was the QA organization for a small development company and the two company owners said to me, "We want to invest in this, go look and see what's out there and show us what our options are and what you think the best option is."

What caused us to switch to this solution was the customizability. The fact that we could make it give us the information that we needed to get out of it. The support organization seemed very top-notch. I actually learned a lot from the support organization when I was getting started in it. And I found it more intuitive then the Rational solution.

I've deployed it in many organizations because I'm a consultant. I've deployed it, upgraded it, customized it, in various ways for different customers.

In terms of complexity, it really depends on the needs of the customer.

When I was a customer in a small development organization that only had 20 people in the entire company, I deployed it, I did the customization - that was way back in the day.

Now, I have customers along the entire spectrum from small to large enterprise. Some customers are okay with near vanilla, out of the box. And some customers have very complex sets of business logic that they feel, for whatever reason, need to be enforced as far as how their defect management lifecycle is going to go. How their test construction, test execution lifecycle is going to go, how they want to manage requirements, and that can require significant customization.

Some of my customers have compliance concerns, they have digital signatures and they have FDA 21 CFR Part 11 compliance. They have all of these rules that they have to follow and some of them are subject to interpretation, so with one particular rule I have one customer who says, "This is how we interpret the rule," and they have me customize it one way; and I have another customer who says, "No, we're not going to interpret it that, way we interpret this way," and it's a completely different set of customizations.

Back then it was Mercury Test Director, which is now ALM. We were also looking at the Silk products, and we were looking at the Rational, now IBM, products.

When selecting a vendor to work with, I want to see that the technical people are really knowledgeable of what they're talking about. I want to know that the tool can give me what I need, not just, this is a standard proof of concept. I want to see what I need to see, and I want to know that, down the road, I'll be able to either get out of it what I need or be able to learn or have somebody come in to help me get out of it what I need. Because if I'm not getting out of it what I need, then I've wasted my money.

I give it a nine because nothing is perfect, there's always room for improvement, especially when you're talking about an app system as large as ALM is. I've been using it for so long it's kind of second nature for me to think about where its strengths are, and know that if I can't get something done one way there's always another way around it. Or I can integrate something into it or build work flow to make the UI behave the way I want it to.

Regarding advice to a colleague about ALM, remember that your process and your methodology should be driving what you need out of their tool and not the other way around. Tools can do some really cool stuff. You may look at it and say, "Okay, maybe we could get some value out of this feature that we're not doing today." But don't make that the driving force. It really needs to be able to support what you're doing and force the things that you want to get out of it. Because there's a truism in reporting: If you don't capture the data you can't build a report that's meaningful. So make sure it can get you what you need.

It's a centralized test management solution. The fact that you have a place where you can go and find all the stuff that you need to find, and keep track of all of the results long term. That is extremely valuable.

In terms of functionality, it really provides all of the stuff that you need for managing test cases and test execution and keeping track of all of these different items. Now, in terms of keeping up with the trends, there's obviously a lot of challenges.

The new offering, Octane, has all of the essential features that we need in order to move forward to the next mode of operation. I tried to use it and, unfortunately, we had all sorts of trouble down to some limitations as to what kind of URL you can use. That was a pretty sad issue that we ran into. Had that not been the case, I would right now be planning to move on to Octane.

The key pieces of functionality are in place. The reason why I wouldn't rate it higher than seven out of 10 is because you're still using really obsolete technology like ActiveX. You have to physically install the product on your desktop. That's a big no-no. Other than that, it is not far away from being much better than what it is.

17 years.

It is very stable. It has some issues here and there but not significant.

We have struggled to grow with the tool, because the original model was to have just a handful of ALM projects, whereas, we have more than 150 projects. Whenever you pass some threshold, it becomes a challenge.

Even upgrading, it's a massive effort. I'd say at least a six month effort for us just to upgrade it.

The tech support is not so great so far. At least as far as the HPE tech support is concerned. Before, when it was Mercury, it was the best tech support of all time. Right now it's okay. It's doable. It could be better though.

When looking at a company to work with, it's as simple as knowing that the products are mature. We know that if there are going to be issues, we're going to be able to find solutions or some work around for them. It's as simple as that. There's a lot of competition out there. Especially in the open source space, but for you to get support on open source, that's probably a whole different ball game.

I like the traceability, especially between requirements, testing, and defects. Being able to build up a traceability matrix, being able to go through and show what's been covered, where your defects are, etc.

It's allowed us to be a little more consistent across the board. We have probably 80% of our QA teams using Quality Center. It is a system of record.

It really does allow our testers to work in a single application. It's not as good if you don't set things up in advance to work with other applications. But we're working on that part.

I'd like to see an easier way to upgrade and install. I'd like to see it less required to have a client. I know that Octane doesn't require a client, but Octane is not mature enough for our organization. I'd like to see some of the good points from that integrated into it.

I would rate it a 10 if it had the template functionality on the web side, had better interfaces between other applications, so that we didn't have dual data entry or have to set up our own migrations.

It's been around a really long time. It is very stable. It does require a little more work to upgrade, add patches, because you have to take it down. But then again, while it's running, we've had very little down time, very few issues from a system perspective.

When we do have to take it down, we usually take a full weekend, because we're a very large instance. But usually the install and upgrade goes through and takes three or four hours, and then it's just going through and running repair/realign or upgrade on the existing projects.

Quality Center is very scalable. We have over 700 active projects on our instance. That's projects, not users.

I've seen a lot of improvement over the years, from tech support. We are premier customers, or whatever the newest term is. We do meet biweekly with them and when we have an issue, we can escalate it and we get very fast response times.

We're a company that has gone through a lot of mergers and consolidations, and we've gone through and actually consolidated a lot of instances into ALM and, with that, the complexity is more with the users than it is with the application.

Getting it installed, getting it set up, that's the easy part. Getting people trained to use it, that's a little bit harder. But once people start using it, they find that they're not sure how they did their job before.

The most important criteria when selecting a vendor to work with are:

• They need to be stable.
• They need to be financially sound.
• They need to have a good technology and support base.
• They also need to be responsive to the company, because it's a big company, so we expect people to respond.

I would advise a colleague considering this solution to start with a plan. Make sure you know what it is that you want to accomplish with Quality Center, and only add fields that will meet that. Use your current documentation, your current processes, to help design the fields and the projects for it, rather than just adding things one at a time. Don't allow a "wild west," which is where anybody can add fields, add workflow. You want to manage that from the top down.

It gives us a solution where we can keep everything centralized like our test scripts, test data, and our projects. It doesn't matter who is creating the project, everybody can access and execute it. Both our onsite and offshore teams working from different locations are able to benefit from this solution. That's the beauty of it.

When we implemented this solution, we chose to virtualize, so we didn't implement any physical hardware. We're able to scale very quickly for very large projects when we need to run 5,000 user simulations. Afterwards, we can also scale down quickly. This gives us a lot of flexibility in our project executions.

The web client doesn't match the quality of the rest of the features of this solution. HP needs to improve it.

There are some challenges we faced during the deployment. But, we've had no major issues.

We've used versions 11, 12, 12.2, and now, 12.53. They've been very stable in our environment.

We're able to scale up and down as needed. It has great flexibility when it comes to scaling.

There are challenges related to the network security during the set up. But, once you figure it out, solution is relatively easy.

We have done the implementation in-house.

While comparing to the previous solution, this solution gave us as much as 60% cost savings.

Before you start implementing, make a solid plan and try to figure out the challenges before hand.