OpenText Application Quality Management Reviews

All types of data can be seen in one place.

• Real-time insight into what’s going on.
• Helps us work aligned with reality.

It's doing what it should do, but it's a little bit costly. I would like to see some kind of testing analytics.

Stability is good; no problems.

So far, we have not had any scalability problems.

I was involved in the setup. It is an out-of-the-box, simple installation. Now we're doing data migration to the database. We are just reading the manual, but more people are involved. This is a normal process.

Start slowly.

When selecting a vendor, the most important criteria for me are that they are trustworthy and nearby.

From a testing point of view, it takes us a step closer to automation. Our testing is quite manual at the moment. We can use it from start to finish; from testing business requirements right through user acceptance testing, load testing, and performance testing. That's a positive feature.

It has dramatically reduced the number of defects that go into production. There have been no serious outages, nor serious problems where we had to do a rollback or anything like that. The transition into production has been very smooth.

From a tool point of view, I would like see some integration into release management. That is the biggest pain point at this moment.

We bought this solution three years ago.

From a performance point of view, stability is very good.

ALM has not directly assisted scalability. I wouldn't say ALM assists with scalability at all.

I haven’t used technical support, but my team has. I don't know about their experience with them, but if they were not satisfied, I would have found out about it.

Don’t just focus on the technology and buying it, but rather focus on the processes behind the support of the technology. That was our biggest lesson.

It's a very good tool to use for referencing all testing components in the lifecycle of the application end to end. For example, you can include a requirement test case, feasibility of execution, and dashboard reporting for web or mobile applications.

The benefit is to track coverage of functionality, and to have a stronger application without bugs in production.

Integration with other tools would be good, for example, with open-source tools. In the meantime, we do something with JIRA, with Selenium, and so on, and it's good; but we can increase this connectivity with other tools.

For the past month, the solution has been more stable than it has been over the past 10 years. For our mobile center, for example, we started using it this year; but it's not very stable for the moment. ALM, however, is stable.

For the moment, we use it for our projects; but our testing centre is only in one location, and not for offshore. We haven’t had to scale it much.

Technical support depends; frequently, it's not very responsive in resolving our problem, but engineers handle it too late.

In the past, we used a Compuware Solution and an open source solution. We switched to ALM because tracking all activities is better when all your monitoring is on products from the same vendor.

The initial setup was okay.

The IBM solution is very hard to set up and to use. The Silk solution, which is now Micro Focus, is very strong.

With ALM, it’s simple.

Use ALM because it's simple; it has all information you need to communicate with all people involved in a project, whether they are in IT or not IT. This is the aim of the testing lifecycle.

The most important thing when choosing a vendor is that the product is user friendly and can integrate with all your old modules. It helps to have one application rather than multiple applications to connect with all the different companies.

Most valuable to us is the ability to have the system organized into distinct roles and sections. That way, we can grant different users access to the specific section they need to access. We have business users that only need to run tests, so they only need that small section of the application. We have the BA's, product trainers, who only care about the requirements.

It has made our development process more professional. The whole interim process is a lot more professional. You can align it with the development life cycles, get the developers to buy in, and try and get it all linked in to the TFS Visual Studio.

Integration is also important to us. You've got Sprinter, which is quite nice for those that aren't familiar with what they've got to do. It's a nice little guide. Also, you can link it in with performance and automation tools, and kick things off with the push of a button.

New development methodologies, such as continuous integration and kanban boards, are being implemented by Microsoft and others to try to get their tools into the testing profession. ALM's got to push back and think more about the overall end-to-end development process. It's very much still a testing tool. We have a few awkward links rather than being a full solution.HPE ALM lacks a few of these features, but for a testing focus tool, helping to ensure quality, I think it's really good. It's good at its core necessities.

It's very stable at the moment. We're not on the most recent version. We have been using version 1201 for 2 ½ years. I did the upgrade, and I found it easy for me to do, because I'd done the previous upgrade as well. The documentation from HPE isn't that great if you don't know what it means. It’s been stable, but I say that, because I did the install.

Scalability is good.

Technical support is good. We've had to get quite deep down in some incidents, so we've actually managed to get through to third level support and speak to the developers. At that point, you're both talking the same language. They can understand your issues and you get good resolution if it gets to that level.

I was not involved in the initial setup back in those days. A couple contractors did it. It was called TestDirector in those days. I'm going to have a look at the new HPE ALM Octane later.

Their licensing model is expensive. We could scale it up and use it everywhere, but then, you look at how much it would cost for the licenses and you really think, "Is it worth it?"

I was not involved with the decision process, but I did put a case together to continue using it. Our parent company was trying to push us to use Microsoft TFS. I was basically showing how much better ALM is over TFS. For what we were using it for, it's just much better than TFS. It was the testing tool of choice.

Try and have a play with it and don't be afraid to customize. We've got this big workflow in ours, so you can control the rules a lot better as to who can do what, who has access, and what they can see. Out of the box, it's a bit vanilla and there's the risk that someone could be given wrong permissions and accidentally do something they shouldn't.

It provides a central repository for all our testing artifacts and documentation. We use it not only to keep everything centrally housed, but it is also great for answering audits. That is our biggest use of this product.

Centralization of our testing artifacts is probably the biggest benefit. We have a disjointed arena with a lot of different legacy applications and new applications that are being built. We need a central house to store all our procedures, documents etc. and ALM is the tool for doing all that.

It provides a streamlined and consistent approach. One that is repeatable. In today's fast paced IT world, these things are definitely necessary.

We're starting to move more into a microservices enablement world. Using other products and being able to integrate with Docker etc. is going to be key for us. That's one of the reasons why I attended this conference, is to learn a little bit more about how HPE can help us with the integration of those tools.

We have had no stability issues. It is very reliable.

It's handling everything we've asked it to do so I don't have any issues with scalability. It could probably do 10 times more than what it's doing for us.

Other than professional services, we haven't used any technical support.

Initially, we were using other products but HPE acquired a couple of those companies. Now with the recent movement towards pushing their software out to Micro Focus that may change a little bit of the relationship we have with HPE. That's another reason why I attended the conference, is to understand a bit more about how that relationship will evolve.

It was initially setup within my organization but I didn't really have any hands-on involvement with it. Our direct teams were involved in this process. Based on the staff that we have today, it was very straightforward and very easy to do. Then again, we've got people who had experience with the tool so they've done it before.

HPE has a great suite or had a great suite in their software department and everything integrates very well. For those who are looking at HPE or now Micro Focus in terms of their software, I would advise them to consider interoperability of all the capabilities. That is the key for speed and implementation as opposed to feature functions. One of the things that we've found with the HPE suite is that the interoperability is hands-down second to none.

It's 100% reliable to us. It provides us everything we need. It's scalable, flexible, centralized and also integrates well. What more could you ask for?

The most important criteria while selecting a vendor are partnership, value, capability and flexibility. We've partnered up with HPE for years and we enjoy all those different aspects with them.

Defect Management, Test Management, MS Excel Reporting, Analysis Graphs.

Allowed us to centralize our test efforts from end to end so that we have a single source of truth for all of our test artifacts and data.

As an administrator, the ability to add users to their appropriate user groups from inside of the Site Administrator tool instead of having to log into the ALM project itself to make that user group assignment would be HUGE!

Since 1999 when the product was known as Test Director.

Just when folks forgot to check in their assets before migrating / upgrading existing projects.

Not so far, no.

Not so far, no.

Good.

Good.

Have been using a version of this solution since 1999. Have not used competing products day to day as of yet.

No.

In house.

I don't have exact figures, but we are saving time and money using this solution.

ALM is a giant library, and Performance Center and LoadRunner require it to run.

We use it to support Performance Center and it runs underneath it as one big system. The advantage is that we can test applications before they go to production, and as long as we're testing in a production-sized environment, we have a pretty good idea how an application will perform in production.

It's like the overall software framework, and Performance Center is just leveraging that framework for storing things such as tests, scripts and test results. ALM works together with LoadRunner and Performance Center as one big system. As newer protocols are developed and newer technologies come along, it's nice to see HPE be ahead of that as much as possible so that by the time that it's really needed, they're already ahead of the curve and they've got most of their performance issues resolved as far as how the software's going to run.

The stability on the old versions is good. On the newer versions, the bleeding edge is still being worked on.

It's very scalable. No issues with scalability.

Premium support is great, but before that when we just had general support, it was not all that great. We had issues with trying to get support to call us back on tickets and turnaround time on resolution.

We previously used IBM Rational.

It's not exactly straightforward. Their instructions were not all they could have been, but we still got it installed.

As far as we know, it's the best tool on the market right now. They're considered the Cadillacs of the testing tools right now. Don't necessarily go with their most recent version code release right now. It kind of depends on what your needs are and the size of computer shop that you've got.

I would say the most valuable is that we can get people started off really quickly on solutions because we've been partners with HPE for a long time and it helps us tailor the product to ours needs. When we have issues with something we can get support directly from HPE since we paid for it.

The fact that it works with a vast number of technologies works for us because our internal customers use the tool for testing a lot of different applications. That's probably the best feature that it has for us.

There's a lot of centralized testing from some perspectives and our main goal is to provide for a bunch of different groups at a lower cost so we centralize licensing and distribute it to various people. The biggest benefit of that is that it allows us to empower the people that need the solutions instead of manually having them develop the solutions on their own.

We've seen a lot of new things in Octane and other things that we have wished for. One of the hardest things that we're noticing is it might be hard to migrate from ALM to Octane, which has the features we need. What we really like is the ability to track different types of tests to our requirement. If you want to play with Selenium Test or LeanFT, UFT tests or any other framework you can think of. Being able to capture those results in a common area is the biggest thing we would be looking for because we have so many different groups that some of them have their own solutions for testing but ALM is sort of the central repository for our results so that would be a huge benefit for us.

In the past three years it's become a lot more stable. Prior to that, we saw a lot of issues with stability and a lot of patching and concern from our internal customers that they couldn't rely on the tool to always be there when they needed it. We spent a ton of time upgrading to the latest version so we don't have as much experience with the stability of it yet.

ALM has really scaled out for us. We have hundreds of projects in ALM and it's always done well with that.

A+

Our biggest issue was in the switch over from HP Inc. to HPE. I think we had some trouble getting in touch with higher level support so we spent a lot of time going through basic support where the people that work with the tools have a lot of experience with the tools. We think that it would be better if we could bypass the lowest levels of support on some issues. I can understand the process that we usually have to go through but more recently our reps have been helpful in getting us to the people that we need quicker so we can get a resolution.

We don't have time to develop a lot of reporting and our customers want a lot of reporting. It's hard to have the expertise to write the scripts in the version that we have now. That's a major pain point for us, something that's missing. Another thing is we always hear about it performance. We have a huge load balance environment to try to speed up the performance but there's always some things that are slow in ALM. Just basic navigations are running automated tests is a big thing we hear. People want to run the tests as past as possible but they feel like they're limited by ALM sometimes.

We have a pretty strong emphasis on quality, so ALM is our gold source repository for quality. That's where we store everything, from requirements, test cases, defects, and all of the artifacts around certifying that quality is evident in every release, in every STLC product we produce.

The UI is terrible in the sense that we actually use automation scripts to avoid being in the UI, which is just fascinating, and then the data model.

I would say it's stable in the fact that it's up and it works. We have challenges with the data architecture. We're excited about Octane. It has some interesting capabilities, but it's our standard. We're used to using it, so I guess it's the things you want to enhance in it, we're just working through that process from that standpoint, but relatively it works.

We're already at enterprise scale, so it's used across the enterprise. I would say that we're at that point.

We invest very heavily on having strong domain and subject matter expertise, so we use support less. One of the things I would love to have is a pay-per-ticket model or a pay-per-patch model. I think that when we call support, it's either a defect or enhancement. It's not just, "Hey, I need customer support," because we're not novice users. We're on the high end of maturity so we're pushing the products in the spaces that I have very much through limits and it's really getting on their solutions and enhancements team.

From that standpoint we get good interaction. There's a really long cycle time though. That's my only disappointing thing around the support is that tickets tend to age, because they're enhancements. Enhancements have a longer cycle, you have to develop it, get it in a backlog, etc.

I have an entire team, so I'm a director and I have an entire tools team that does that. I did get involved in the planning and the strategy of how we're going to do it. My team said that first installation is relatively easy. When we go to upgrade and migrate, that's where there's pain.

Almost every customer will say the upgrades and migrations are very painful. They could be way easier. A lot of it has to do with having to upgrade the data, the in-place database or stand up in entirety, it's just cumbersome. It's very cumbersome and it takes a long time, longer than it probably should. That's a pain point that I think everyone has. Fortunately in our case, we've never had to call professional services to do it. I have a lot of customers say they couldn't get through the upgrade without it. Now, on the support side, it was really helpful, they were on the phone our first major migration for 72 hours.

It was great to literally be in that, "Hey, we're going through it," they were there the whole time, which was really awesome. We didn't have to involve professional services, but that was a good story to say, "Hey, they're on the phone with us. They're grinding it." So the whole 72-hour period we had someone from support cycle in. They did the hand-offs and all that stuff while our team was grinding off. So that was a good story there.

I think it's a great platform. It does a lot for us, but the fact that our users don't want to be in the application is weird. They'd rather work in a spreadsheet and then upload their results to the actual server. Now it could just be their behaviour pattern, but I think if it was a little easier for them to kind of work in, they would have an easier time with it.

Although on the plus side, the fact that it's open like that and you can just connect, maybe that's a positive too. So it's kind of a plus/minus. The UI they said, "Hey, I don't really like UI," but the fact that you can just upload your stuff from your work space, which could be a spreadsheet, it could be Eclipse, it could be a script that you're working in and it just directly uploads, they love that.

When you talk about easy use from an integration standpoint, definitely high marks there, but the UI is just something they really do not like. I personally, as the person who has to get all the data and metrics out of it, the data model is horrible. It's a constant complaint that I have. The new Octane platform kind of solves that. I just wish they had put some of that into ALM because the product marketing strategy is you have to have both.

Have a well-defined process, have a strong reporting structure, meaning in your process you want a lot of measurability. If you define your output, the reports and the questions you need to answer from what you're doing, which your process should be managing for you. In our company, we are very specific about what our executives and stakeholders want.

We have a very well-defined set of measurements that we have to take. We then put a process designed to ensure those measurements are always taken. That then allows you to deal with your outputs and your reporting structure, which then allows you to properly architect your tooling. The technology is very flexible. You have to decide as a client area how you really want to use it and that's going to start with what your business needs are the values that you're trying to get out of it.

That's the biggest advice that I have, it's not even on the technology. The technology will do great things for you if you have a plan and a structure and you know what you want it to do for you. Half the time they don't know, they want the tool to do it for them and it's the other way around. So that's what I advise people to do.

Think about it, have a vision, have a plan, tie that to outcomes, and measure those outcomes. If you're answering the right questions and asking the right questions, your technology will really enable you. You've got to look at it from that standpoint.

ALM helps us keep track of all the functional testing that we do for projects before deployment and even after it goes live. We also use it for tracking future enhancements, and all the functional defects. Test requirements are maintained in ALM.

It saves time, and definitely mitigates risks in having products which are not very well built, to having a product which will perform well and function well once it goes live.

I work in a bio-pharmaceutical company, so we have lot of validated applications, and when we do functional testing for these validation applications, tracking the e-signatures is very important.

I know there are plugins to track the e-signatures, but the problem is that it's very hard to get them implemented. There's no out-of-the-box way, as far as I know, to implement track changes continuously, that comes with add-ons, and those add-ons operated by third parties as well. They are not very mature and there is a huge learning cycle in adopting them. Due to these reasons, the effectiveness of ALM for an industry like ours is less than what we would see in LoadRunner.

It has been challenging in the past, specifically when a new version is released and we have to upgrade. We haven't been upgrading that often, and because of that, it may mask some other issues which we would encounter because by the time we upgrade the new version we would have gone through some of the new patch fixes and so on. We wait for a couple of years and then apply the fixes. By that time, most of the big bugs are fixed.

It scales for our requirements but we have been finding it more and more expensive for LoadRunner. They're introducing new protocols, but they are quite scalable.

We haven't used technical support directly from HPE. We go through Avnet for all the technical support. They're a value added reseller partner of HPE.

We acquired HPE products a long time ago before I was around.

We have been using ALM and LoadRunner throughout. I can't recall having used any other solution before that. But one thing I have noticed is that there's less and less emphasis on load, scalability or performance testing, and the emphasis seems to be shifting away completely. This is feedback based on the fact that there's less emphasis on performance and load testing in these seminars as opposed to the last few years.