OpenText Application Quality Management Reviews

I'm the admin for our organization's Quality Center. I define the guidelines and projects for use. We use also use it for management requirement testing. Though, we are not doing automated tests or defect management right now. 

We can't use the Quality Center for everything because the login is only about the user ID and password. Because of this, we are not using the data in Quality Center for all projects.

It is quite complicated because I have about 200 projects, mostly SAP, and all of them have to work in the same way. I do a lot of reporting and everything has to be more or less the same.

I love to use this solution with single projects. It has helped our productivity. With the metrics that I receive, I can put them onto the management model so I can see them there. It has reduced our time for project management and controls by 20 percent.

We do a risk-based testing in some parts of tests, especially because the applications are very big so they can't test everything. The control of incidents is normally very good, as they don't want critical defects when we do this.

The requirements are the best thing.

The management feature is very important. I also use requirements, tests, and defects.

While I'm using a lot of the business reports, these are very complicated.

It is hard to find the traceability from a defect to a requirement. Sometimes, it is very hard to find the evidence in an executed test case. While it's possible, it could be easier. Only these two things have to be improved: the tracking from a defect to requirement and the evidence of testing.

Quality Center's ability to connect all the different projects to reflect status and progress is quite complicated. We may develop something because there are so many projects. Right now, I have to do something which Quality Center is really not designed for: over reporting. This is a very big problem right now. We may develop some controls, but it is problem at the moment. I love Quality Center for individual projects to work with it. However, if you have a lot of projects for Quality Manager to do cross reporting on many projects, then it's almost impossible. It takes a lot of time. 

I have used it for 10 years.

With my current company, I started to set up their solution two and a half years ago. It has taken that long to get the solution working because it is a big project.

The stability is okay.

All users have to report their projects in Quality Center. Previously, it was voluntary to use Quality Center. From September, everybody has to use it in the company.

We have 300 users currently utilizing the solution. This number should increase to 500 or 600 going forward.

I don't work with the support of the Quality Center.

I haven't had a lot of contact with Micro Focus to know what they are doing.

Previously, we had no application lifecycle management tool, so there was a lack of coordination about requirements and no traceability regarding which requirements had been tested. Sometimes, defects were being reported by email. Now, everything works well, which is a huge improvement for my company.

It is very intuitive and wasn't complex for me. I like to work with it, but there are a lot of new users, and it's very complex for them to understand using Quality Center in the beginning.

We jumped right in and didn't have an implementation strategy.

We had a lot of problems with the new installation.

The implementation team was all internal: two other people and myself.

I started with the testing. Then, after the launch, I was working with the requirements and defects. Therefore, the deployment was a step-by-step process for quite a long time.

Pricing is managed by our headquarters. I am able to get from them for very cheap. The market price is horribly expensive.

I have seen other applications, and I like this application more. We tried SHIELD, Xray, and Confluence. I have also looked at another solution which was more about integrity. However, I am more concerned about requirements management. Other solutions working with integrity and enterprise architect can be very complicated. Though, SHIELD, as a solution, is too simple.

Very quickly, you can work with the solution. Though, there are user in my company in which this solution seems very complex. I would recommend that users take the courses offered to them. In addition to getting the manual, reading, and learning it, users have to try the solution, e.g., I create a playground for them to try out the solution for a few hours. Here they can try out the requirements and play with it. 

If you think logically and practically when using the solution, it works fine.

From the start, visualize the application. The initial tree on how to start is very important.

We would like to implement Single Sign-On, but there is a problem with it in my company. All different solutions have to be signed on individually in our company. Right now, we are trying to work with Oktana, but Oktana won't go into production in our company if there isn't a possibility of another login.

In the last release, there was nothing really new nor useful.

I would rate this solution as an eight (out of 10).

We used it for multiple platforms in our organization. The IT platform was divided into groups, into towers, and each tower was using it. I used it for multiple towers together. I was managing it for my individual tower. But if there was a roll-out of the regression plan and we needed to see how many would be impacted, we were pulling out the ALM regression part from each and every tower and building it into one.

It's an effective test management tool. When you have to map all the requirements, and need requirement traceability, it reduces test management time. Compared to managing testing in Excel, it reduces it by 50 percent.

Reporting was the main thing because, at my level, I was looking for a picture of exactly what the coverage was, which areas were tested, and where the gaps were. The reporting also allowed me to see test planning and test cases across the landscape.

I was managing multiple landscapes. We were adding requirements in ALM itself and then mapping those requirements across the landscape. If one requirement was distributed across a project, it was mapped with ALM so that we could trace this particular requirement and see what projects were impacted and what test cases were tested regarding it. ALM provided complete traceability.

In terms of the solution's security features and compliance, I didn't come across any concerns. I checked the ALM SaaS version for the project I'm working on in my current organization as well, and I haven't felt there are any security concerns regarding ALM.

I used ALM Quality Center in roles from test manager to test director and it was the best tool in each role. It was easy to handle, and we could map everything, starting from requirements, and see everything with the test reports. It's a tool for everyone, and one which is very easy for everyone to adopt. Creating test plans, doing test setup, and set up of folders was very easy. The tool was quite flexible. It might take a maximum of one day to set up a whole project. 

I never faced any issues in integrating this test management tool with other tools for test automation. I worked with UFT and another in-house tool as well. We were able to manage and we were able to connect the applications very easily. The auto-run options were pretty good.

When it came to JIRA and Agile adoption, that was not really easy to do with ALM. I tried, but I was not able to do much on that. So for Agile, I've never used it and I'm not sure how good it is. There is room for improvement in the way it connects to and handles Agile projects. When I was trying to manage both Agile and projects with ALM, I had to pick up my defects and reinsert them in ALM. There was no integration that I was able to find for that, although that was about a year ago.

I have used Micro Focus ALM Quality Center for seven to eight years.

The stability is quite good. Their upgrades are quite good. There are formal updates. I was happy with that.

It was utilized, effectively, across the landscape, across our technologies, and across projects. It was widely used.

My previous company was a pretty big organization and had 200 to 300 users of the solution. It was purely for the technical teams, for people like architects, testers, project managers, and test managers. We distributed it with the access required by each. The defect managers and architects only had traceability. The testing teams had full access. Test manager had planning and reporting access.

When you have to ramp up your licenses and you have to scale it up, it's quite a costly product. You have to keep an eye on how many people are using it. You can't just give access to users who are only there to take on excess work and who are not using it. It is not a very economical solution.

At that time, I was also looking at JIRA, participating in a comparison between ALM and JIRA. What I was looking at was how effective JIRA is for test management versus ALM.

We use it for defect management and for test cases. We synchronize it with JIRA for the requirements and the defects side of things.

We're also using it for our UFT script repositories, but that is more than likely going to change, in the next couple of months, as we go across to GitLab. It's just simpler to have all the artifacts for a particular iteration in one place.

Quality Center is cloud-based with a local client.

The way Quality Center improves our organization is with the traceability and through standardardization. It's about having the test cases all in one place. That's very important for us. It will be even more important once we revive the regression suite in the coming months. It's extremely important to have one source of truth.

It definitely helps in standardizing our testing process and, if utilized properly, it will streamline it because everyone is using the same standards and capabilities. It has helped with that in the past and will in the future as well.

Quality Center also assists with risk-based testing. You can put risk ratings on test cases as you go, and if you do that you know which ones need to be run, for sure. It doesn't have very much smarts around it though, it's just a field that we fill out. It doesn't utilize AI, which some of the tools in the market are purporting they can utilize to determine which test cases need to be run. But I think it's very early days for that yet and I'm exceptionally skeptical about it.

The automated scripts give us management control.

Defects are widely used within our organization. 

We've had a little bit of a hiatus on the test-case side of things, because we decentralized the testing team, but that's about to be re-centralized. The test-case repository and linkage through to regression requirements will absolutely be a key component for us. We haven't got it yet, but when we've got an enterprise regression suite, that will be a key deliverable for them. We will be able to have all of the regression suite in one place, linked to the right requirements.

Also, its traceability and visibility features are good when it comes to managing multiple projects, which is how we've got it set up. The reporting was a little bit clunky to start with, but we've built some reporting out of it now as well, to give us a cross-portfolio view of those projects that are using ALM. Each project can do its own thing, to a certain degree. There are some standard fields that we don't bend on, so that we can get the correct reporting out.

There's no problem at all with its ability to handle a large number of projects and users in an enterprise environment. We only ever have up to 60 concurrent users, but the number of users we've got in the database is in excess of 250. We manage it reasonably well, that way. Project-wise, we've got about 40 to 50 projects in there.

The security features are good. They will be better once we get the single sign-on capability with ADFS on ALM 15. We're very keen to get that capability up. We're looking at the implementation process for single sign-on right now. It should be okay. It makes things a lot more convenient for us, particularly as we have a number of contracts users come in. When they go, we've got to manually remove them from ALM at the moment, because it's got its own authentication. Because it's in the cloud, anyone can get to it directly from anywhere. They don't have to come through our network to get to it. That is good in some regards. But it does give me some concerns when people have departed, or when organizations that we've been working with have finished up with it, because we have a separate swipe that we've got to do to remove any users who are no longer working with us.

There's room for improvement on the reporting side of things and the scheduling, in general, is a bit clunky. 

They can also improve on its interoperability with other tools. All tool sets need to evolve in that regard. They need to understand that you don't buy all one color of tool sets these days and that some tools do a job better than others, depending on what it is. If I've got an industry-strength configuration management tool and repository, like GitLab, I'll pull my stuff out of ALM and I'll interface with GitLab from ALM. That interoperability with other tools sets, the standardizing of interfaces, is an area to work on. All of the tools in the industry are the same. You get a new version of JIRA and it no longer works with the likes of ALM, or you get a new version of IBM UrbanCode Deploy and it doesn't work properly and you've got to do a configuration with GitHub or Artifactory or even ALM, for that matter.

The other thing that ALM could do well with is to move away from Internet Explorer. I believe they're doing that with version 15.

I go back to Test Director days, Test Director 8. That was around 20 years ago.

The stability has been fine. If ever we do have problems we're straight on the phone to our customer success manager and he gets onto any issue that we've got, immediately. But it very rarely goes down.

We only use whatever our concurrent is. We run very lean at the bank, very lean. That goes with all of our tooling. We have a concurrent licensing model that is well under the maximum number of users. If we find that we haven't got enough licenses we adjust the time-out so that people are not holding onto licenses unduly.

With Quality Center, for user scalability all we do is get extra licenses. We've never hit any sort of limit on the size of the project.

We've got a number of admin users, a few site admin users; there's one per domain in our model at the moment. They are the super-users who look after everybody within their domain. Within projects, it's up to the different projects or squads to work out whether they need what we call TD admin users in there. There are also defect-owner users. We also have some analyst users and some tester users.

We'll be increasing usage because we've just kicked off our transformation program with a third-party. As a part of the agreement they are using it, so we'll be upping the number of users that we have. And by reestablishing the centralized testing thing, we'll also be ensuring that Quality Center or ALM is used as our tool of choice. We will reestablish the standards that somehow were dropped when we went to Agile.

They coordinate it for us but I do have direct access to the tech support guys. Typically, if there's an issue, I'll get on the phone and notify our customer success manager. Either we will already have raised a ticket or he'll raise one for us. Then we'll work through anything that we need to do to get things fixed so we're up and running as quickly as possible. 

There have been some issues around getting any major problem that we've had resolved, although we've had very few major issues. It's just a matter of keeping at it until it's fixed. Having that CSM in place allows that to happen.

Before Quality Center the only thing we were using was JIRA. We interface with JIRA. Some teams want to use it for defect tracking. We keep JIRA and ALM in sync using the synchronizer tool that comes standard with it.

JIRA and ALM have different strengths. JIRA and Confluence do Agile planning and management well, and ALM does defect management and test case management and reporting well.

The fact that we've got it in the cloud at the moment, as software as a service, enables us to keep up to date. If it's a back-end or a server-only change, it just gets done. That's the beauty of the arrangement we have with a SaaS or cloud-based version. 

We started using the cloud-based version about four years ago. The setup was very easy and very quick. I did the migration. We had to unload the databases on-premise and FTP them across to the cloud overnight. We did it project-by-project or by groups of projects. Each one of them had its own backup/transmit/reload. They then went through a series of validations and were up and running the next day.

I did it on a project-by-project basis because there was a lot of data that had to go across and be uploaded to the cloud. Once it was up there, I logged on, checked it, and then got the SMEs from the different projects to validate that everything they needed was there.

Having to package up and coordinate clients is, occasionally, difficult, but that's just a project management issue: scheduling things at the right time. Sometimes we have problems and we have to go in and individually blow away components for the product for the client. That's more because of our setup, our configuration on our network, than it is the tool set. We do that with most tools. Occasionally have to rebuild when we've had version upgrades, but not for everybody.

For maintenance there's only two of us, myself and one of the guys that works for me.

As an end-user, of course I'm going to say that it's too expensive and I want things cheaper, but don't we all?

Aside from the standard licensing fee there are no additional costs. It's set up with a good agreement that runs three-yearly.

Do your homework on it to really understand how it works. I've worked at a number of different organizations that have had Quality Center, Test Director, and ALM. They have all been set up differently. I'm also guilty of having gone in as an external contractor and setting it up the way that I want it to run too. But if the time is taken to set it up properly, you will get strong value from it.

The biggest lesson I've learned from using Quality Center is that, when it's used well, it's an exceptionally powerful tool. When you use all the features of it, when you have things that are standardized and locked, it's a really handy tool in governance around testing and projects. But in an environment where you've got multiple external contractors or vendors coming in, where they all tend to bring their own way of doing things, it's good that it's flexible enough to accommodate that, but at the same time it leaves you with a bit of a mess to clean up afterwards.

It's really about making sure when you do implement it that you understand your process, you understand your workflows, you understand the standards that and the reporting that you want out of it, and you set it up accordingly. If somebody comes in and says, "Oh, I want to know what my defect aging is," you can say, "Well, here's the report that does that," if everything's filled out properly.

I've seen it set up really well in a couple of places, and it was really good to have it set up well because we could get the information out of it when we needed it and we could ensure that things were tested properly.

When it comes to connecting all related entities to reflect project status and progress, we have to do a little bit of tweaking, but we can customize it. We can always do better with the cross-project reporting. But the biggest issue we have is that we need to re-centralize testing to get the standards enforced. At the moment, since we've moved out and become very Agile, we've become very lax as well in being able to keep the likes of test cases — in particular regression suites — up to date. That is one of our reasons for reestablishing a centralized testing team. It's nothing to do with the product. It's just that everybody decided, "Hey, Agile's the way to go," and a lot of people with Agile thought, "Oh, we don't have the formality and the structure and standards around testing," which was not good.

At the moment we're in a bit of a state of flux because we've had the whole Agile movement start to hit us. Unfortunately, that meant that there was a decision to decentralized testing and put it out into the different Agile squads, which in turn meant that there was no standard way of doing things. Now that we're engaging in a transformation program, we need to re-establish that standard way of doing things, because we're working with third-party vendors. We're centralizing, ensuring that things are handed over in the format that we want, ensuring that the third-parties are utilizing ALM as the tool set for their test case repositories, and as the defect management tool as well. Being an industry-wide, and understood, standard tool, it's very easy for us to go to our partners and say, "You've got to use ALM because that's what we're using." We are still going to be Agile, but we'll be doing centralized testing.

I wouldn't say Quality Center has reduced the time required for testing. It's a tool. It supports our testing process. It gives the governance and standards around the testing that's done, but as a tool it doesn't reduce the time for testing. Something like automated testing will reduce the time for testing. However, by association, I suppose it might reduce testing time because it's where we execute our automated scripts from.

We haven't found that Micro Focus is still investing so much in Quality Center and releasing valuable features. They did do a big push to go towards Octane and we trialed that. Because we have multiple best-of-breed tools in the organization, Octane could plug-and-play with a lot of them, but then it became an overhead to be able to manage and maintain. 

With ALM in Australia at least, there's enough support and development going on. I know the APIs into ALM have improved, and they needed to because aspects were pretty clunky. Now that we've got a REST API that we can use, that's a lot better. So they're sort of keeping up.

I would rate Quality Center at about eight out of 10, but I have a testing background. I'm very stingy when it comes to rating things. I don't think I've ever rated anything to 10.

We use it for recording our requirements. We use it for recording our test cases and the data is done within the ALM itself. And, during execution, we use it to update services and to log defects.

The solution reduces testing time, although not in all cases. But it is capable and in some cases, like for web testing, where we are easily able to capture screenshots and videos within the ALM workflow itself, or the test execution steps, it really saves us time. Otherwise, the guys have to keep on capturing screenshots into a file. Here, they can upload  everything in one shot. In that aspect, we have seen some savings in execution and, while they are not that drastic, it does help.

When it comes to the test planning cycle, if I have my regression cases, they could be almost 40 percent of the cases and they are repeated. So instead of uploading them again, I can easily replicate them in ALM. That is one way I am able to save and I would estimate that saves around 25 to 30 percent. The other part is when it comes to the execution steps. The savings are not so drastic but they could be between 5 and 10 percent.

The best thing is that you can see your current status in real time. Our people are deployed mainly offshore, and we have some guys working onsite as well. We have close coordination of the teams using calls. To see real-time updates, you just log in to ALM and you can see exactly what the progress is. You can also see if the plan for the day is being executed properly, and it's all tracked. From the management side, I find those features very valuable.

The ability to connect all related entities and to reflect project status and progress is the main thing that, as a manager, you are able to see: progress in real time. If the guys are updating the status in real time, meaning that as soon as they finish execution they update the status, it is really helpful.

If you ask the testing guys what is most valuable, for them it's like a one-stop, central location for every project, where every artifact and everything else is recorded. It is a single point where you can store everything. It's very easy to track and escalate. The solution does a lot of things which will support you in your project delivery phase.

When it comes to managing multiple projects, as long as everybody is actually recording all the requirements in the Requirements module of the tool, and from there the test cases and test plans — if everybody is doing that — it is really helpful. When we look at the status, we can actually map it to the requirements and we can see which of the requirements have been completed end-to-end, what we're spending, and so on. However, one thing we see is that not everybody uses the Requirements module to log the requirements. For certain projects, people just start using ALM from the time they upload the test cases, during test planning. In such cases, I am not able to see all the information. But for the projects where ALM is being used end-to-end, it is really helpful. The tool itself is really good. It all depends on how you are using it.

In terms of the solution’s ability to handle a large number of projects and users in an enterprise environment, I am sure the solution is capable. Our current usage here is not so large. But I previously worked in companies where around 300 users were using ALM for everything. In that setting, it was a central location where we could see all the results in real time. Here, I handle around six or seven projects simultaneously. But I have seen people who are handling up to 30 or 35 projects simultaneously, all using ALM. I've seen other organizations where people use it completely, for all their projects. There may be different managers, but it is a single location where everything can be tracked. It is scalable and it is pretty user-friendly as well.

In ALM, when you start to execute something, you can record and capture screenshots and videos. Once the team was trained in those features, I could see that they started recording and that they were doing the execution. When they close the last test, the recording is attached automatically. The tool is capable and, again, it comes down to how people are using it. If they are using it in the right way, we are able to capture everything.

ALM only works on Internet Explorer. It doesn't work on any other browser. In my opinion, Internet Explorer is generally a bit slower. I would like to see it work on Chrome or on other browsers. We have other applications that work perfectly fine with Chrome. It is not a major problem, but browser compatibility is an issue. And if you're using a Mac, it doesn't work.

We have a digital platform and we have done a lot of automation using Selenium there. Those tools have the ability to work in Chrome. But I am not able to integrate ALM completely, end-to-end. For example, using the automation tools we have to initiate test execution from ALM and then take all the results and upload them back. So I'm not able to work end-to-end because of the browser compatibility issues.

The majority of our guys are working on Windows and they have IE. For manual execution, I've never seen a problem. But when it comes to automation, I have an issue.

We've been using Micro Focus ALM Quality Center for about eight years. Our company has been around for almost 11 years. Out of that, for about eight years we've been using HP QC, now known as ALM. We've been using it continuously throughout that time.

I just recently returned to this team. When we started the testing phases here, I was leading the team. I moved out and I just joined it again three months ago. When I left, we were on version 11 so we must be on 12.55 now.

The solution is on the cloud, it is not on our premises.

It is pretty stable. I don't think we have seen any issue. The availability is always 99.999 and it has never been down unless there is a planned outage. 

In the last two years, we have seen issues for two or three hours, but that is the maximum we have seen. 

When there is a planned outage they always notify us in advance. Otherwise, the application is always available. Our guys work in multiple shifts. They work throughout the day and they work at night as well and it's always available.

If we request any kind of support, they are always there to help. They are very good.

Before ALM, we were only using Excel. But along with ALM right now, we also have some projects that are using JIRA, and there are some people who are using Confluence. The digital teams here are using JIRA.

The initial setup was pretty straightforward. We had engineers come in and they gave us training and showed us what we would be doing. They were very supportive, from the customer onboarding perspective. They did a very good job. Initially, there was all this complexity. We didn't know how to manage it because it was very new to the team. They came and trained us very well. To put it simply, the onboarding process was amazing. We have monthly sessions with their team and we have continuous contact. It's pretty organized.

They started the planning two months ahead. Everything happened in a proper, planned way. That is something I really like about Micro Focus. The initial installation took almost two months. In part, that was because of internal problems. We were using Excel and some other tools. To migrate from there to ALM took some time. That included moving the data. We had to make sure that whatever data we had was not lost and that even the number of test cases was the same as what we had before.

Upgrades happen in a single day, or sometimes two to three days.

In terms of the implementation, it happened a long time ago. They first asked us for a timeline and they then held multiple sessions on the features and the abilities of the tool, with multiple teams over the course of two to three weeks. After that they came and deployed ALM itself and tested the compatibility with our machines, because we had some desktops and laptops. That took some time. Micro Focus gave us an installer that we had to push to all our machines. Once all the machines were updated with the installer, we started using it.

We have definitely seen return on our investment in Micro Focus. Imagine the amount of hours that our guys would be spending tracking stuff in Excel. If you look at the number of man-days that my team would have to spend on that and at the licensing costs, of course it is worth it. I'm very happy with it.

The pricing has been the same for the past few years. It is reasonable. It is not very high. Of course, the cheaper the better, from our point of view. But the tool and its quality are amazing, really good. And including the support their team is giving us, I think the price is justified. It's a fair price.

We did not evaluate other tools at that time. My manager and I — we came from different organizations — had both been using HP. I was using HP QC 9.0 when I moved here. When we started off our testing stream, the only tool that came to mind was HP. In addition, HP was one of the vendors that was being used for testing other stuff in our company.

Even now, we are not looking at other tools. 

It's all about the mindset. ALM has a lot of features. We, ourselves, are only using about 30 percent of the features. If you are expecting that when you start deploying ALM you'll be using everything it has, that's not the case. Of course the tool has all the features, but there are some customizations that can be done based on your needs, and the Micro Focus team will be able to help you with that. It's all about setting expectations and telling them exactly what you want.

Initially, we were not sure what we wanted to see. But after some time we understood that there are so many features. For example, the reporting part: ALM has automated reports but they require some things to be entered at first. If your team has the skill to set up your own stuff, that's good. If not, the Micro Focus team can support you. ALM can automate reports so that, at the end of the day, it sends out an email so your team doesn't actually have to prepare all that information and send it.

To make full use of ALM you have to invest some of your time. It has a lot of features. Most people will just use the basic stuff and they will be happy with it. But if you start exploring it, you will find it has a lot of capabilities. And they are all included in the licensing cost. Don't just go with the flow and keep doing what you're doing. Spend some time and ask ALM the right questions and they'll be able to help you. You will get more benefit out of the tool. That is one thing I have learned in using the solution.

Micro Focus is still investing in the product and releasing valuable features. We have been asked to upgrade our version so that means they are working on upgrading features and are fixing bugs. In previous versions, I was seeing that things were a bit slower. It took time to actually load. But now, my team is saying that it is fine.

In terms of security, ALM has controlled access. Every user has his own login and password. We restrict access. There is one admin on our team and he's the guy who controls who accesses our systems. Before we create a user ID for someone, they have to go through a review process. We need to understand which team he is working for and for how long he will need access. In that way, we keep things in control. As for uploading our data, I don't think anybody will be able to access it. It's pretty secure.

Right now we have 35 licenses for 35 concurrent users. But the number of actual users is around 400. It's being used by our testing guys as well as business people and even our senior management. If they want to see reports in real time, they log in and see them. From that perspective, it is really helping us.

We don't have many people involved in maintaining it. I don't have a dedicated person on our side to manage it. Micro Focus manages everything. I have one point of contact and she takes care of everything.

For me and for our organization, it's a really good product. I'm really happy with it. It's a 10 out of 10. It meets my needs completely.

We are from a Vodafone department that manages testing and quality. We brought this tool in to assist us. We are constantly using it. 95 percent of projects are running on it.

We mostly use this solution on our laptop devices.

It is helping with our delivery, testing, and quality processing. It links all our test cases with defects. Users from across the globe can comment on a defect or add attach artifacts to the defect cycle. ALM adds control with its integration.

We use it for visibility on multiple projects. We categorize all our deliveries into different domains and projects. Recently, we had a call with the technical team and they suggested to split our project into multiple domains and projects since this account is not that big. We hardly have six to seven projects running in parallel so we manage with one domain and one project, and all other projects are archived. We decided the way forward would be to split one project into multiple domains. This way, if in future something goes wrong, other projects will not get impacted if there is a problem with a project.

The solution’s ability to connect all related entities to reflect project status and progress is good. Right now, individual users are logging in with Single Sign-On and uploading their test cases. Performance usability is fine.

We have never experienced any security issues.

We can get an entire project into a single repository where we can view all the data in detail. This is where we keep all our test cases where everyone can reference them. This provides everyone access to the test cases and artifacts via the cloud. There is no need to contact anyone. It is the same with defects. It uses a common forum for tracking the defects and centralizing discussions.

Test Lab: This is where we keep all the test cases and mapping of all the defects. It's also for storing of all the artifacts.

Defect management: This is a good feature and fulfills all our requirements. We use it for user and role management. Only the admins can see all the users' details.

We use the application's Single Sign-On feature. The usability is good. There are no access performance issues. It is easily understood, even for new users. 

It takes time because it has a 360 view of all the processes when talking about test case, design, and defects. There are so many things to track. Therefore, if I try to inject Micro Focus ALM into a small agile, delivery project, there is resistance. If there is resistance, is there flexibility for customization based on project scale? I don't know if this is possible.

Also, it adds time when I upload and execute all my test cases to Micro Focus ALM. For example, when I prepare test cases, I need to run them individually, then upload them to my sheet. After 10 days, I might have finished all my testing after tracking everything in Excel. Moving to ALM at this point adds time and overhead. It increases my testing timeline, e.g., if my testing takes eight days, when I add on time for ALM, the testing time is now 10 days.

The version of Micro Focus ALM that we use only works through Internet Explorer (IE). We have to communicate to everyone that they can only use IE with the solution. This is a big limitation. We should be free to use any type of browser or operating system. We have customers and partners who are unable to log into the system and enter their defects because they work on a different operating system.

From 2011, we have been using Test Director, which became HP ALM, and finally Micro Focus ALM Quality Center.

We haven't seen any issues when working with multiple projects. Maybe once a year, we have an issue with stability.

When this solution was upgraded to version 12.55, we saw some performance issues. We raised this as an incident. The team has worked on this and provided us with results. We have seen performance issues which may not be related to ALM, such as latency in the data or remote working conditions. These are issues that we are raising to the Micro Focus team though.

We have experienced some scalability issues. I would rate the scalability as an eight to nine out of 10.

We have about 50 to 60 users logging into the solution.

I would rate our Qatar technical support as 10 out of 10. Our technical support person is always available to help us. We are very thankful for the service and support. The communication is excellent. However, when we have an issue, e.g., an application is not working, having error, or we are raising a ticket, it takes time to resolve. This should be improved.

When we were installing for the first time, it was not simple. We could not just go to the URL and install. There were some initial installations problems with IE where we have to add the URL and make it a trust site. This had to be done by an admin, which takes times. I would like to see this improved. 

After the installation, we didn't have any problems with deployment or integration into our environment.

We can open this solution by URL and access the application where it runs to the server. We do have a restriction when installing infrastructure applications. We have to ask our IT to have our admin install it.

Admins should not need to directly install objects into the application. This should be done directly into the server or cloud.

We don't do any maintenance. The solution is SaaS and managed by the Micro Focus team.

The solution has saved time with background activities and helped my delivery to move forward. However, this application is a support function into our delivery.

Compared to the market, the price is high.

We just renewed our licenses, which took time to do. I think we have 30 concurrent licenses. 

The world is changing to open source code and free applications. This may be an issue in the future.

In one of our agile projects that was going into a sprint, we recently started using Jira (about a year ago). This was for a small delivery project whose team felt more comfortable using it. For example, if a tester raises a defect in ALM, there are many fields, including those that we have customized. It takes time to raise a defect, then close it. Since it takes time, the project team decided Jira is quicker and also open source. On the other hand, they agree that Micro Focus ALM is better overall, e.g., in the way, it keeps information and provides reports. Because the team didn't need a lot of information as part of their delivery, they went with Jira.

We are happy. It is a good product. We have benefited from the tool and recommend it. We have received very good feedback regarding its use. From a user perspective, the ability to create test cases and manage defects is excellent.

We are planning to integrate automation with Micro Focus ALM. This is in development. 

We are doing risk-based testing using manual generation of the script, then uploading it.

To use the flexibility feature from a requirement to my test cases and get the benefit of traceability per the SDLC process, I would need to keep and map all my requirements. It is on the user whether they are using this feature or not. While I know this feature is there, we are currently not using it. We are manually managing traceability. We are preparing and keeping all our test cases in Excel. When the test cases have built up, we are manually mapping them based on our requirements.

We are not currently using mapping test cases. This is a feature of ALM that would allow us to map our requirements, solutions, and everything the test misses. We had a call with the Micro Focus technical team regarding this and about how we can use other features. 

We primarily use the solution for test management.

The dashboard reporting is great.

It offers very good defect management, test planning, and execution. 

It's been stable so far. 

The product can scale. 

I'm looking at more towards something more from a DevOps perspective. For example, how to pull the DevOps ecosystem into the Micro Focus ALM. You have other different tools in the market which have more towards DevOps capabilities, like integration with pipelines, et cetera. I need more of that within Micro Focus ALM basically.

We could have higher quality technical support.

I've been using the solution for 15 years. 

We haven't had any issues with stability. It's reliable. The performance is good. There aren't any bugs or glitches, and it doesn't crash or freeze. 

We have found the product to be scalable. 

We have between 7,000 and 8,000 users right now. 

The technical support is average. We aren't unhappy with them. However, we don't find them to be exceptional. The quality of the response could be better. It's the first level of response that's the issue. They don't dig deep. They might read your something or ask questions unrelated to the underlying issues. They need people with good product knowledge even at level one support.

We've only ever used this solution. We did not use anything else previously. 

We have four admins that can maintain the product.

The initial setup is complex in terms of understanding everything and building up the infrastructure required for deploying it. Setting up all the infrastructure from the servers to the database, to load balancers can be difficult. Many things are there. It takes a good amount of knowledge actually to deploy it correctly.

Initially, the implementation was done by Micro Focus. After that, the four admins take of upgrading, et cetera. The initial implementation was done many years ago by Micro Focus, and thereafter it's all the admins who take care of everything else.

I don't handle any aspect of the pricing. 

I'm both a consultant and a user. I'm a Micro Focus partner.

It's all about what you need. If you really want to deploy a good test management tool, which gives benefits and helps you manage everything, and you're really serious about test management and application management, then go for it. If you just want a tool that takes care of something from testing an ALM, you're not as serious and likely don't need this. 

I'd rate the solution seven out of ten. 

I primarily use ALM Quality Center as a conversion tool.

Previously, we stored our test cases and results in Excel sheets, which was difficult to manage. Implementing ALM Quality Center has allowed us to map our requirements with test cases and use cases properly.

ALM Quality Center's best features are the test lab, requirement tab, and report dashboard.

ALM Quality Center could be improved with more techniques to manage Agile processes. In the next release, I would like a time management feature to be included.

I've been using ALM Quality Center for two-and-a-half years.

ALM Quality Center is stable.

ALM Quality Center is scalable.

Micro Focus's technical support is functional and responsive.

I previously used Microsoft Azure.

The initial setup was a little complex in terms of setting up the database. Deployment took between forty-five minutes and an hour.

We used a third-party team.

ALM Quality Center is a little bit costly.

Compared to JIRA and other solutions, ALM Quality Center is better for large-scale projects. I would rate ALM Quality Center four out of ten.

When I use it, it is mostly for test management. The instances I've used are mostly on-prem.

It is a tool, and it works. It has got good linkage and good traceability between the test cases and the defects. It has got lots of features for testing.

It can be quite clunky, and it can easily be configured badly, which I've seen in a couple of places. If it is configured badly, it can be very hard to use. It is not so easy to integrate with other products. I've not used Micro Focus in a proper CI/CD pipeline, and I haven't managed to get that working because that has not been my focus. So, I find it hard. I've often lost the information because it had committed badly. It doesn't commit very well sometimes, but that might have to do with the sites that I was working at and the way they had configured it.  

The feature that I would have liked to see is more integration into CI/CD pipeline and agile pipeline. It should have integration with third-party tools such as Jira, DevOps, and the cross-platform type of thing. The versions I've used are older, so these features may have already been included in the new versions.

I have been using this solution for 10 to 12 years.

I've had many cases where I've lost data. I had bugs where I couldn't record, and the records got lost or locked, but rather than the actual product, it had more to do with the way it was set up at the sites I was working at.

It is scalable. I've seen big organizations using it.

I've not had to deal with technical support.

I also use Microsoft Azure DevOps. I don't really have a preference. It is horses for courses, and it depends on the type of application you're running. For older style waterfall projects, you can probably go with Micro Focus, barring pricing and others things. For agile or particularly a Microsoft Azure-based product, I would go with DevOps because of the better pipeline and the whole end-to-end integration.

I never had to set it up from scratch.

I've never been in the procurement process for it. I don't think it is cheap. Some of the features can be quite expensive.

Generally, it is pretty good for what it does. As a standalone tool for managing testing, it is good.

I would give Micro Focus ALM Quality Center an eight out of 10.