OpenText ALM / Quality Center Reviews

It allows us to track test cases that we create, so for all of our applications that we test we build our test cases, load them into Quality Center, and then we also track our defects inside of Quality Center. It allows us to be able to gather metrics based on the applications that we test.

I would say specific to our business solutions department, we can absolutely take a look for individual applications that we are testing. We can make some decisions about applications being turned over. How defect prone they are. If unit testing is occurring beforehand it helps us at least talk to some "Hey, here is what we received, here is how many defects that we received." It's been helpful with that.

What I am hoping with the latest version of Quality Center is that I would like to see a better interface with being able to load Excel spreadsheets, so a lot of times the key way analysts rewrite our test cases in a spreadsheet, and then we load it up. I would like to see where the interface is better as it's not as user friendly in this release that we have, so I am hoping that it is improved with the latest version.

It's been pretty stable for everything we've been doing.

I would say that at this point I really cannot speak to that.

We haven't used it. I know we are going to upgrade Quality Center this year, so say maybe there will be some more possibilities for us to interact with support.

Quality Center was around well before I got to the company.

It was very easy. LeanFT came with UFT 12.5 and greater. Just deploying the UFT package which we're very comfortable with, we were able to deploy LeanFT as well.

I know there are some other tools out there if you are looking to manage requirements such as JIRA and a couple of others. I know some are really gauged more towards agile development, but a lot of them are used for requirements and they do have the ability to store test cases but we as a organisation use Quality Center.

It works for us in terms of being able to track our test cases, absolutely being able to store results if we want to put in defects and build metrics. It is a pretty decent tool.

Workflow management is a feature we find valuable.

It provides us with common development and test workflow for defect management.

Linking between modules, with actual field values like those between defects and releases.

I've used it for over 10 years.

The desktop deployment causes issues when the enterprise has locked down PC. The application itself is hosted by HP (SaaS).

Very good, 99.9%

It scales to our needs.

7/10 - it could be better, but usually it's good.

8/10 - the TAM and team are very good.

No previous solution was used.

Straightforward, the only issue is doing patch updates as they touch the desktop client which makes it painful to update.

HP hosts the application with no issues, and a vendor does the desktop update. This desktop vendor is expensive and inflexible.

The tool has been in use for more than 10 years, the evaluation was back then and not known now.

Make sure your desktop team have the skills and expertise to handle Quality Center’s client components.

Test Planning and Test Lab modules are the most valuable to capture test cases and track execution. Defect module for tracking defects in testing and to capture production incidents.

The primary HP QC modules, requirements, test plan, test lab, and defect management have become, over time, foundation stones in our project teams development methodology. In each area, the modules provide the fundamental processes to record scope, capture test cases, track execution for each phase of testing (functional unit, string/business process, integration, user acceptance, etc.) and our project management team are all HP QC "savvy" from a standpoint of using the tools to manage the project team, the component releases and change requests, that flow through our team.

The product continues to evolve and improve and we are now on v12.01. The defect module, while fundamental and more or less consistent over numerous versions, is an area we would like to see improved regarding how response time is measured in the standard application. Reporting is another area that could stand improvement - many times the data is simply exported out to Excel for analysis.

We have used HP ALM/Quality Center going back to its days as a Mercury Software product, 2006-2007 and have evolved up thru 12.01 at present.

At Verizon we are 'clients' on a supported application base. Application project teams are supported with domains and projects within a central installation. We didn't deploy the application, per se.

As a client, no, we have not have any major issues with stability. The application is pretty much available during business hours with the exception of routinely scheduled maintenance windows.

No issues to date. We're just a client (one of many project teams supported thru a central HP ALM/QC test tools support team) but the number of project teams that are supported via our central team would seem to imply that the application can scale to support large organizations split amongst multiple project teams.

As a customer/client of a central VZ QA/ALM installation, the few times we have needed to be in direct contact with HP, they have been responsive. We had a better relationship, overall, with Mercury Software before their acquisition by HP, but that was several years ago now.

Most of our technical support questions are fielded by our own in-house QC ALM support team. I can't directly speak as to their relationship with HP regarding direct technical support questions. Where we've had issues with specific installations, etc., they have been quickly resolved, so the assumption, always dangerous, would be that technical support is responsive with the primary vendor.

We have used this application for a number of years now. There have been explorations of a variety of open source, "DevOps-inspired" applications, as a potential replacement. To date, there has been no determination to move away from this application as our standard.

From a project team standpoint, the setup was very straightforward. All the tools are accessible and installable via browser.

We have an in-house one team who are supporting several portfolios within our IT organization. I would say their level of expertise is good to excellent.

I hate to say we haven't taken an independent project level analysis of ROI -- at this point, it's more an integral part of our application support model and a focal point for project level activities. Overall, even if informally measured, it's very high, if by no other measure than how deeply ingrained it has become in our project methodology and project tracking metrics.

Licenses are a major factor -- they are not inexpensive but with concurrent licensing our global IT groups are able to share licenses around the clock.

At the time we first utilized Mercury Quality Center, they were pretty well established as the industry leader in this space. When HP acquired them (2009?) they were the 800-pound gorilla in the test tools field.

For most large companies/installations, you will need to establish a core testing tools support group. This group can handle the care and maintenance of the application itself, the plug-in tools, user management, and deployment to various project teams. I would think taking this one within an isolated project team would be asking for headaches. Many organizations have turbulent histories with centralized testing -- it seems to typically depend on what is business critical -- not only externally, but internally (HR Payroll, for instance -- most companies can't tolerate issues with defects around payroll..

• End-to-End traceability - Request>Test>Result>Defect
• Versioning
• Reporting (since v11 when it uses Word templates)

• Added electronic signature functionality (in-house dev)
• Controlled changes to data allow for validated processes in a regulated environment (record workflow)

• Reporting
• Drill-up, drill-down works sort-of OK
• Multi-project reporting
• User-friendliness, it requires some time to get used to

I've been using it since 2004, when it was known as Mercury Test Director.

No issues encountered.

No issues encountered.

No issues encountered.

7/10.

8/10.

No previous solution used.

It's simple, but customization adopting for a regulated environment is complex as it requires 15,000 lines of code.

It was done in-house.

Review if the all-to-be licensed functionality is needed as certain modules are not used as they introduce needless complexity. You should aim for concurrent licensing if global us is needed as slack periods in one time-zone can be picked up by another.

No other options were evaluated, we just upgraded from Test Director>Quality Center>ALM, and we are planning to upgrade from v11 to v12.

ALM/Quality Center is expensive, but it has its value and, in certain cases, the Enterprise edition is way too much, but it is very stable and reliable. You should review v12 Webclient solution for requirements management.

Our primary use case for this solution is preparing test cases, and we deploy the solution via desktop.

The independent view of elevated access is good. In addition, the elevated instructions being sent to our SQL is valuable.

I rate this solution an eight out of ten. The solution is good, but the response from customer service and support could be improved.

We have been using this solution for fifteen years. We are currently using version 12 but intend to migrate to version 16.

I rate the scalability of the solution ten out of ten. There are currently over 100 users using this solution in our organization.

We have had a poor experience with customer service and support, and sometimes, we do not get responses from them.

We have previously used JIRA, but ALM was a better solution for us.

The initial setup is straightforward.

The deployment is done in-house.

I cannot comment on licensing as another department handles it.

I rate this solution an eight out of ten.

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.

I would say the most valuable is that we can get people started off really quickly on solutions because we've been partners with HPE for a long time and it helps us tailor the product to ours needs. When we have issues with something we can get support directly from HPE since we paid for it.

The fact that it works with a vast number of technologies works for us because our internal customers use the tool for testing a lot of different applications. That's probably the best feature that it has for us.

There's a lot of centralized testing from some perspectives and our main goal is to provide for a bunch of different groups at a lower cost so we centralize licensing and distribute it to various people. The biggest benefit of that is that it allows us to empower the people that need the solutions instead of manually having them develop the solutions on their own.

We've seen a lot of new things in Octane and other things that we have wished for. One of the hardest things that we're noticing is it might be hard to migrate from ALM to Octane, which has the features we need. What we really like is the ability to track different types of tests to our requirement. If you want to play with Selenium Test or LeanFT, UFT tests or any other framework you can think of. Being able to capture those results in a common area is the biggest thing we would be looking for because we have so many different groups that some of them have their own solutions for testing but ALM is sort of the central repository for our results so that would be a huge benefit for us.

In the past three years it's become a lot more stable. Prior to that, we saw a lot of issues with stability and a lot of patching and concern from our internal customers that they couldn't rely on the tool to always be there when they needed it. We spent a ton of time upgrading to the latest version so we don't have as much experience with the stability of it yet.

ALM has really scaled out for us. We have hundreds of projects in ALM and it's always done well with that.

A+

Our biggest issue was in the switch over from HP Inc. to HPE. I think we had some trouble getting in touch with higher level support so we spent a lot of time going through basic support where the people that work with the tools have a lot of experience with the tools. We think that it would be better if we could bypass the lowest levels of support on some issues. I can understand the process that we usually have to go through but more recently our reps have been helpful in getting us to the people that we need quicker so we can get a resolution.

We don't have time to develop a lot of reporting and our customers want a lot of reporting. It's hard to have the expertise to write the scripts in the version that we have now. That's a major pain point for us, something that's missing. Another thing is we always hear about it performance. We have a huge load balance environment to try to speed up the performance but there's always some things that are slow in ALM. Just basic navigations are running automated tests is a big thing we hear. People want to run the tests as past as possible but they feel like they're limited by ALM sometimes.

We have a pretty strong emphasis on quality, so ALM is our gold source repository for quality. That's where we store everything, from requirements, test cases, defects, and all of the artifacts around certifying that quality is evident in every release, in every STLC product we produce.

The UI is terrible in the sense that we actually use automation scripts to avoid being in the UI, which is just fascinating, and then the data model.

I would say it's stable in the fact that it's up and it works. We have challenges with the data architecture. We're excited about Octane. It has some interesting capabilities, but it's our standard. We're used to using it, so I guess it's the things you want to enhance in it, we're just working through that process from that standpoint, but relatively it works.

We're already at enterprise scale, so it's used across the enterprise. I would say that we're at that point.

We invest very heavily on having strong domain and subject matter expertise, so we use support less. One of the things I would love to have is a pay-per-ticket model or a pay-per-patch model. I think that when we call support, it's either a defect or enhancement. It's not just, "Hey, I need customer support," because we're not novice users. We're on the high end of maturity so we're pushing the products in the spaces that I have very much through limits and it's really getting on their solutions and enhancements team.

From that standpoint we get good interaction. There's a really long cycle time though. That's my only disappointing thing around the support is that tickets tend to age, because they're enhancements. Enhancements have a longer cycle, you have to develop it, get it in a backlog, etc.

I have an entire team, so I'm a director and I have an entire tools team that does that. I did get involved in the planning and the strategy of how we're going to do it. My team said that first installation is relatively easy. When we go to upgrade and migrate, that's where there's pain.

Almost every customer will say the upgrades and migrations are very painful. They could be way easier. A lot of it has to do with having to upgrade the data, the in-place database or stand up in entirety, it's just cumbersome. It's very cumbersome and it takes a long time, longer than it probably should. That's a pain point that I think everyone has. Fortunately in our case, we've never had to call professional services to do it. I have a lot of customers say they couldn't get through the upgrade without it. Now, on the support side, it was really helpful, they were on the phone our first major migration for 72 hours.

It was great to literally be in that, "Hey, we're going through it," they were there the whole time, which was really awesome. We didn't have to involve professional services, but that was a good story to say, "Hey, they're on the phone with us. They're grinding it." So the whole 72-hour period we had someone from support cycle in. They did the hand-offs and all that stuff while our team was grinding off. So that was a good story there.

I think it's a great platform. It does a lot for us, but the fact that our users don't want to be in the application is weird. They'd rather work in a spreadsheet and then upload their results to the actual server. Now it could just be their behaviour pattern, but I think if it was a little easier for them to kind of work in, they would have an easier time with it.

Although on the plus side, the fact that it's open like that and you can just connect, maybe that's a positive too. So it's kind of a plus/minus. The UI they said, "Hey, I don't really like UI," but the fact that you can just upload your stuff from your work space, which could be a spreadsheet, it could be Eclipse, it could be a script that you're working in and it just directly uploads, they love that.

When you talk about easy use from an integration standpoint, definitely high marks there, but the UI is just something they really do not like. I personally, as the person who has to get all the data and metrics out of it, the data model is horrible. It's a constant complaint that I have. The new Octane platform kind of solves that. I just wish they had put some of that into ALM because the product marketing strategy is you have to have both.

Have a well-defined process, have a strong reporting structure, meaning in your process you want a lot of measurability. If you define your output, the reports and the questions you need to answer from what you're doing, which your process should be managing for you. In our company, we are very specific about what our executives and stakeholders want.

We have a very well-defined set of measurements that we have to take. We then put a process designed to ensure those measurements are always taken. That then allows you to deal with your outputs and your reporting structure, which then allows you to properly architect your tooling. The technology is very flexible. You have to decide as a client area how you really want to use it and that's going to start with what your business needs are the values that you're trying to get out of it.

That's the biggest advice that I have, it's not even on the technology. The technology will do great things for you if you have a plan and a structure and you know what you want it to do for you. Half the time they don't know, they want the tool to do it for them and it's the other way around. So that's what I advise people to do.

Think about it, have a vision, have a plan, tie that to outcomes, and measure those outcomes. If you're answering the right questions and asking the right questions, your technology will really enable you. You've got to look at it from that standpoint.