OpenText Application Quality Management Reviews

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.

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.