OpenText ALM / Quality Center Reviews

Our current environment is ALM QC 12.53 and for performance testing ALM PC 12.53, Vugen 12.53, and UFT 14.

Micro Focus Quality Center helps in end-to-end traceability from releases to requirements to test cases and with defects. The enhanced dashboards capabilities are useful for senior management to view the progress of releases under the portfolio in one go and also drill down to the graphs.

The Project Templates and Enhanced Reporting features are the most useful. We have created domains as per the business units, and per business units, there is one template. It becomes easy to manage the template at business unit level. By standardizing our template, we publish reports at the business unit level.

• Easy integration with open source tools. 
• It has several limitations in adapting its agility easily. 

I feel that the licenses are expensive. 

Valuable for us is having all the data in one place. Having the support for a process of testing. That professionalizes testing, more or less. You need input, you need a little bit of training as you could use vicarious approaches when you use ALM.

They can improve, of course on the deployment side, now whether that will be ALM or Octane I don't know. ALM-Octane with its lower footprint is of course easier to roll out and with the old Java client. I don't know if I could take to a roll out point of view. HP is probably stuck with a bit of a beast. We haven't got many areas where we think it can improve now, if we use it in combination with other tools.

A particular problem area for us is really to improve support for requirements. We come from an environment where everything had procedures for requirements from a business analyst point of view. Having to switch to ALM is a bit of a disappointment. You lose lots of functionality, for example VOV in comparison, baseline reporting. So far being able actually to write the requirements from a granular way. There are system constraints, very old times in ALM which make it an outdated tool for requirements to be frank.

We have been using the product since 2012. We use both ALM and UFT together, as a team.

ALM is very stable. I'd still rather you didn't talk about facts, but it's stable. We never had a crash, for example. If that's what you mean.

It is highly scalable.

The technical support is pretty good. It probably depends on the support contract type you have. Our contract works pretty well as we have dedicated support engineers for our product.

They are knowledgeable and responsive. Sometimes you need a little bit more, but then HP help us to find it as they're knowledgeable troubleshooters. So we never had a problem to get issues fixed when we found that particular person. It was very effective I guess.

The setup of ALM is, well, mixed. You know the old Java clients give some headaches. That's for ALM.

When considering vendors we look for stability, support and reliability. And that's probably it. So we probably are not going for small vendors.

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

Requirements, testing, defect management, all integrated in one solution.

In my previous organization, various tools like Excel and other open source test management tools were used. This was causing issues in sharing Test Management data. Once HPE ALM was brought in as a single solution, and data from all other tools were migrated to it, there was a single tool for all needs.

Agile, Devops.

Seven to eight years.

No.

Agile, Devops

No.

Good.

Need of a single solution for all needs.

Not straightforward, it was a complex architecture.

Expensive tool which could become an overload on the budget in the future.

Bugzilla.

Be aware of the cost aspect, it is very expensive.

Test planning, Test Execution, and Defect Tracking, as these are the code artifacts/deliverables for testing.

A centralized and unified repository of requirements and testing artifacts with access across geographies in real time, which improved efficiency and efficacy of application lifecycle management, including integration of Test Automation tool (HPE UFT tool).

• Integration with other open source test automation tools such as Selenium WebDriver.
• Dashboard reporting including test plan versus test execution progress (overall and module-wise), forecasting test planning or test execution progress based on the past progress run rate.
• More options to slice and dice/analyze defect trends, e.g. open defects count/numbers component wise, open defects count/numbers linked to Test Case IDs, defects linked or converted to change requests (CRs), etc.
• For Agile SDLC support, option to define sprints or iterations, effort estimation, release planning and sprint planning and tracking.
• Ease of reuse of Test Automation scripts for performance testing with HPE LoadRunner integration.
• Mobile Testing support with option to assign/mark test cases for mobile testing with mobile device specification of OS, make, screen size, integration of mobile testing on Cloud e.g. Perfecto Mobile.

Two years.

No.

No.

Nine on a scale of one to 10.

Had used Quality Center and Test Director in the past and HPE ALM is much more enhanced and useful.

The initial setup is more secure and procedural.

Pricing may be a factor prompting a look at competitor products and differentiators or open source options with limited product features. Licensing could leverage combo packs with HPE ALM such as HPE UFT, HPE LoadRunner, etc, as well as continued usage of product post-expiration of license without upgrade and technical support.

No.

Get input regarding the evolving core customer's unmet needs to help choose the right solution.

The tool provides invaluable bi-directional traceability from requirement --> test case--> test execution --> defect.

The ability to have visibility of manual and automated test results within the one product certainly cuts down on the management overhead and eases the creation of project health reports.

The UI is becoming somewhat dated but that shouldn't be a deal breaker.

Out of the box, the tool is very flexible in what it allows the user to do. This can go against data integrity in a regulated world but the tool can be customised to improve data integrity. For example, you could customise the tool's workflow to ensure tests cannot be re-executed after a set of executed tests have been peer reviewed.

I administer it, and from what I've seen you can create defects and follow up the resolution with defects based on the scenarios that you have created in default program.

Other valuable features I've seen are:

1. Requirement traceability 
2. Dashboard
3. Camera, which helps us to take a screenshot at a particular instant
4. Customized notifications of different instances

It centralized all the defects in our organization. It also allows us to test scenarios in only one bullet, one database, so it’s easier to manage. All the methodology around the testing scenarios is gathered into the same product, so it’s easy for communications between the business side and the testing side because they all know where to find the information.

I’m not an expert in ALM, but if I have to look into some issues or other occurrences, I can easily find my way around. It’s quite user friendly, I would say.

I supervise the team using and providing support for the product, and there are a couple of things my team feels that could be improved upon.

1) We need to move test cases manually from Test Case module to Test Execution module. This consumes more manual interaction. If this could happen with any in-built functionality, that would reduce the manual work and time involved.

2) Email notification list. Emails are not triggering to any member of the email notification group if just any one of the email addresses is incorrect. So, if one email address is wrong in a group of ten email addresses, no one receives the email notification that they're all supposed to receive.

It has deployed just fine for us.

Stability is fine, except for a few pop ups sometimes. We don't understand why we're getting them, but it's generally quite stable.

Scalability hasn't been an issue.

• Test Management
• Tracking
• Integration with SAP Solution Manager

The processes of both test execution and test tracking have become more transparent.

We use it for big SAP implementations, which provides ROI after the first project.

More flexible reporting would be good.

I've used it for one-and-a-half years.

No issues encountered.

No issues encountered.

No issues encountered.

The support is good, however their response time could be improved.

No solution was previously in place.

It was straightforward.

A vendor was used for support during the implementation, but we had internal knowledge as well.

The implementation ROI highly depends on the size of the project the tool will be used for in the future. For big SAP implementations, ROI will be gained after the first project.

SAP Solution Manager TAO was considered as we are using that tool for Application Lifecycle Management.

But due to the integration possibilities with HP ALM and SAP Solution Manager, HP ALM was the choice we made.