OpenText ALM / Quality Center Reviews

1> Intuitive GUI: Fairly easy to use and follow. For using QC, deep knowledge of the tool is not required. 2> For each test case, a test script with detailed steps can be created. This makes it easier to run the test script. 3> Provides interface with other test management systems like JIRA. 4> Excellent reporting process including customizable reports and charts. This is very useful for monitoring the progress of QA cycles and communicating the same to the higher management. 5> It stores test cases, test scripts, and requirements in a modular fashion, which can be easily copied and modified to create new test cases. 6> An extremely useful feature of QC is that it allows linking defects with higher level artifacts e.g., a defect can be associated both with a failed test script and the unmet high level requirement. It allows traceability of a defect with varying granularity of information. 7> No extra form required to perform searches on the defect list. Search is available for each field right on top of the list.

1> High licensing cost. 2> QC lacks a "watch" feature thus disallowing independent actors, such as managers / leads, to track the progress of issues. For example, for each defect, only the assigner and the assigned receive any updates / notifications. Everybody else has to employ external means e.g., e-mail to get these updates / notifications, thus introducing humans in the loop.

I have used HP Quality Center (QC) for over 3 years in an industrial setup. QC is a versatile Quality management tool that offers test case and defect management capabilities along with a customizable reporting process. It also integrates with other defect and requirement tracking tools, making it a good fit in multi-team environments, as well as integrated application environments. QC does have an involved initial setup, but once it's done, it is fairly easy to use by testing and defect management teams. However, as QC comes with a high license and maintenance cost, it is more suitable for large projects in terms of cost.

When I use it, it is mostly for test management. The instances I've used are mostly on-prem.

It is a tool, and it works. It has got good linkage and good traceability between the test cases and the defects. It has got lots of features for testing.

It can be quite clunky, and it can easily be configured badly, which I've seen in a couple of places. If it is configured badly, it can be very hard to use. It is not so easy to integrate with other products. I've not used Micro Focus in a proper CI/CD pipeline, and I haven't managed to get that working because that has not been my focus. So, I find it hard. I've often lost the information because it had committed badly. It doesn't commit very well sometimes, but that might have to do with the sites that I was working at and the way they had configured it.  

The feature that I would have liked to see is more integration into CI/CD pipeline and agile pipeline. It should have integration with third-party tools such as Jira, DevOps, and the cross-platform type of thing. The versions I've used are older, so these features may have already been included in the new versions.

I have been using this solution for 10 to 12 years.

I've had many cases where I've lost data. I had bugs where I couldn't record, and the records got lost or locked, but rather than the actual product, it had more to do with the way it was set up at the sites I was working at.

It is scalable. I've seen big organizations using it.

I've not had to deal with technical support.

I also use Microsoft Azure DevOps. I don't really have a preference. It is horses for courses, and it depends on the type of application you're running. For older style waterfall projects, you can probably go with Micro Focus, barring pricing and others things. For agile or particularly a Microsoft Azure-based product, I would go with DevOps because of the better pipeline and the whole end-to-end integration.

I never had to set it up from scratch.

I've never been in the procurement process for it. I don't think it is cheap. Some of the features can be quite expensive.

Generally, it is pretty good for what it does. As a standalone tool for managing testing, it is good.

I would give Micro Focus ALM Quality Center an eight out of 10.

On-premises

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.

More than five years.

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.

More than five years.

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.