OpenText ALM / Quality Center Reviews

I personally found the defect tracking feature very useful in my ongoing project. Our complete Agile process of Software development and QA is dependent HPE Quality Center.

It has streamlined communication with business users and technical users whereby business requirements are now tracked on HPE Quality Center.

Thus, providing clarity with simplicity.

I've faced a couple of bugs in the product whereby we were not able to open attachments on a particular ticket.

The session timeout time also needs to be longer in my opinion.

I've been using this solution for close to two years on a daily basis, and it's a wonderful product.

Not in particular, only certain defects that I've mentioned for the question above regarding areas for improvement.

Certain minor issues such as error in opening attachments linked to a ticket and session timeout issues apart, otherwise the product is stable.

The product is scalable and consistently delivers the required purpose.

HPE has dedicated support with this licensed product and they were available for any queries.

Technical issues were resolved based on SR with HP team and the response was good.

We have used HPE QC from the onset as the scale of our operation and the throughput of requirements were greater so using other solutions, such as Kanban, were not feasible in our project.

Initial setup was straightforward with installation and HPE provides tutorials for advanced modification.

It was implemented by our client team and we helped them with the offshore installation.

The value created was high in our project as were dealing with an application with high public exposure, so the smooth working of tracking requirements and defects definitely gave a good ROI.

For pricing, I recommend to buy a bundled package. Check the HPE site for more details.

Other teams had used Kanban and its visual style of quality control, but it was not a good fit in our project.

I highly recommend HPE Quality Center for its simplicity and ease of use whereby Business and Technical teams can see each other's progress and help make better decisions.

Being able to quickly and easily compile executables on multiple platforms.

Just over 10 years ago, our organization joined the Australian Bill payment scheme, part of the technical requirements involve having to build a COBOL interface to their rules validation program. So we needed to source a COBOL development environment which would allow us to quickly develop and deploy a COBOL interface.

None that I can think of from my experience, MicroFocus COBOL does everything we need it to do.

More than 10 years

No, we found the support staff at MicroFocus in Australia to be highly knowledgeable and very much of assistance in helping us get our products setup and deployed.

None, the product has been absolutely rock-solid.

No, the solution has coped with tens of millions of dollars worth of transactions over the years.

Very high.

Extremely good.

No.

Yes, setup was fairly straightforward. It needed a little help with regards to the license server on the development platform, but once that was sorted out everything was smooth sailing.

We developed our solution in-house.

Substantial, the payment platform is an essential customer service.

We found the pricing to be very reasonable.

We did, however MicroFocus stood out with their excellent technical support.

Definitely support of the agile methodology is the most valuable feature. We have received a lot of feedback from our agile teams that the ALM.NET is not supporting their work and it was really great to see that ALM Octane is fulfilling those needs. But our development and testing teams are looking for the new agile and DevOps deliveries.

We see a double benefit because part of our business is still very legacy-type. We are running the mainframes, and so on, the old kind of solutions, where we pretty much see that, at least for the next year to two to maybe even three years, we will continue using the ALM.NET, as such, maybe even for the functional testing and the UFT, as such. But another team is quickly adopting the agile methodology and there we have hardly seen any validity at all on the Octane for over a year now. We started to implement it the first real project in NND Center, and see good results from that.

The new solutions that are soon coming for ALM Octane, such as predictivity and requirements management, are very welcome. Those have been missing from the existing solution. So far, we have been able to manage with the other alternative solution and integrations, but I am also really looking forward to that.

So far, we are very happy with stability, even though knowing that there is quite a lot of new development, especially for the ALM Octane. But so far, so good. I have nothing bad to say.

We are at a very early stage in implementing this solution. But at the moment it looks promising. Although, it is difficult to say how far it goes. But at least, so far, we have started.

So far, technical support is very good because we have been using HPE products, or the earlier Mercury products, for a long time. We have a quite good collaboration with them. From that kind of background and knowing our kind of working environment and solutions, together with their technical support and help, we have been able to implement these tools in the right way the first time, without trying to invent the wheel on our side.

Setup was pretty straightforward. Obviously, we kind of had a bit of discussion internally, because we didn't take a traditional migration from the earlier product. We really started from scratch. That is still somewhat an issue for some of the deliveries, that they don’t want to use the agile method. But we have highly recommended this because they are two different worlds and that it would be better to plan it carefully and not just carry on all the crap from history.

Our development teams are using a lot of open source solutions and other tools, such as JIRA. But, for our business needs and the business purposes, we have seen that HPE solutions are still valid for our business. We need to have backwards traceability. We have to have the capability to show what has been done, what's been going on, and what. In some of the cases, there has been the discussions that, "Yes. We have all this information, but you have to go to the Jenkins, or this and that logs, and it's there." But that's not what the business wants to see. They want to have a high-level visibility on their business. That is why we are still keeping the HPE products, and probably also in the future we'll have them.

Allows us to do defect resolution from logging to resolution. It gives us an overview of all the defects and prioritization for resolution.

The dashboard was not working at first. Later on, it was difficult to customize it.

We have used it on and off for over four years.

In ALM, the most valuable features are the overview, the primary requirements, test cases, defects, and traceability. Manual applications handle the regulations, so we must have the tracking capabilities. Even some of the core systems are not allowed to go down. It's very important that we know what we have tested and what is working and what is not working. That we can find out from ALM.

Stability is no problem.

The first time we installed it was a long, long time ago. We bought small, five license versions of Test Director from Mercury in 2007 and it has continuously grown since then. Today we have 600 users and 130 active projects. The environment gets bigger and bigger all the time.

It's complicated to upgrade. For ALM, we have roughly 600 users. In ALM, we have roughly 130 active projects. So it takes a long time to upgrade. Some of the big projects are 5 GB of data. To migrate that to a new version takes maybe two or three hours, even if we have huge hardware. 

It's very complicated. We'd gladly like to upgrade to newer versions. We plan to use Octane, but we will not end up in a situation where we have two tools. We would like to, but we must find a smarter way to do some kind of migration. Several of the applications have regulations that we follow and we must be able to track 10 years back. We can't just throw away the data we have in there. 

If not upgrading ALM, probably they would like to search and would like to find something else. They really need to find a smart way to migrate some part of it. Of course, it's a totally different tool.

We have looked at many alternatives. We have compared ALM to almost everything. We even have JIRA for smaller projects now. ALM and JIRA are two totally different products that are for two totally different needs. 

For example, we have an on-premises solution of ALM. You have to log into the active directory, so it's not so easy to give to someone outside the company. It's also struggling with different browsers. It's doesn’t work very well on a Mac, for example. The Mac developers and the Mac teams don't like ALM. Now it works much better on Chrome, but we're struggling there as well. They haven't been following the world with browser support. It's problematic to use ALM in Edge, for example.

But with JIRA, on the other hand, you don't have any requirements. It's easy to set up. It's easy to start up and have your backlog there. But after a while, you figure out what is going on. For maintenance and for testing, you need a plugin for this, you need a plugin for that, and you need a plugin for something else. It's not so easy to get the overview or the helicopter view of it, if you compare that with ALM. But I understand why some like it and it has some kind of need. I hope we can mine that capital when we upgrade to Octane.

In our company, the most interesting thing is that ALM can be used for manual testing. The testers can define, by themselves, how they structure the test and then execute it. All the results, both the positive and negative one, are collected. There is easy defect creation.

On the other side, if you look at it as a project manager, you have to see the results, i.e., the current status of the project.

Afterwards, if you get an outage, it is important that you can show the regulators that you did a good job, you executed everything, and you went in production with a concrete status, with no big issues or critical errors.

Our biggest problem with ALM is the version upgrade and especially the migration.

We have 1400 projects which are active. With the next version upgrade, we expect more than 3000 projects that have to be migrated.

The migration itself takes months. Here is something that can be improved. It is very important for us, otherwise each migration would kill us.

I’ve been using ALM since 2004.

If you find the right patch, then it is stable. You can stay with that for years. In our situation, it takes a very long time to roll out a patch and even more time to bring a new release.

ALM is for sure scalable. We are running 1400 active projects with 15,000 users. Concurrently, we have around 1000 users. If there is a performance issue, we have to find out what the reason is. It is true, in most cases, that we need an additional database server. The application servers, if they have enough power, scale a lot.

For such an experienced team as my mine, who have been working with the product for more than ten years, it is not that easy dealing with technical support. They often do not have the knowledge that we have. It takes a while to train them so they understand what our issues are and we have to connect to second or third level support.

The collaboration between HPE and us, especially over the past ten years, has been very good. For that reason, I try to bring in more HPE products, if needed.

This is managed by Tieto, our managed service testing partner. We use ALM as a repository for our automated test scripts. This is only the very beginning of the of our testing and managed testing service journey. The reason we use ALM is it's ability to schedule tests and nightly runs. It creates reports and statistics.

We are only starting off now. I'm able to present the progress on our work with the test-information initiative. I can keep a close eye on what's going on to monitor the progress and to schedule the test runs.

I used Quality Center 5-10 years ago, and I had no issues with it. It is also the de facto industry standard of test management tools. I don’t have enough insight at this point in time. If you ask me in half a year's time, I'm sure I'll have loads more information.

We have had no stablity issues so far.

I know for a fact that it's possible to scale it up. We might add another test management tool in-house that's been there for a long time called Rec Test; a Swedish solution.

It’s a very simple test management and requirement tool. But in the long run, ALM will probably support us better, so that is on my radar to keep track of and see how we can implement them better. This will take a lot of training and convincing of end-users.

I have not used technical support myself, but Tieto is actually doing that in an effort to improve their own framework and initiate a closer relationship with HPE.

Setup was a very smoothly written, spot-on theater.

Not formally, but informally through my own experience. Our use with Rec Test, as well certainly requires more training. It requires a more structured way of working. You really need to set up a good structure, and make sure everyone is following that structure. Otherwise you'll have a mess in no time.

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.