OpenText ALM / Quality Center Reviews

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

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.

LeanFT:

LeanFT is a new solution, but in general, it's opened us up to a wider audience such as the developers, so they can actually do their unit testing. We couldn’t do that with HPE UFT. This is the big advantage of this tool.

The second thing is you can use more technologies than with UFT, including using different languages like Java.

The third part is that we can use the Cucumber test framework, which is something that you can use easily with LeanFT.

Quality Center:

Quality Center is our testing management tool. When you're running a global team with more than 120 QA staff around the world, you need one repository to write, run, monitor, and share your test cases between teams.

This is the most valuable feature of this solution and you can do it very easily. The UI is very user-friendly. With one click, you can see the status of each project that you're executing. Quality Center is the Rolls Royce of solutions and I would give it the highest rating.

LeanFT:

LeanFT should include more technologies. For example, I would like it to include the Scala programming language. That is one of the main language that we use.

Quality Center:

There is a new product, HPE ALM Octane, which might be the solution for the gaps. I would like to see more connection to more products and processes, and including the DevOps into Quality Center.

Stability for both is okay.

Scalability is becoming more complex. Scaling involves more experienced people because it’s not easy to scale.

LeanFT:

Because this is a new product, we're not at a stage to scale something. I don't know how it's going to scale. Based on what I’ve seen so far, it should be okay.

Quality Center:

Since Quality Center is a web application, it's easy to add more users and products.

Technical support is good. We are located in Israel, with an Israeli team, so it's easy to contact them. We have the right phone numbers and from that standpoint, it's great.

There's always room for improvement and additional customization that would be nice. In general, both solutions are quite easy to install.

LeanFT:

There is a debate between this solution and Selenium, and we use both of them. Your choice of tool depends on the technology and the gaps in each of them. We are not an “all-HPE shop”.

Quality Center:

We looked at IBM’s RTC for an ALM solution. We use it now for implementing SAFe (Scaled Agile Framework), which is designed for feature tasks, user stories, and program board elements.

We chose HPE because I had good experience with them when I was Test Director. In term of overall experience, HPE provides a good experience for the users and a lot of benefits which you cannot find with other vendors.

The Central Repository is key for us.

It has sped up our regression testing cycle almost three times what it is if we do it manually.

Tighter integration between ALM and UFT, especially from a reporting perspective, for automation reporting. We currently run into reporting issues.

We've been using it for around a year.

ALM's been pretty rock solid for us. Getting it to interact with UFT nicely has been a challenge for us sometimes. There's good integration in my opinion, but it just needs to be a little more rock solid.

It's been able to scale to our needs.

Good, sometimes a little slow, but overall pretty good.

We didn't have any other solution in place, and needed to have a much better solution than doing testing with Excel files.

It's straightforward.

HPE was one of the very few that we actually had on the list. We went with HPE because my boss was very familiar with the product, and felt it fit our organization's needs extremely well.

Give it a shot, if you take the time to invest in it, it works.

ALM allows everyone to work at the same time, doing defects and reporting the same way.

ALM is quite heavy to use because of the process. Everybody needs to do the same process at the same time, and that’s quite heavy. We get a lot of complaints from customers that they're forced to use a process that is so heavy.

It's not always very stable, but that depends on how you implement it in your organization. We put it on a separate server host in Singapore managed by our guys in Bangalore, so they make sure that they’re always available first.

We have a lot of people using it and it works fine.

Technical support is quite good, but sometimes it depends on who you’re dealing with. Sometimes you have bad luck and get a guy who doesn't know much about it, is new, or is in training, but most of the time it’s fine.

ALM is a bit complex since it's scalable and everybody needs to use it. With everyone needing it, you have to open the firewalls to everyone, which makes it complex.

We planned on using the solution for defect testing but it was a low priority for us, we never got around to it.

So far in the way we use the product, it has slowed down our process.

I have not thought about it. Though, I think the tools might be effective if we could utilize them better.

The tools could be useful if we were utilizing them more effectively. There is not a standard way of using the tools and I think that if there was, we would benefit. The tools are also too complex.

If they could improve their BPT business components that would be good to include in the next release. The current one does not seem complete. It is not really user friendly and it is difficult to handle test speeds. Even though the product supports a range of configurations they are difficult to set up and we preferred a different configuration.

I have been using ALM Quality Center for 1 year.

I think the only issue we were getting was with the memory. Our database was getting bigger and bigger so we need to increase the memory for the database to alleviate the issue.

In regard to scalability, I think it is scalable. In our team, we have more than 100, as for the other teams, I am not sure.

The tools might be good but the way we were utilized them was not effective. People have different ways to use the tools and we did not have a standard or conventional way. It would have been more beneficial if everybody followed a set of standards. Making the tools less complex would be better.

I rate Micro Focus ALM Quality Center a five out of ten.