OpenText ALM / Quality Center Reviews

We are using ALM especially in business process testings because this solution helps us to connect the business mindset with our business analytics and the IT perspective. When we ran several years ago classical tests business did not understand the quality of our application. When we began to talk with the business process, it helped improve communication between business and IT.

The business value from Octane has benefited us. We see that it can combine all third parties together, free software, integrate all tools together, and create a single pipeline for development.

The previous version of ALM had a greater functionality regarding test cases. Not automatic, BBT and so on, but now in ALM Octane we have only manual testing and integration with other tools.

I think we need to increase functionality to help us to run testing. When we run the ALM project so I think I can give it a better score after we assess our experience.

Stability is OK as we installed the superior version, and now we are in our testing environment. We are investigating the process how best to use it. I heard that we can download a new version and I think after this conference we can begin our pilot project for the real team because we have several areas for implementing developments and several comments.

We have 10,000 employees. There is a huge IT staff so we need tools that can help us to collaborate with each other.

We have used HP technical support for resolving cases and we also asked help from Presales in HP Russia. These guys resolved our problems and helped us to install ALM Octane in our environment.

When we installed it we had a problem because it's running on Linux and we needed to create our infrastructure for installing Linux which was a big problem. The previous version of ALM was working on Windows. But we resolved these problems.

• Traceability from requirements to executed tests and fixed defects
• Visibility and reporting on test execution

It gave us control over the development of requirements and tests needed for the bank's transition from bespoke back-end systems to an Oracle banking system.

The user interface is still dated. Writing test scripts in HPE ALM is generally avoided as the interface is too awkward to use. At the software development company where I worked, the test scripts were routinely created in Excel and uploaded into Quality Center. This process was seen as much more productive than using the HPE QC interface.

At the bank where I worked, I was responsible for training and supporting the end user testers. I constantly found myself defending the way HPE ALM worked. When executing tests, the users would get themselves lost, would expect an action to have taken place when it had not, had lots of problems logging defects, had problems getting screenshots into a defect, and understanding and using favourites.

The interface they have developed is quite good at the top level, i.e., grouping into Requirements, Test Cases, Test Execution, and Defect Management. However, once you get into each area, the complexity of the application kicks in. There is no 'flow' of the basic functionality. For example, in Requirements, the basic function is to create requirements and link them. There should be a wizard that guides the user through that process, which includes suggestions about grouping and structuring, etc. Instead, you are just left dangling.

Another example: Test cases are to be written or modified, linked, selected for execution, and executed. Test execution in particular is a prime candidate for 'wizard-like' guidance for the tester. A much-clearer indication of where the test execution is up to by test set and test case as well the test steps would be most helpful.

What do I mean by 'flow'? Based on my own application development experience, the basic function(s) of the application should be obvious to the user and the easiest to perform. Extra functionality steps are seen as and executed as digressions from the standard flow. I realize that this is not easy in a product as complex as HPE ALM that has been hacked together by several companies and many developers over the years, which I guess is the reason it is the way it is.

We imported a large number of tests and requirements and found a few 'gotchas' on the way, but generally it filled our needs at the bank that I was working at the time.

I used HPE ALM at the bank for 9-10 months.

We had a number of issues with importing the requirements and test cases we had created in Excel. Mind you, we were using a very complicated setup in Excel.

We only encountered stability issues in the importing from Excel. Things would not go quite as smoothly as expected; quite a few emails back and forth to the local supplier.

I did not encounter any scalability issues.

The local supplier Assurity were good.

The local suppliers were very good, but if it was something that had to go back to HPE, forget it.

We were using Excel spreadsheets to try and test a major system change in a bank. Need I say more?

At the bank, the setup took the local supplier over two days to complete. The issues were mostly around meshing into the bank's security and local IT systems.

The vendor was okay. The person sent in to do the installation was very knowledgeable on the product.

It is totally over-priced.

I did not evaluate other options. The system was picked by the QA manager at the time, based on his experience with the product.

I think it is over-priced and would recommend looking carefully at other options.

• Traceability from requirements to executed tests and fixed defects
• Visibility and reporting on test execution

In the case of the software development company, the use of HPE QC helped us to become compliant with GAMP and ISO requirements. The process of developing the software had to meet the regulatory requirements FDA 21 CFR Part 11.

• Reporting.
• Project setup and maintenance.
• The user interface is dated and not terribly intuitive.

I used HPQC at a software development company for about six years. We upgraded it once from 9 to 10. As far as I know, they are still using that version, because the modifications they have made over the years would make it too difficult to upgrade.

I don’t remember any deployment issues. The R&D department at the software development company handled all the install and setup.

I don’t remember any stability issues (it was over five years ago that I was at that company).

I did not encounter any scalability issues. We regularly ran test sets with over 60,000 test steps.

The response from HPE is almost non-existent. Most of our issues were fixed by the company's R&D section.

The switch to HPE QC was made because the existing system was not considered GAMP-compliant.

The software development company spent considerable resources in getting the system set up correctly using modifications developed in-house, as well as developing user guides that we could use for training users of the system.

An in-house team implemented it.

It is totally over-priced.

We had to modify the product considerably to get it to do what we wanted, especially reporting. It never did fully meet our needs for traceability back to user-readable requirements documentation.

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

The most valuable feature is the Quality Center itself. It's a test management tool; so it enables us to manage and track tests, record the effects, and give us full traceability. It enables us to record what's happened and to have full traceability throughout the testing process.

It provides us with a central place for all our tests and all our test results.

The stability is very good.

The scalability is very good.

Technical support can be a bit hit and miss. Sometimes the support has been very good. At other times, the wait has been a bit long to get a response.

We were previously just recording all our test evidence in Word documents. So we needed a test center.

Make sure that you set it up correctly, and make sure you use the full range of tools in it. It will provide you with enough information for you to produce reports and get a full understanding from what you have done.

Our most important criteria when we choose a solution are reliability and scalability.

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.

It's robust and leading edge. They are always ahead of the pack. They spend a lot on research and development and that’s the reason they make good products.

The testing tools and everything that comes with it is very beneficial; especially the REST API environment that is best-of-breed.

I am not an end user so I can't really say. But, I would like to see improvement in the price.

The solution is very stable.

You can use it any way, so I suppose it is very scalable.

I am not personally responsible for technical support, but the other team would have used them.

We have always been using HPE products, so we have just grown with it.

Another team was responsible for the setup.

Specifically for this solution, they need to be in a close relationship to co-develop functionality. They also need to know the vendor is there. That is the biggest plus from an HPE perspective.

ALM makes functional testing much easier for our customers. We tell them that if they use ALM, they will have a productivity gain of at least 40% compared to using traditional spreadsheets, Word documents, and so on. They also need it because their departments are getting larger and larger. They're not sitting in the same place, so they need a tool to combine their teams’ efforts. This is difficult if you are using Excel spreadsheets because you need to send them by email and make sure they have the latest version.

We see the advantage of ALM over Quality Center. You can have templates instead of having specific templates for each product. Once we define the workflow for customer X and the setup for that customer, we include all of that in the template. If we want to make a change, we change it in the template. We'll then do an escalation down through all of the various products so that each and every one gets updated. So it means that things are administratively much easier with ALM compared to QC.

With Octane, HPE is finally trying to combine the agile world together with the functional testing world. It also has an integrated ALI, which means that with Octane you have one point of view of your whole testing process. I see that this as very valuable because we're also competing with JIRA and so on, which has the facilities that we are trying to accomplish with Agile Manager.

JIRA is fancied by developers; so if a war starts between developers and testers, usually what we see - in Denmark, at least, - is that the testers are on the losing side. But if we can get Agile Manager on our side, then we can start competing with products like JIRA.

We should consider not being a testing tool as such. I know that with ALI, we integrated the customer's EDI - the Eclipse, SAP and Visual Studio - but we'll need to do that more. We need to get moving in that direction as well.

ALM is a very stable product. The latest version we install at customer sites is 12.5.3. It's a very stable platform. We have no complaints whatsoever.

Our customers do not generally use HPE support very often; and therefore it's a bit awkward for them to get started with it. They find it pretty difficult. That's not the worst part. The worst part is really when you finally get to someone to talk to, and then they're not qualified. So we instruct our customers, if that happens to you, you should say immediately that I want to escalate this to a duty manager, who can then take charge. It's not as bad as the time we tried to move all of our support functions to India. That was terrible. Thank God we got it back; but I don't think we are there yet. We need more qualified people to take first-line support.

The initial setup was pretty straightforward. We are the experts in Denmark. That means it's a bit easier for us because we know exactly what to do. Various customers use our services to do that for them because it can be very complex if you only do it on a rare occasion. If there is a customer who needs to upgrade from 11.5.2, for example, and they haven’t touched the administrator module for a couple of years, it is easier for us to do the upgrade because we do it all the time.

HPE has failed desperately to offer a competitive enterprise for new customers in this market. If I have a new customer, three years ago I could sell them ALM site licenses. Now I need to sell them ALM global licenses, which is a hard sell because it is double the price. That just doesn't appeal for new customers. So I understand why they take JIRA or stick to Excel spreadsheets because HPE has priced themselves out of that market.

With Octane, you get more functionality; but it's like having Microsoft Word. How much of that functionality do you use? You probably use 20% out of the 80%. So I don't think that adding more functionality solves the problem. HPE desperately needs to get a low enterprise for new customers.

I believe that my largest competitor is our customers who are using Excel, followed by those who use JIRA.