OpenText ALM / Quality Center Reviews

Consolidate the testing process, centralised reporting, ease of analytics on metrics, easier bug management, consistent flow of requirements, flow of test cases, reusable test cases, testing history, bugs.

It has improved our organization as a result of several factors: All test assets are in one central location; Easier to track progress of QA activities; Easier reporting; Easier to assess quality

Requirements Management, Test Plan, Test Lab, Defect Management, Sprinter, Access control, Versioning and audit.

The project tracking is a bit complex. It takes some time to maneuver around it. It would also help if you could export some of the reports generated from it e.g. the Master Plan.

More than five years.

No

Can be used for really large organisations, multiple test projects

Customer Service:

Very responsive, though we haven't needed a lot of support.

Technical Support:

Technical Support has been helpful.

Initial setup was straightforward.

Vendor. The team was very qualified, both technically and from a user perspective.

We haven't yet computed the ROI.

Original cost was $158,000. Our day-to-day cost is difficult to compute, but it’s very low.

Yes, IBM - CLM.

It’s a great product for managing an end-to-end lifecycle process. It’s easy to use once you get the hang of it. One of the biggest pluses is having all your test assets in one place – requirements, models, test cases, test results, bugs, reporting, tracking (it’s unbeatable in my opinion).

It's also great that HP has now lowered the Saas cost for ALM - it was too high in my view.

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 most valuable features of ALM are in the new upgraded version of 12.53. We're able to more accurately document our test results, our actual versus our expected results, with the new screenshot functionality. That is the most useful part of the tool for me right now. Of course, we use it as our testing repository, and it's basically the way to show the work that we do as QA testers, and to have a historical view of those executions.

Because we can trend repeatable results, we can look at trends of things that are continuously working well, and things that continuously get broken within the software development process. So it helps us improve our testing quality.

Sprinter, I think, is a good part of this ALM tool, but it has some limitations for us. Based on the type of software we use - we have some web based applications and also some power built applications - not able to capture all the objects, or the way that we develop our software. We're not able to use it as much as we would like to. So Sprinter would be something I would like to see better integrated with the different types of technologies used by the software companies.

I'd like to be able to improve how our QA department uses the tool, by getting better educational resources, documentation to help with competencies for my testers, to make sure they understand how to use the tool. Do they really understand how they're using it? Why they're using it. So, for me, that would useful.

For us, so far, it's been pretty stable. Because we have such a ginormous amount of historical data, we've had a little bit of an issue with performance. We were working on copying and creating a new database for that because we have products that we use, FDA regulated products, and we can't get rid of those testing results. So we have to keep them for the life of the product.

So of all of the things that we've experienced, or had issues with, it would be the amount of data we're able to store, because we have to keep everything.

That would go to what I just mentioned above. We're looking at ways to improve being able to capture more results without impacting our products.

I haven't used tech support because we have a couple of different layers within the business unit. So I have people that I can go to, and then those people go to tech support. So it is utilized on a different level, just not by me.

When selecting a vendor to work with, the most important criteria are flexibility, availability, and scalability.

I would say it's a good tool. You have to invest the time into learning the different ins and outs of the tool, and become educated on it. I think it can scale as much as you allow it to, but you have to put the time into learning what it has to offer.

The Business Process Testing module and approach to testing in QC is its most valuable feature.

For manual test cases, we need to write test case each time and if any update or CR comes then we need to go to each test case and update, which is very time consuming. But, with BPT we can update it in less time as would otherwise take to update two or three business components. After a refresh, it will automatically update the whole test set, which is over 100 test cases.

I would like to see a bit of improvement in its look and feel.

We've used it for seven years.

There were issues with the deployment.

We had some issues with the stability.

We had some issues with the scalability.

8/10

8/10

Earlier I used Mantis, but it was not user friendly and had no functionality apart from defect tracking. But HP QC is defect tracking by default. Test Case Execution tracking and reporting functionality which will serve all purposes for testing processes.

The initial setup was not complex.

We used a vendor team with in-house machines for the implementation.

For testing processes and improvements, I would suggest you use this product. But, if you're looking at cost, then that might be a concern, but no doubt it is the best tool for testing.

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.