What is our primary use case?
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.
How has it helped my organization?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I started using Quality Center ALM with version 9.2.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
How are customer service and technical support?
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.
How was the initial setup?
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.
What about the implementation team?
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.
What was our ROI?
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.
What's my experience with pricing, setup cost, and licensing?
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.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.
Which deployment model are you using for this solution?
Which version of this solution are you currently using?