OpenText ALM / Quality Center Reviews

I primarily use ALM Quality Center as a conversion tool.

Previously, we stored our test cases and results in Excel sheets, which was difficult to manage. Implementing ALM Quality Center has allowed us to map our requirements with test cases and use cases properly.

ALM Quality Center's best features are the test lab, requirement tab, and report dashboard.

ALM Quality Center could be improved with more techniques to manage Agile processes. In the next release, I would like a time management feature to be included.

I've been using ALM Quality Center for two-and-a-half years.

ALM Quality Center is stable.

ALM Quality Center is scalable.

Micro Focus's technical support is functional and responsive.

I previously used Microsoft Azure.

The initial setup was a little complex in terms of setting up the database. Deployment took between forty-five minutes and an hour.

We used a third-party team.

ALM Quality Center is a little bit costly.

Compared to JIRA and other solutions, ALM Quality Center is better for large-scale projects. I would rate ALM Quality Center four out of ten.

We use this solution primarily for doing test cases and running UFT cases.

The integration with UFT is nice.

We are having a lot of problems with this solution. One example is that users are able to run test cases, but the permissions are managed by another group.

I don't have the ability to create test sets.

A lot of the testing steps are ad-hoc in nature where they have a lot of prerequisites, but they don't specify what the prerequisites are.

The organization that I am at is not very good in the sense that even finding test cases that need to be run is very difficult.

The UFT tests don't work very well and it seems to depend on things as simple as the screen resolution on a machine that I've moved to. Specifically, if I move to a screen with a different resolution then it throws things off.

I first started using Micro Focus ALM Quality Center in 2011.

We are using version 12. It has a new name, it's called HPE application Lifecycle Management.

The stability of the hardware is okay. It's just the tool itself is not easy to use at all.

The scalability is not great at all, especially with the licensing model.

I have never had to use them because we have an in-house group that manages many of our issues. I don't know what their interactions have been with Micro Focus, but I have personally had never reached out to them.

My experience with it, in general, is that the initial setup is not easy and that upgrades are dreaded. Companies tend to not go through the upgrade process because it causes many different types of issues, especially on the database side. This seems to be a longstanding bug with the management of permissions that goes all the way back to quality center days that have never been addressed. 

I would say that the initial setup is not easy at all.

The licensing model is an area that can be improved.

The cost of licensing depends on the number of VMs that you are running test cases on and it is not cheap. To the best of my recollection, it is several thousand dollars per license.

We are having a lot of problems with this product and we're now looking at other options.

This is a product that I do not recommend but if someone were in a situation where they were intent on using it, my advice is definitely to plan it out ahead of time. Don't try to wing it and learn it on the fly. Have someone who knows the tool and can set up the proper authorization because otherwise, it will be like ours, which is a mess.

I would rate this solution a three out of ten.

We use it for defect management and for test cases. We synchronize it with JIRA for the requirements and the defects side of things.

We're also using it for our UFT script repositories, but that is more than likely going to change, in the next couple of months, as we go across to GitLab. It's just simpler to have all the artifacts for a particular iteration in one place.

Quality Center is cloud-based with a local client.

The way Quality Center improves our organization is with the traceability and through standardardization. It's about having the test cases all in one place. That's very important for us. It will be even more important once we revive the regression suite in the coming months. It's extremely important to have one source of truth.

It definitely helps in standardizing our testing process and, if utilized properly, it will streamline it because everyone is using the same standards and capabilities. It has helped with that in the past and will in the future as well.

Quality Center also assists with risk-based testing. You can put risk ratings on test cases as you go, and if you do that you know which ones need to be run, for sure. It doesn't have very much smarts around it though, it's just a field that we fill out. It doesn't utilize AI, which some of the tools in the market are purporting they can utilize to determine which test cases need to be run. But I think it's very early days for that yet and I'm exceptionally skeptical about it.

The automated scripts give us management control.

Defects are widely used within our organization. 

We've had a little bit of a hiatus on the test-case side of things, because we decentralized the testing team, but that's about to be re-centralized. The test-case repository and linkage through to regression requirements will absolutely be a key component for us. We haven't got it yet, but when we've got an enterprise regression suite, that will be a key deliverable for them. We will be able to have all of the regression suite in one place, linked to the right requirements.

Also, its traceability and visibility features are good when it comes to managing multiple projects, which is how we've got it set up. The reporting was a little bit clunky to start with, but we've built some reporting out of it now as well, to give us a cross-portfolio view of those projects that are using ALM. Each project can do its own thing, to a certain degree. There are some standard fields that we don't bend on, so that we can get the correct reporting out.

There's no problem at all with its ability to handle a large number of projects and users in an enterprise environment. We only ever have up to 60 concurrent users, but the number of users we've got in the database is in excess of 250. We manage it reasonably well, that way. Project-wise, we've got about 40 to 50 projects in there.

The security features are good. They will be better once we get the single sign-on capability with ADFS on ALM 15. We're very keen to get that capability up. We're looking at the implementation process for single sign-on right now. It should be okay. It makes things a lot more convenient for us, particularly as we have a number of contracts users come in. When they go, we've got to manually remove them from ALM at the moment, because it's got its own authentication. Because it's in the cloud, anyone can get to it directly from anywhere. They don't have to come through our network to get to it. That is good in some regards. But it does give me some concerns when people have departed, or when organizations that we've been working with have finished up with it, because we have a separate swipe that we've got to do to remove any users who are no longer working with us.

There's room for improvement on the reporting side of things and the scheduling, in general, is a bit clunky. 

They can also improve on its interoperability with other tools. All tool sets need to evolve in that regard. They need to understand that you don't buy all one color of tool sets these days and that some tools do a job better than others, depending on what it is. If I've got an industry-strength configuration management tool and repository, like GitLab, I'll pull my stuff out of ALM and I'll interface with GitLab from ALM. That interoperability with other tools sets, the standardizing of interfaces, is an area to work on. All of the tools in the industry are the same. You get a new version of JIRA and it no longer works with the likes of ALM, or you get a new version of IBM UrbanCode Deploy and it doesn't work properly and you've got to do a configuration with GitHub or Artifactory or even ALM, for that matter.

The other thing that ALM could do well with is to move away from Internet Explorer. I believe they're doing that with version 15.

I go back to Test Director days, Test Director 8. That was around 20 years ago.

The stability has been fine. If ever we do have problems we're straight on the phone to our customer success manager and he gets onto any issue that we've got, immediately. But it very rarely goes down.

We only use whatever our concurrent is. We run very lean at the bank, very lean. That goes with all of our tooling. We have a concurrent licensing model that is well under the maximum number of users. If we find that we haven't got enough licenses we adjust the time-out so that people are not holding onto licenses unduly.

With Quality Center, for user scalability all we do is get extra licenses. We've never hit any sort of limit on the size of the project.

We've got a number of admin users, a few site admin users; there's one per domain in our model at the moment. They are the super-users who look after everybody within their domain. Within projects, it's up to the different projects or squads to work out whether they need what we call TD admin users in there. There are also defect-owner users. We also have some analyst users and some tester users.

We'll be increasing usage because we've just kicked off our transformation program with a third-party. As a part of the agreement they are using it, so we'll be upping the number of users that we have. And by reestablishing the centralized testing thing, we'll also be ensuring that Quality Center or ALM is used as our tool of choice. We will reestablish the standards that somehow were dropped when we went to Agile.

They coordinate it for us but I do have direct access to the tech support guys. Typically, if there's an issue, I'll get on the phone and notify our customer success manager. Either we will already have raised a ticket or he'll raise one for us. Then we'll work through anything that we need to do to get things fixed so we're up and running as quickly as possible. 

There have been some issues around getting any major problem that we've had resolved, although we've had very few major issues. It's just a matter of keeping at it until it's fixed. Having that CSM in place allows that to happen.

Before Quality Center the only thing we were using was JIRA. We interface with JIRA. Some teams want to use it for defect tracking. We keep JIRA and ALM in sync using the synchronizer tool that comes standard with it.

JIRA and ALM have different strengths. JIRA and Confluence do Agile planning and management well, and ALM does defect management and test case management and reporting well.

The fact that we've got it in the cloud at the moment, as software as a service, enables us to keep up to date. If it's a back-end or a server-only change, it just gets done. That's the beauty of the arrangement we have with a SaaS or cloud-based version. 

We started using the cloud-based version about four years ago. The setup was very easy and very quick. I did the migration. We had to unload the databases on-premise and FTP them across to the cloud overnight. We did it project-by-project or by groups of projects. Each one of them had its own backup/transmit/reload. They then went through a series of validations and were up and running the next day.

I did it on a project-by-project basis because there was a lot of data that had to go across and be uploaded to the cloud. Once it was up there, I logged on, checked it, and then got the SMEs from the different projects to validate that everything they needed was there.

Having to package up and coordinate clients is, occasionally, difficult, but that's just a project management issue: scheduling things at the right time. Sometimes we have problems and we have to go in and individually blow away components for the product for the client. That's more because of our setup, our configuration on our network, than it is the tool set. We do that with most tools. Occasionally have to rebuild when we've had version upgrades, but not for everybody.

For maintenance there's only two of us, myself and one of the guys that works for me.

As an end-user, of course I'm going to say that it's too expensive and I want things cheaper, but don't we all?

Aside from the standard licensing fee there are no additional costs. It's set up with a good agreement that runs three-yearly.

Do your homework on it to really understand how it works. I've worked at a number of different organizations that have had Quality Center, Test Director, and ALM. They have all been set up differently. I'm also guilty of having gone in as an external contractor and setting it up the way that I want it to run too. But if the time is taken to set it up properly, you will get strong value from it.

The biggest lesson I've learned from using Quality Center is that, when it's used well, it's an exceptionally powerful tool. When you use all the features of it, when you have things that are standardized and locked, it's a really handy tool in governance around testing and projects. But in an environment where you've got multiple external contractors or vendors coming in, where they all tend to bring their own way of doing things, it's good that it's flexible enough to accommodate that, but at the same time it leaves you with a bit of a mess to clean up afterwards.

It's really about making sure when you do implement it that you understand your process, you understand your workflows, you understand the standards that and the reporting that you want out of it, and you set it up accordingly. If somebody comes in and says, "Oh, I want to know what my defect aging is," you can say, "Well, here's the report that does that," if everything's filled out properly.

I've seen it set up really well in a couple of places, and it was really good to have it set up well because we could get the information out of it when we needed it and we could ensure that things were tested properly.

When it comes to connecting all related entities to reflect project status and progress, we have to do a little bit of tweaking, but we can customize it. We can always do better with the cross-project reporting. But the biggest issue we have is that we need to re-centralize testing to get the standards enforced. At the moment, since we've moved out and become very Agile, we've become very lax as well in being able to keep the likes of test cases — in particular regression suites — up to date. That is one of our reasons for reestablishing a centralized testing team. It's nothing to do with the product. It's just that everybody decided, "Hey, Agile's the way to go," and a lot of people with Agile thought, "Oh, we don't have the formality and the structure and standards around testing," which was not good.

At the moment we're in a bit of a state of flux because we've had the whole Agile movement start to hit us. Unfortunately, that meant that there was a decision to decentralized testing and put it out into the different Agile squads, which in turn meant that there was no standard way of doing things. Now that we're engaging in a transformation program, we need to re-establish that standard way of doing things, because we're working with third-party vendors. We're centralizing, ensuring that things are handed over in the format that we want, ensuring that the third-parties are utilizing ALM as the tool set for their test case repositories, and as the defect management tool as well. Being an industry-wide, and understood, standard tool, it's very easy for us to go to our partners and say, "You've got to use ALM because that's what we're using." We are still going to be Agile, but we'll be doing centralized testing.

I wouldn't say Quality Center has reduced the time required for testing. It's a tool. It supports our testing process. It gives the governance and standards around the testing that's done, but as a tool it doesn't reduce the time for testing. Something like automated testing will reduce the time for testing. However, by association, I suppose it might reduce testing time because it's where we execute our automated scripts from.

We haven't found that Micro Focus is still investing so much in Quality Center and releasing valuable features. They did do a big push to go towards Octane and we trialed that. Because we have multiple best-of-breed tools in the organization, Octane could plug-and-play with a lot of them, but then it became an overhead to be able to manage and maintain. 

With ALM in Australia at least, there's enough support and development going on. I know the APIs into ALM have improved, and they needed to because aspects were pretty clunky. Now that we've got a REST API that we can use, that's a lot better. So they're sort of keeping up.

I would rate Quality Center at about eight out of 10, but I have a testing background. I'm very stingy when it comes to rating things. I don't think I've ever rated anything to 10.

• Test management
• Defect management, and 
• Test case storage.

Good test management tool.

Defect tracking.

Licensing model is awful.

My prior organization used the test execution and defect modules for QC. As a manager, I was able to set up reports that allowed me to finds areas of improvement for my team. We used the import functionality to import test cases for reusability and execution.

Prior to using Quality Center, my organization used spreadsheets and emails to track testing efforts. Therefore, QC helped my team become more efficient by tracking all testing activities with the tool.

I like the customizable report functionality. I was able to set up reports that allowed me to accurately give a real-time status all of all testing projects that were in process.

• I would love to see QC update and use metric dashboards at the individual and project level. 
• The UI also needs some updating with a fresh new look and feel.

The biggest benefit is it’s a seamless way for demonstrating the validity of the testing effort from requirement: test planning, execution, and ultimately, reporting.

When I first arrived, everything was manual, no single process, etc. At this point, I set up a standard testing practice utilizing this tool for all testing. It allows for test management to be seen by senior leadership.

Reporting.

Over 15 years.

No.

No.

A seven out of 10.

Not relevant.

It could be complex depending on the setup. However, I have done this for a number of years and do not have any issues with it.

It is expensive.

Yes. Micro Focus, IBM Rational, and Spectra.

It is the standard upon which all products are gauged.

• Integration with other HPE products
• APIs
• Dashboards

Defects and Test management were earlier conducted with the help of Excel sheets. Now, they are tracked in the Quality Center leading to accountability, dashboards, and being tracked in a single place.

Licensing model: HPE has one of the most rigid, inflexible, and super expensive license models. It is an extremely heavy system application. The UI is very dated. Most applications these days have a light UI that can be accessed by pretty much any browser; QC still uses a UI which has a look almost the same for the past 20 years! I am guessing they are doing this to maintain the same look and feel so that they do not have to get their customers familiar with a new UI. When you compare this system's heavy UI with JIRA or TFS, the difference is evident!

I have been using this solution from the time it was part of Mercury Corp as a Test Director. That makes it around 17 years.

Past versions were a pain to use with frequent crashes. The current version also has its own set of problems with HPE deciding to do away with its HTML/Lite version leading to a lot of confusion.

While getting additional licenses is straightforward, HPE's licensing model makes life difficult with customers having to submit a "non-usage" agreement if they do not want active support for part of the licenses. For example, you have 100 licenses and decide to get an additional 50; later on you want to downscale to 50, you will need to sign a document that says that you will not use those licenses even though you OWN the licenses! We found this extremely irritating and impossible to explain to end customers who were (and still are) irate. Support should not have anything to do with usage!

Technical support is pretty good. However, their SLAs are based on locale, timing, etc.

We did not previously use a different solution.

HPE has one of the most complicated installations. Upgrades are a nightmare. Even HPE recommends doing a fresh installation and a cut-over.

HPEs licensing model is inflexible, rigid, and is not customer-centric.

We did not evaluate other solutions.

I would recommend going towards another solution unless you have an entire HPE shop. Other similar products offer more features, are lighter, and are very light on the pocket book, too. We are also moving away from this product, primarily due to licensing costs

• Cross referencing between the modules: Insures traceability between requirements, tests and defects with easy maintenance and reporting.
• Traceability: Ensures that requirements are covered, test cases can be linked back to defects, and code is not pushed to production without testing or checking outstanding defects. Traceability reports are an audit requirement.
• Having the links maintained within the tool is a huge boon to reporting requirements, tests, and defects.

Having a system of record that maintains traceability ensures that reporting and audit items are managed in the same system. This has simplified the need for additional documentation to meet audit requirements.

• Cross project reporting is limited to similar database schemas
• Requirements are not managed as well as in other applications

I have used this product since 2003.

We have a large ALM instance. The biggest issue with stability is related to reporting. To offset this issue, we are working on an alternative reporting solution that would use data warehousing and not affect the application directly.

There are scalability issues. HPE does not support clustering of database servers.

In addition, a specific number of users, concurrent usage, or databases has not been supplied by HPE as a best practice for a maximum per node. To obviate this risk, we are looking at leveraging three load balanced servers and one standalone application server.

The standalone server would be used for third party integrations, reporting, etc. End-users and automated tests would leverage a single vanity URL with load balancing spread across three servers.

We have HPE FlexCare. This provides for single points of contact, which is a must with a large organization.

Training is becoming an issue again with HPE technicians. That glib answer of issues being ‘fixed’ in a later release is being provided instead of true research of the issue. This is an ongoing problem we have seen working with them over the past ten years.

We still use a variety of SDLC tools within my organization. However, HPE ALM has been determined to be the best all around solution for testing of software across the enterprise.

We are doing a number of activities to reach a common goal, including leveraging the ALM template functionality and defining fields and list values across all testing applications.

HPE ALM Quality Center, (formerly HP Quality Center, and before that, Mercury Test Director), has been in use for over 10 years.

It is easy enough to set up an ‘instance’ of HPE ALM.

However, it is recommended to understand the business and process it will be supporting. This will ensure that standards, additional fields, etc. are incorporated early in the design.

If decisions on how the application will be used are not defined early on, then a later project to standardize it may be required.

Without standards, data cannot be shared easily between ALM projects, databases, and third party tools.

If you have more than five users, a concurrent licensing model should be considered. With concurrent licenses, there is no need to search for machines with unused licenses.

• Be thoughtful and consistent.
• Know your current business process and incorporate it into the application.
• Ensure that the management is handled at an enterprise level, as opposed to a department or group level. This allows the application to grow in a supportable direction, while allowing a certain amount of flexibility.