OpenText ALM / Quality Center Reviews

From a testing perspective, creating our test cases, executing test cases and then raising defects, it gives us good visibility back to our functional requirements.

It’s one product that allows us to do everything from a system test perspective.

We’ve seen a couple demos for Octane and Agile Manager. I think the direction it’s going will deliver what we want. At this time, it delivers what we need, but the direction that Octane is going is what I would like to go towards.

We’ve had the product online for about 7 years.

We have not really had any problems with it. It delivers everything that we need.

The way things are going, it’s going in the direction that we would want; with ALM, Octane, and all the types of products that we want.

I don’t use technical support personally. We have another guy that we report issues to and he looks after those.

I was not involved in the initial setup.

From a testing perspective, it is a great product for system test and delivers everything that you need. It gives you the complete package and full visibility from your requirements to creating tests, test execution and defect tracking. Definitely a great tool.

When looking at vendors, we look for reliability, trust. If you do have an issue, you want to know that somebody is going to take an interest in it.

For us, the most valuable features are the task management function and the requirements gallery that's true to test execution. It's a good mapping tool and a good sensor repository for all prior testing. We can keep all that data in one centralized place.

I think the best improvement it's made to our organization is that because it's so stable, we haven't needed to change. We're able to continue with our business because it's a solution that stands still.

Sometimes there are small customizations that we'd like that are not always available. If I need to contact technical support about an small issues, sometimes it takes some time before I can get resolution. And if there's a feature that's not available, we need to wait for another release because we can't just simply add the feature we need.

We've had no issues with deployment.

It has enterprise-grade stability. We never have any issues with it.

It's definitely scalable.

Absolutely fine. We have contacts where if you just send them an e-mail they will ring you in 15 minutes. It's been a good relationship with the guys. Really helpful.

It's very straightforward and the pre-sales guys are really good.

They come in and set it up.

There are several features of ALM I found to be extremely valuable.

This question should actually be divided up. Several companies receive a different value add from different components of ALM. Some use it only for managing tests and defects and leave out requirements.

But just for sake of overall added value to me, the Test Planning and Lab portions are extremely valuable especially pertaining to a BPT license. Creating your core BPT components and mapping corner and edge test cases from that makes it easy to create regression test beds as well as facilitate Agile development. Also, if you are talking automation, the BPT component is critical in helping with the BPT test driven framework. Of course, the Defect module along with the Test Runners are key for execution and defect reporting. I love the ability to customize different attributes to defects in order to facilitate a specific release type.

ALM has driven some of the projects in my past organizations.

• It has established a sense of accountability with its traceability mechanisms that are unparalleled from a single system.
• It has allowed multiple stakeholders of a project to deliver fast, all simultaneously in an ALM system without having disparate sources of information.
• The automation has been a pride and joy as far as mapping requirements to BPT cases to automation.

• License costs are still staggeringly high.
• Implementation is a bit tedious as far as backend installation and configuration. Perhaps with 12.x it has become easier but there need to be more troubleshooting "tools" in order to do upgrades and better insightful dialog/windows/prompts for new installs. If I compare the feature set of the Requirements module to COTS tools such as Jama, it has room to improve in many areas.
• Also, with tools this large, the integration to automation can be bloated. There need to be a long term, sustainable solution to run much leaner.

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

• The ability to create and store requirements as well as tests, both manual and automated.
• The ability to determine traceability between requirements, tests and defects found in our testing process is a huge advantage in determining the breakdown in the application business model.

Previous to the utilization of Quality Center our requirements were created and stored in Word documents, and all Test Plans were facilitated through Excel, and there was little coordination or consistency to testing standards. Quality Center has allowed us to better track our testing coverage and plan our releases.

I think there are still some changes to help integrate with agile processes better without having to use a separate product. I think that since Quality Center has had functionality added over such a long period of time, that certain modules and other HP tools could be better integrated.

Initially when we started using Quality Center we had some issues with scaling the solution throughout and updating across multiple teams but these issues have since been resolved.

I would rate the level of customer service very high.

Its very high, and once you establish the proper channels and key contacts to work with it is pretty seamless.

We did not previously utilize a different solution for managing our requirements and testing efforts.

Our implementation and setup was somewhat complex do to our enterprise architecture. We have multiple divisions across two companies that share the same servers and architecture but have different needs with regards to setting up and managing projects.

Initially we implemented Quality Center ourselves but then went with an outside vendor later due to some complications. Depending on the complexity of your organization I recommend working with an approved vendor or service partner to setup your installation.

We haven’t really calculated ROI on our testing efforts as of yet.

The Open Test Architecture (OTA) and development of the REST API. The OTA is a published set of functions that administrators and users can use to interact with HP ALM programmatically. The most common example HP ALM users would recognize is the Microsoft Excel upload template, which allows users to upload test scripts to HP ALM projects directly from an Excel worksheet.

The REST API sneaked into HP ALM with little fanfare. The REST API has no application overhead and is fast. HP extended the API through patches in v11.0. Please check your current version and patch level to see which functionality is now included in the REST API.

On a recent multi-year project, the average defect resolution time for all defects was over twenty-two days. My goal was to reduce this number by 20%. It was an easy goal to reach because no one realized that 80% of 22 days was still a number out of bounds for defect resolution. I used custom fields, defect workflow and custom reports to move defects through their lifecycle. Within thirty days the defect resolution time was reduced to 3.1 days and averaged 1.1 days over the next eighteen (18) months.

The graphical user interface has the most room for improvement. Not all screens within the integrated suite refresh the same, some screens or activities are self-refreshing and some are not.

I would also like to see the “Disable Quick Runs” added back as a site parameter or built as an internal function within a project.

I've used it for seventeen years (1998 to present). This product was initially developed by Mercury-Interactive and released as Test Director. My first enterprise installation and administration experience with Test Director 2.0 was in 1998.

Over a seventeen year period, yes. The key to maintaining a site today is in patch management. Keep the patches up to date.

When the patches lag too much, it may be safer to build a new site and port the data than to try and patch an existing site in place.

Customer support for this product is with the vendor, not necessarily HP. After a site has been up and running a few years and all the original implementers are gone, it can take some time to even determine the vendor. My satisfaction level with vendors range from acceptable to excellent.

My personal satisfaction level with HP service and support website is low. I get the majority of my technical information from colleagues or third party discussion forums.

In the Application Lifecycle Management space, HP ALM and IBM Rational are the two big players. I recently participated in an evaluation of the IBM Rational Jazz Platform. The client had been using IBM’s ClearCase and ClearQuest for many years. During the evaluation, an unrelated IBM audit detected a long dormant pack of five ClearCase licenses on an active server. The cost associated with this incident ended our evaluation of the IBM solution.

Historically, most people considered this to be a defect tracking only tool. In that domain, tools are plentiful. Over the years I’ve used VI editor on UNIX, Microsoft Excel worksheets Microsoft Access databases, Bugzilla and Notepad for defect management.

The installation and configuration of an HP ALM site is straightforward for those with enterprise software deployment experience. An installation requires at minimum, a dedicated server with an operating system and database connection. The most typical, physical or virtual, hardware configuration I encountered over the years was a single Microsoft Windows server running web, license and application software servers. Both Oracle and MS SQL Server databases respond adequately, and when given a choice now select a schema based on DBA agreeability.

The installation of an HP ALM site establishes a service endpoint for communicating with other applications via Web Services. I believe the configuration and management of these services is the most complex part of a site installation and requires substantial planning to map fields and permissions across multiple applications.

HP ALM resellers typically perform the initial set up and configuration of the HP ALM site and user projects. In some cases, larger testing firms are also resellers and provide the tool as part of the project. I fundamentally disagree with buying a tool from its eventual user.

I advise clients to do the upfront planning and limit users with access to the site administration console to three or less. The planning required for a successful implementation requires much more time and effort than the deployment itself. Deployments are typically scripted while planning requires humans. Access to the HP ALM site console is separate from project access. I have seen sites with twenty or more registered site administrators. I believe this occurs more as a symptom of long term neglect than an implementation issue.

I encourage clients to use the built in service accounts and APIs where practical.