OpenText Application Quality Management Reviews

It is a test management tool where you write the test plan, test scripts, and test cases. You can log the defects that you found during the testing. You can also use it with other integrations, such as automation using UFT, where you execute the scripts from Micro Focus ALM Quality Center. We are using the latest version of this solution.

You can maintain your test cases and requirements. You can also log the defects in it and make the traceability metrics out of it. There are all sorts of things you can do in this.

It is not that complex to use. In terms of user experience, it is very simple to adopt. It is a good product.

The Agile methodology is now being used across all the organizations, but in this solution, we don't have a dashboard like Jira. In Jira, you can move your product backlogs from one space to another and see the progress, that is, whether a backlog is in the development stage or testing stage. Micro Focus ALM Quality Center does not have this feature. It is typically very straightforward. You just execute the test cases from it, and you just make them pass, fail, or whatever. They can also improve its integration with Jira.

The browser support needs to be improved in this because it supports only Internet Explorer as of now. It does not have support for Firefox, Chrome, Safari, or any other browser. 

There are also some performance issues in it. Let's say that you are doing the testing, and you found something and are logging the defect. When you try to attach several or multiple screenshots with the defect, it slows down, which is a very common problem people face.

I would like them to include a functionality where I am able to see the reports across all the projects. When you have multiple projects, being a manager, I would like to see the reports across all the projects. Currently, there is no single sign-on through which we can get all the information at one place. You need to log into it project-wise. If you have ten projects, you can't view the information in one dashboard.

I have been using this solution for more than 12 years.

It is a very stable product. It is a very old product.

Whenever I face any issue or require an item for automation, such as for integrating Excel support, I can get it in the resource library. It has a resource library where you can get all of the stuff.

I don't have any direct contact with Micro Focus support. For any issues that I face while using the product, we have a ticketing system in my company. I just need to log the ticket, and the right person will resolve it. They might be contacting Micro Focus.

The initial setup is pretty simple.

I would highly recommend this product because it is a very stable product. Around 70% to 80% of organizations are using this product. It is a very stable and popular product.

I would rate Micro Focus ALM Quality Center an eight out of ten.

The primary use case is test management, e.g., test executions using UFT combined with Business Process Testing. We do also requirement traceability, where we pull requirements out of a source system, then we link test cases to those requirements in order to have a coverage matrix.

It empowers us to do more testing. Our testing is being done for customers. 

The solution enables us to conduct risk-based testing. We link this solution to requirements of a certain risk factor. Once it's covered at least one time, it will show us in a report that it has been covered. Most tests are running automatically with UFT, so the check is already there in the automation, and there's no impact to us.

The Test Plan feature is the most valuable because of the test execution.

Security is covered. HTTPS works well. There is also support for LDAP over SSL. Those are the most important security features.

Within Quality Center, you have the dashboard where you can monitor your progress over different entities. You can build your own SQL query segments, and all that data is there in the system, then you can make a dashboard report. That works fine.

Managing multiple projects is possible when you have the full ALM license. However, we have the Quality Center license, which can be managed poorly. This is because you cannot look or report across projects.

We don't use Single Sign-On because this is available from version. Therefore, we do not use it right now. Also, it needs to be tested and we haven't tested it yet. With test automation. If you have Single Sign-On and want to make use of another user, that can be challenging. It is good for normal users to use Single Sign-On. However, it's not really a must at the moment, though it is good that the solution finally supports SSO.

Making Quality Center available to connect to external tools is doable, but it takes some work. With our current version, it is not fit for external entities. Connecting to external entities is easier to work with and report in using the newer versions. However, if you really want to use other tools, I would suggest giving ALM Octane a try.

The defect management module has room for improvement. E.g., for Jira tickets in defect management, they could have a direct link with Jira. However, with Micro Focus Connect, you can set up a link between Jira and Quality Center. 

Requirements management could be improved as the use is very limited. E.g., they have always stated that, "You can monitor and create requirements," but it has its limitations. That's why companies will choose another requirements management solution and import data from that source system into Quality Center. Micro Focus has also invested in an adapter between Dimensions RM and ALM via Micro Focus Connect. However, I see room for improvements in this rather outdated tool. I feel what Micro Focus did is say, "Our strategy is not to improve these parts within the tool itself, but search for supported integrations within our own tool set." This has not been helpful. 

I want to see Atlassian as part of the ALM solution. ALM Quality Center is more from a waterfall approach where Atlassian has already evolved into more of the DevOps and agile part.

I started using Quality Center ALM with version 9.2.

I just engaged with my new customer to do an upgrade. At the moment, it has been stable on all versions of Quality Center. However, I'm quite positive that will room for improvement will be needed shortly after we release the newest version of Quality Center.

Do not wait too long to upgrade. The longer you wait, the harder it gets to upgrade to the latest version with the newest features. Just like buying a car: You do not buy a car, then not go to service.

It is scalable in terms of high availability when you add an additional node because it's licensed for ALM. For Quality Center, this makes it less scalable. However, this is the perception from the vendor that the Quality Center addition is not for big enterprise. It's for a corporation, but not for an enterprise. Normally it's for bigger companies: 2000-plus users with over 1000 projects and domains. Then, they need to scale up with additional nodes, which will make it scalable enough for ALM.

It very much depends on the support engineer that you get. In the past, I've noticed that some really do not know the tool. Sometimes, I challenge first line of support or can come up with a solution faster than the support, but that's because I've also provided technical support for ALM in the past on the behalf of HPE. I know a bit more than the normal user.

Sometimes the support is very good, and sometimes it's a bit poor. E.g., if you go to the second or third of line support engineers, they really know the product. I've also worked with R&D in the past, and that goes beautifully. 

The installation is quite straightforward. Then, the implementation is based on one project, so it cannot go wrong.  This is for a very quick start. You will need more skilled people in your projects for implementation if you want reporting, traceability between requirement tests and defects, and release management. 

I always see ALM as an enterprise solution, so I don't go for the project implementation. You also need to maintain it. If one project has an issue, it may be very different in another project. There's also an issue when you have a user who is working multiple projects. E.g., where does the user have an issue? From a maintenance perspective, project implementation is not very handy so I always try to treat it as an enterprise solution, not as a project solution.

Testing time has decreased for manual execution because tests are being executed with UFT.

ROI is very difficult to say. If you don't test, you don't know how good or poor your quality is, but effective testing always costs money. However, it is very important for your return investment to know the value of your tests. What I've seen until now is that it's not being monitored that much. We have this tool because we need to test and prove the quality of the tests that we have been doing, but there will always be bugs and defects in production.

The solution has the ability to handle a large number of projects and users in an enterprise environment with the correct license.

Most vendors offer the same pricing, though some vendors offer a cheaper price for their cloud/SaaS solution versus their on-premise. However, cloud/SaaS solutions result in a loss of freedom. E.g., if you want to make a change, most of the time it needs to be validated by the vendor, then you're being charged an addition fee. Sometimes, even if you are rejected, you are charged because it's a risk to the entire environment.

With IBM Rational Quality Manager, you need to stick to the rough process and first train your end user versus ALM Quality Center's basic features, which are very easy to understand.

Make sure you have your build requirements and which features are important. Are you running projects for DevOps, agile, etc.? Also, make sure that you can evolve your tooling and not stay on the same tooling for years, knowing that your business users grow faster and have different needs.

Micro Focus does invest enough, but most investments are now going towards ALM Octane. I've seen that they are investing in adapters where you can say, "We're going to migrate from ALM.net to ALM Octane," if not entirely, then partially. There will always be projects in ALM.net, and they will keep maintaining ALM.net because there are many customers on it. Customers do need to realize that IT is changing and that you need to modernize as well.

I would rate this solution as an eight (out of 10), though I would rate it less for DevOp/agile.

We use it as a test management tool where our requirements and everything we need are entered into it and we manage the test cycles. When new products come out, the requirements are gathered and captured. Based on that, the test scripts or test cases are created and uploaded. Eventually, the functional analysts or testers run different test cycles, such as integration, user interface, and user acceptance test cycles. We log the defects with it as well. Based on the metrics, if a product qualifies, it is moved to the next cycle.

We have seen multiple improvements using this solution. One example is that one of our customers wanted to see the defect numbers in the same grid where test execution happens. We were able to provide that. Whenever a defect was raised for a particular test, the defect number updated automatically in an integrated, single view. That meant we could see the status of that step. If it failed, we could see that the defect number had been assigned to that particular step.

We also have a custom tool that we have created to disconnect a user. Sometimes, a user may lock the test scripts and go for a coffee. Usually, a system administrator would have to be there to disconnect that. But we created a solution where test managers or test leads have an option to use the username and kill the session so that other users can log in and start working. This is one  of the best-practices we have implemented so that the time involved in test execution will be reduced. There are a lot of dollar savings when executing each cycle.

Overall, it has absolutely reduced the time it takes to do testing. Initially it might be very difficult for the users to execute and then update the test script status and the defects. But after two or three days, they are used to the navigation and it can save a lot of time. If we were using Excel or doing things manually, they would need to store the details and pass them on via shared drives. That approach would also make consolidation very difficult and a person would have to collect data to create a report. ALM is an integrated tool from which we can get reports.

The most valuable feature is the Test Lab, when compared to any other tool.

With test execution, you have an option to create custom fields. It is also really user-friendly. With other tools, we only have restricted fields and we cannot customize or add new columns or fields that users can make use of while testing. ALM is very flexible for creating new fields. It is easy for users to understand the application.

It is also pretty easy when managing multiple projects. We can actually create the domains in the tool, and under the domains we can create a project. Based on that, we can manage things very well without any confusion for the users. They can log in based on the domains and select their respective projects. Most of the equivalent test management tools don't have that option.

The solution is also really secure. It will only open within our network. And in the next version it has access roles and a single sign-on feature where users don't need to log in physically with their usernames and passwords. It automatically takes the authentication and goes. That is a very good feature because we can log in to the laptop and it goes automatically, making it very secure. Because in our version, 12.55, we don't have SSO enabled, we are doing a PoC of version 15, which has this feature.

We cannot rearrange the Grid in the Test Lab. It is in alphabetical order right now. But sometimes a user will want to see, for example, the X column next to the B column. If they came out with that it would be useful for us. They are working on that, as we have raised that request with Micro Focus. They have not given any definite dates, as there are multiple requests from different companies, but they are working on it. We have 14 or 15 of our own columns. So every time they want to validate details of, say, SAP security or something along those lines, they need to drag to the right. They wouldn't need to do that if there were an option to reshuffle and save the view.

I would also like to see them provide a better reporting structure. They have a Business Views Microsoft Excel Add-in that appears as an additional tab in MS Excel. If they could improve that a little more, integrating it better with Excel, it would be very useful for all the stakeholders, helping them see the reports.

I have been using Micro Focus ALM Quality Center for the last six years.

It's very reliable. It is a mature application. It's very rare that there is a crash.

The scalability is very good. 

We use it for most of the projects in our organization, with the exception being small projects. Currently, there are no plans for increasing usage.

Their technical support is very helpful. They provide support 24/7 and they have resolved whatever issues have come up, on time.

I was not involved in the initial setup, but I have been here for six or seven releases, new versions, and their installations. It is a straightforward process. It is not that complex, but we have needed the assistance of Micro Focus at times.

We have dedicated staff for deployment and maintenance of this solution. There are seven of us in the company working with Quality Center. One is a technical admin leader who takes care of Quality Center, and another is a project leader. Under them are project support people who work in shifts, 24/7, and create projects and provide support for users' technical issues.

Pricing is not my area, but in general, what I've seen when reading articles is that it is costly. That is the reason most customers are moving to the other solutions, which are much cheaper. That is the opinion of people I have spoken to in other companies.

Quality Center is a mature test management tool, which is used across the industry and, for the Waterfall model, it is the best solution. JIRA is good for Agile testing. Micro Focus has released Octane, but it is costly compared to other solutions, so companies are not opting for it. JIRA has a low licensing cost.

I've worked with multiple tools, when it comes to a Waterfall model of testing, and ALM is the best tool.

The solution enables us to conduct risk based testing but, as a test manager, that kind of testing is only done when there is not enough time for testing the entire solution. That is when we go through the requirements in the ALM Requirements module and see what the most important requirements are that should be tested. Based on that, we mark it as risk-based testing. We create a column and check it as "yes" or "no". Based on that information, it can be filtered and the same test cases will be handed to the Test Lab for testing. That means that the most critical functionality of the solution will be covered. The solution helps segregate, using the requirements, to test scripts.

Micro Focus is investing in the product. It is really good that they are investing in it and that they are releasing new releases. The newest release, currently, is 15, where there are multiple new features. It is useful for our users and, as a company, enterprise-wise, that they further improve the solution.

We started an SAP implementation about four years ago and it was selected as the test management tool at the time.

Prior to us using Micro Focus for this program, my company had been using a lot of manual testing. So we had to reproduce or find scripts over and over again. Quality Center enables us to have a single library where people can reference back as we go through multiple releases. We are able to bring non-SAP systems into the fold as well and increase their productivity as related to testing and compliance.

Having used the tool before, I like the use of parameters, being able to do exports and reports of the data for monitoring of executions, and the defect management as well. I feel satisfaction in that area.

It's really customizable, so I don't know if we're using it well enough, but with the way requirements are managed, there's no inherent workflow or statusing native to the application. Reviewed and not reviewed is the standard. I would like to see the ability to manage the requirements a little bit better.

There were multiple modules to the solution so the requirements can map to test scripts but it can't map to test steps. If you've got a process that's set up and you've got multiple test scripts that are in it, each script has to be linked to the requirement and the whole set can't be. If we're doing process-driven testing, it's more difficult to do it at the script level, which is what we're finding from a traceability perspective.

Having a way to connect requirements to test steps would be helpful.

I have been using Micro Focus ALM Quality Center for four years. 

The stability is very good. We haven't really had any major issues. We do have to go through the VPN just the way we have it set up in our network because we are using it within our network and not on the cloud.

Sometimes when we're in through the VPN, it runs a little bit slower, but I think that's just how all the networks connect. I don't think it's the tool.

It has huge scalability. It's been used for multiple applications that we support from large SAP programs to a smaller system. It can be used as a single release. One of the bigger issues is the licensing approach. They have concurrent usage and it's very expensive. They should offer - and we've asked and they've said no - an enterprise-type license where you're not paying every time you want to bring more people into the solution that you know you're going to go over your license count.

We have to buy more licenses and more maintenance. If we could have at one point an enterprise-type tiered license, that would be more appropriate to be able to scale it up even more. People are moving to DevOps for a little bit more of an Agile approach, as well as that it's free versus the cost of an ALM.

At the peak of the project, we had about 300 people using the license as concurrent users. We had everywhere from testers in India and people offering scripts and executing testing. We also have our business folks doing UAT and our technical teams doing our functional testing. Then we have obviously our quality organization going in and verifying the results. We also have our developers utilizing it for defect resolution. So during testing, a defect can be identified, and then we have a separate type of license that's only for the defect module that the developers go in and they can find a cause and put notes against it. There's the test management team and really the whole program at that point.

We have a light maintenance agreement with Micro Focus for the application, but it's primarily for our e-signature capability because that was custom code and we really haven't had any tickets against it, maybe once a year. And we have a certain amount of hours that were allotted. We actually use that for enhancements to our workflows, they help us build that out. We haven't really had any direct needs to go back to Micro Focus for support.

It's a quick turnaround. They have remote access to our environment, they've changed over points of contact on who our support person is seamlessly over the years. They notify us. They let us know and they send us monthly reports on any activity that usually is zeros for them. But when we have needed them, it's a quick turnaround. We've been satisfied.

I've worked with HP Quality Center at a prior job.

I wasn't involved with it when it was first implemented for the program. I've worked on it in past companies, but it was forced to fit into meeting minimum requirements. So now, we're actually in the process of evaluating best practice and integrations with other tools such as Solution Manager and ServiceNow.

We haven't calculated ROI but the time it would take to go through paper documentation versus digital is huge. I don't have any quantitative numbers on that. We also were able to enable automated testing using Micro Focuses UFT, which writes back to ALM for results. The time it takes to execute in itself has a return as well, but the time value is really on the UFT. The write back to ALM and to be able to document results in a single location is key.

Depending on the volume, the annual maintenance costs vary on a percentage but it's around $300 a year per license for maintenance. It's at 18% of the total cost of the license.

Make sure you have an ALM administrator, both technical as well as at the project level or at the application level available to support creating templates, doing a lot of the backend technical work administrative. If things do get blocked, you can push things through. So you do need two technical experts on staff to support the application.

The biggest lesson I have learned is that proper training and governance is not really the tool itself. It's how you use it. They pushed it in to satisfy a minimum goal. We utilized Parameters in our test scripts, but the testers then don't utilize them properly and then there's no governance that forces them to do it. Having the structure to support the application the way it's intended is really key.

I would rate it an eight (out of ten). Obviously there's always room for improvement, but it's an overall good tool.

We are using it for test management. We have distributed teams in three locations with one location in Portland, which is the newest, and also in India. We have a team of around 150 people (developers plus three testers). We are implementing an order migration legacy system to a new system based on AngularJS 5.0. We also have test automation being implemented on this account using Micro Focus UFT. 

Automation is triggered through ALM. We have the test scripts stored in ALM that are triggered through the execution dashboard. Also, the reports are available on the dashboard. 

We do defect management through ALM, which is the typical use case. The defects are raised in our different locations, then the collaboration between the development leads and testers happen through ALM.

We use the Test Plan module where we have test cases related to all our different releases up until now with a few current releases as well. We use the Test Lab tab to pull test cases from Test Plan and do executions accordingly. We have also created some smoke and sanity testing suites where we pull test cases, then execute them when required during the project phases.

Any user who accesses a project gets to know what is the latest status on a test case, from a test case writing or test design perspective as well as test execution perspective. Collaboration is very strong. The communication that the tool sends out along with the log which is maintained is locked in the history. This is for any change at the test case level or within any of the components of ALM. The history helps us to understand what went wrong or when has somebody made a change. Therefore, the history log is a very important feature.

From a collaboration perspective, I can send out emails directly from ALM that, at times, get triggered automatically. If you raise a defect, then it automatically triggers to a particular email ID that the defect has been logged in ALM. This helps to get immediate visibility or attention of the development team from a testing team's perspective.

Initially, we used to lose a lot of time in collaboration. If we do this in a very crude way through Microsoft Excel, then there would be a lot of issues related to version control. Like somebody might say, "I've fixed the defect," and the other guy would say, "It is still open." Now, across the team, we have one single source of truth because ALM helps the whole team to understand the exact status.

Ease of use is definitely one of the strongest points for ALM. It's a very user-friendly tool and the maturity of processes within ALM are amazing compared to other tools. Their in-built reporting does help with getting ready-made reports from the tool. 

The Test Plan and Test Lab setup helps us a lot when pulling test cases repeatedly from a different perspective. If I want to make a sanity pack, then I can pull test cases from that same library of test cases. I don't have to create them again or copy and paste them. 

I love linking/associating the requirements to a test case. That's where I get to know my requirement coverage, which helps a lot at a practical level. So, we use the traceability and visibility features a lot. This helps us to understand if there are any requirements not linked to any test case, thus not getting tested at all. That missing link is always very visible, which helps us to create our requirement traceability matrix and maintain it in a dynamic way. Even with changing requirements, we can keep on changing or updating the tool.

We use the dashboard and have created our own reports. The typical dashboard also helps us a lot to understand test execution progress and the percentage of open defects from a defect perspective. We use the defect aging reports a lot. This saves us lot of time and gives us the right input from the perspective of which defects are aging. Those need to be looked at again and possibly discussed in further detail in the defect triage call about what's the blocker to get them fixed and how we can work in a better way to avoid the defect aging in these manners. 

The vendor is still investing in the product and releasing valuable features. For example, there has been improvements in the overall folder structure. Initially, we just used to have Test Plans and Test Lab. Now, we have the Task Board.

Sometimes I do run my queries from the admin login. However, if I want to reassess all my test cases, then I am still doing this in a manual manner. I write SQL queries, then fire them off. Therefore, a library of those SQL queries would help. If we could have a typical SQL query to change the parameters within test cases, then this is one aspect I can still think that could be included in ALM. Though they would need to be analyzed and used in a very knowledgeable way.

About four years.

It's very stable. We haven't had issues with any sort of stability issues, e.g., no downtime.

We have around 4,000 test cases in ALM, so I don't think scalability is an issue.

We have around 150 users. The hierarchy of ALM users is:

• The admin
• Process leads, who are using it.
• At the lowest level, there are data developers and data testers who access ALM.

70% of our people use ALM and the other 30% don't need to be on ALM.

The technical support is nice. At times, we have needed to wait. However, this is understandable for a few of the issues as they sometimes can be tricky. I would rate the support function as above average. 

The turnaround time varies with the issue, but they're decent enough. The average time is two days. They provide us local support.

I have always used different versions of ALM. I did not previously use a different solution before using ALM.

The initial setup was pretty straightforward. The process was just about our customization, which we do from our end and is admin guided. This took us around a couple of weeks and wasn't cumbersome at all. ALM is a mature product. We could set up how we wanted to upload our test cases, then structure the different parameters or columns the way we wanted them. The process was quite streamlined.

We did have some internal help, but we didn't have a full-time consultant. We didn't have any external help. We used a team of three people (part-time consultants).

We definitely feel that it has given us a huge advantage from a collaboration and time savings perspective.

It can reduce the wastage that happens in collaboration activities. The effort has definitely gone down. Effort and collaboration have been reduced by 60 percent.

It all comes down to how many people are going to access the tool. When teams go above 20, I think ALM is a better tool to use from a collaboration and streamlining perspective.

At a process level, the maturity within ALM is at the highest level. Now, if I have run the same test case five times within Test Plan, it will gives me a status of that test case based on the last run, whether it passed, failed, or its situation. If I want to know right now from a functionality perspective what functionalities are working for me and which are not, then based on the immediate last run done directly through Test Plan, I can understand that. That's one of its strengths. This is not available in other tools, like TestLink and Jira (we are using both).

Jira has an advantage from agile perspective. For an agile project, it helps to have the dashboard in the way Jira is structured.That's where Jira is pretty useful. We also have three of the defect calls running different ways using Jira. There are a few things from a visual perspective where Jira poses some advantages over in ALM.

TestLink is pretty similar to ALM. It is not really drastically different. It's open source and doesn't have the kind of maturity which ALM has, like the BI page, the history log, or other functions that are present in ALM. It doesn't have that type of strength. However, since it's open source, at times a couple of our clients use it, but I use it very rarely within our projects.

Security is driven by the different user login credentials that are created by the admin. This is pretty typical. In this aspect, all their tools are good.

For risk-based testing, I used to have a different version of ALM that gave me a confidence level. Currently, I don't think our company has bought the version where you implement risk-based testing. However, it does help me to get the required inputs from the tool. Then, I have my own way of going about risk based testing.

I have seen the Single Sign-On. It's nice, but we don't use it in our current project due to a few constraints and a few user experience related issues. Sometimes, people don't want to change and just want to do it the old way. That is why we stopped using it.

I would rate the solution as a nine (out of 10) to keep pushing them to include more features.

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.