OpenText ALM / Quality Center Reviews

REST API. It lets me do what I need to do, instead of what HPE Quality Center does on its own.

By using the REST API, I have automated QA Reporting, and integrated QA information into the development build process.

Its performance is horrible, and it's unnecessarily complex, which means the local site administrators set it up to be used in very unproductive ways.

10 years (including earlier versions).

Yes. While most of it is introduced by our poor local setup, that is a direct outcome of my complaint mentioned in the need for improvement.

Yes, but again this mostly do with how we implemented it locally. Again, it is an outcome of the issue that the local site administrators set it up to be used in very unproductive ways.

On the lower end.

I have a lot of trouble getting to useful information – on the HP site, and with their technical support. Though I’m far removed from interacting with HP support directly now (at one point I was on the local support team for HPE QC, but now I’m just a user within my company).

Yes – HPE QC is much better than anything else I have seen.

Extremely complex, and unnecessarily so. Main reason was HPE QC doesn’t do a good job of explaining how you can keep it simple and still get the same job done. The tool is ready to do a great job, its how it gets implemented that is the real problem.

I understand that it’s still extremely expensive.

Yes – PVCS Tracker, Compuware’s Track Record, SmartBear, and JIRA. Some groups use JIRA for defect management (in addition to its development usage), but local JIRA usage is just as messed up in its setup that it just recreated the problems which we have with HPE QC instead of solving them.

Same advice as for any Test Resources Management product: KISS – "Keep it simple, stupid."

HP ALM is a good tool for a centralized and coordinated view of requirements, tests, defects, and iterations.

The main barriers of entry are cost and implementation, especially if an enterprise implementation is the best solution

Being able to have one place to review defects, testing progress, and defects was very useful.

Merging 40 different streams, just for defects, into one solution that had good search and reporting capabilities saved a significant amount of time in coordination, defect management, and by consequence, there was better control of the quality of delivered software.

The main barriers of entry are cost and implementation, especially if an enterprise implementation is the best solution

I have used this solution for eight years in a variety of versions and companies.

The biggest challenge was finding the appropriate resource balancing for the enterprise release. It is not very clear how that was going to be implemented due to documentation in 2010.

If there is a need for third-party integration, the documentation is not very good. We were able to integrate with FIT, but it took a very capable programmer to figure out how to do it. Again, this was in 2010. Hopefully, the documentation has improved.

I did not encounter any issues with stability.

I did not encounter any issues with scalability.

Customer service was adequate.

Technical support was adequate

We used a lot of home grown 'tools' and spreadsheets in one location and Lotus Notes in another.

In one instance, it was straightforward because anything was better than spreadsheets.

In the location that used Lotus Notes, there was a significant amount of resistance because of loss of control.

Neither instance was due to the tool, but it was due to cultural issues.

The implementation was done in-house.

At a Fortune 100 company, we achieved a reduction of 30% of defects in the first year and decreasing percentages the subsequent years.

The dollar figures were proprietary, but were significant even for an $11 billion dollar revenue company.

The main concern is that there is a significant dollar investment, so do good research to make sure the tool will meet your needs.

We evaluated IBM tools, as well and a couple of Open Source tools.

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.

ALM helps us keep track of all the functional testing that we do for projects before deployment and even after it goes live. We also use it for tracking future enhancements, and all the functional defects. Test requirements are maintained in ALM.

It saves time, and definitely mitigates risks in having products which are not very well built, to having a product which will perform well and function well once it goes live.

I work in a bio-pharmaceutical company, so we have lot of validated applications, and when we do functional testing for these validation applications, tracking the e-signatures is very important.

I know there are plugins to track the e-signatures, but the problem is that it's very hard to get them implemented. There's no out-of-the-box way, as far as I know, to implement track changes continuously, that comes with add-ons, and those add-ons operated by third parties as well. They are not very mature and there is a huge learning cycle in adopting them. Due to these reasons, the effectiveness of ALM for an industry like ours is less than what we would see in LoadRunner.

It has been challenging in the past, specifically when a new version is released and we have to upgrade. We haven't been upgrading that often, and because of that, it may mask some other issues which we would encounter because by the time we upgrade the new version we would have gone through some of the new patch fixes and so on. We wait for a couple of years and then apply the fixes. By that time, most of the big bugs are fixed.

It scales for our requirements but we have been finding it more and more expensive for LoadRunner. They're introducing new protocols, but they are quite scalable.

We haven't used technical support directly from HPE. We go through Avnet for all the technical support. They're a value added reseller partner of HPE.

We acquired HPE products a long time ago before I was around.

We have been using ALM and LoadRunner throughout. I can't recall having used any other solution before that. But one thing I have noticed is that there's less and less emphasis on load, scalability or performance testing, and the emphasis seems to be shifting away completely. This is feedback based on the fact that there's less emphasis on performance and load testing in these seminars as opposed to the last few years.

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.

HP ALM helps us consolidate our efforts. All of our projects are in there. We are also in the life science domain so we have many more compliance requirements which we have to adhere to. It's pretty good so far.

As a user we see one version of the requirements for the application, we keep all our assets together, it gives us a huge traceable. It's all the classic benefits of using an application lifecycle management tool that are available.

We look at service packs, what bugs they have and fixes. From a end-user perspective when you have invested heavily in these tools for the last four, five, six years or more, organizations are there from when it was Mercury. We just want to keep pace with where the industry is going, where the shift is in terms of quality assurance and requirement management. HP is very strong on the testing side, but in the last few years with the agile methodology it has lagged behind. It's slowly catching up and eventually it will get there, but we love the eco-system we're in and will continue to move forward.

It's stable

It's very scalable, a very robust kind of solution and we recommend it to anyone who's looking for application lifecycle kind of tool.

We use an HPE partner for our support needs, but tickets do go to HPE eventually, level two, level three. We have never had an issue.

Our organization is very new in this area. We are a pretty young company. We didn't have any formal task-management kind of tool or testing tool per se. When we were looking at the solution one of our implementation partners for one of the projects recommended it and we looked at it and it's capability. Many of the folks who are on the team have used it in other companies. For the current organization it was a no-brainer not to pick this tool.

It's very straightforward.

Since we are in a regulated industry we have to use the workflow we use, what was built for this. For us it was a straight-forward choice. For large and small companies there are a lot of choices for task-management tools. IBM rational tools are there and then there's JIRA, there's also TFS. There are a lot of task-management tools. They can pick any one that they want to.

The most valuable feature for us is probably the full Oracle component of ALM. It allows our users to be connected to other products.

We're able to use it with UFT/QTP for defect management. When it records a test, ALM will produce analyses to do cross-project reporting. This becomes a large repository of data and information that's valuable for us to make necessary improvements.

I'd like to see them move away from a desktop-type client and towards a web-based client, although we've also had ActiveX issues with web clients.

ALM, as a group, has probably been in use for 10 years plus.

Once installed, no issues with deployment.

The application itself tends to be very stable, but when switching to an open-source website, that's where the issues are. So it's not so much the core application having issues. For example, you may find that it would be an Oracle issue and not an ALM issue. But really there are very few occurrences, even after all these years, of a serious application fault.

Scalability is fine. We have in the region 15,000 registered users and up to 2,200 concurrent users of ALM. We don't really have any scalability issues.

Any issues would have to do with what a certain server application is up to. You just need to keep an eye on it.

We have the higher level, premium support. Technical support tends to be quick and reactive to issues and we don't have any major issues with it.

As large as it is, it's pretty straightforward to put in and you can configure it in probably less than an hour.

My advice would be to research the full system requirements you need for the initial install. In corporate environments, once you've got it up and running, it's more difficult to get off of it. Also, plan to scale up based on projected CPU and space that you'll need to get.

• 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.