OpenText UFT One Reviews

We're primarily using the solution for end-to-end regression and integration testing. We also use it for volume and performance and performance testing. It runs the entire gamut of testing. 

The solution is very useful. It offers a wide range of testing. 

We can apply testing for the entire week and test everything. You can do basic automation, which is helpful.

It is easy to set up. 

The solution is scalable.

It is stable.

The pricing is very reasonable. 

It is script-based. We'd like it to have less scripting. It might make it easier to use. 

Newer tools have a nicer user interface.

We'd like something more aligned with SAP.

Technical support could be more responsive. 

We started using the solution more than ten years ago.

The stability is good. We haven't had any problems at all. I'd rate the solution ten out of ten for reliability. 

The scalability is pretty good. We've used it over the last ten years. We can scale from one single ERP to multiple ERPs. I'd rate the scalability nine out of ten. 

The technical support we do not use too much; however, with other technical support services we've used, we find that this team takes a long time to respond back.

Neutral

We recently started using Tricentis Tosca. We've used it for about three months. It offers lesser scripting, which may be easier from an end-user perspective. It's also well aligned with SAP.

The solution was straightforward to set up. I'd rate it seven out of ten in terms of ease of setup. It wasn't too complex. 

However, I wasn't directly involved with the initial setup and cannot speak to the deployment process. 

It's the best pricing compared to other tools on the market. I'd rate it nine out of ten in terms of affordability. 

We are an end-user.

Micro Focus and SAP don't seem to have the same relationship that they had previously, so we are leaning more toward Tosca, which also has the benefit of offering less scripting. 

It's a good tool. You need to invest some time in getting it implemented. However, we are happy with it.

I'd rate the solution eight out of ten. The functionality is good. It covers the entire range of tests; however, from a business perspective, we wanted something more user-friendly.

This solution is typically used for desktop-based applications where you cannot use Selenium or other web-automation tools.

It's deployed on-premises.

There are five people in our organization who are using the solution.

It's a complete tool. The entire framework is very useful. It's easily integrable with Excel. You can do keyword-driven or data-driven frameworks easily, and you can create automation frameworks very quickly. It covers all the needs of a desktop-based application.

Integration with Jenkins and any CI/CD tool is also valuable.

It should consume less CPU, and the licensing cost could be lower.

I would rate the stability as seven out of ten.

I would rate the scalability as eight out of ten.

Setup is straightforward. It takes time, but it depends on the CPU that you have. It's a one-time effort. At maximum, you need one admin person to handle maintenance and deployment.

Implementation can be done on-house.

We have seen a return on investment.

It's a yearly subscription. There are no additional costs to the standard subscription.

My organization switched because they wanted to do the POC in the latest version, not the old version of UFT.

I would rate the solution as eight out of ten. I would recommend this solution for those who are looking into implementing it.

We use this solution for database and desktop application testing. We are customers of Micro Focus and I'm a senior software engineer. 

The stop automation is a great feature that is not generally supported by other solutions. 

I'd like to see reporting included in the solution, particularly test case-related reports.

I've been using this solution for two years. 

The solution is 70-80%  stable. Stability really depends on the servers or the license which we have installed. If the license doesn't reach the server, there's less stability.

The solution is scalable. 

The setup process was somewhere in between straightforward and complex. The vendor carried out the implementation for us; it would have been helpful to have better documentation. The solution doesn't require maintenance but when the version changes and you have to reinstall there might be some work involved. We're not using the solution on a daily basis, just when we need it.

This is a great solution and I rate it eight out of 10. 

I like the fact that you can record and play the record of your step scripts, and UFT One creates the steps for you in the code base. After that, you can alter the code, and it's more of a natural language code.  

General users can create the scripts, and you can bring in an engineer if you're struggling with one of them. It saves you money because you don't need an engineer there the whole time. You only need an engineer for your initial planning and implementation.

I would like Micro Focus to provide more information on their portal about their newer products. The information about UFT One was outdated. The image recognition features could also be better. 

We haven't experienced any stability issues so far. 

UFT One is easier to scale because you can bring in more people without a strong coding background. As long as you have a good plan, it's fairly simple to take an entire team of manual testers and have them create test scripts. It's much better than getting a whole group of engineers to set up and build the test cases.

Setting up Micro Focus UFT One is straightforward. 

UFT One's license is somewhere in the $5,000-a-year range.

I rate Micro Focus UFT One eight out of 10. if you're considering UFT Developer versus UFT One, you should consider the skills of your team. You should go with UFT One if you want to leverage more people who have testing knowledge. If you're only using the engineering team and plan on not using the business, then you can save quite a bit of money by going with UFT Developer.

We are currently using it for migration.

Micro Focus UFT One is useful. However, there is an issue with the scripts. We are going to collaborate with multiple automatic specialists to identify the problem. If we can fix the issue, we will continue with UFT, otherwise, we'll switch to other automation tools.

The high-level security, high standard and compatible SAP are great.

The solution does not have proper scripting, which impacts the solution. We are currently deciding whether we want to keep the UFT and will decide by the end of December. We paid a lot of money for the UFT, and we will only drop it as a last option.

We have been using this solution for four years. It is deployed in the client-server application with SAP.

The performance is not great, which is why we are currently conducting a review.

The solution is very scalable for a UFT. We have more than ten people using this solution.

There is a gap in technical support which is also part of our review. We've raised issues in the past, which have not been fixed in two years.

We used QTP and LoadRunner in the past.

Our deployment was completed in-house, and we have an in-house software development and architecture team. We do all our products and services and also provide services to third parties.

I rate this solution an eight out of ten. Micro Focus UFT One is outstanding. All HP processes are excellent. I used to use HP Test Director, HP QC and HP ALM. So I am confident that Micro Focus UFT One is useful.

We primarily use the solution as a front end for testing for our customers, to automate installations, for behavior testing, and for various types of API testing. We mostly use the technology on our websites, and sometimes on older technologies, such as for Oracle Forms applications.

One of the ways the product has improved our organization is that we are able to quickly get detailed information about the behavior of our applications, and we can provide this information to our customers through screenshots and additional information so that they can also easily check the reason for the defect or bug. We can work together without our customers needing special knowledge of programming. This is very important.

UFT allows us to install our applications much more easily, without our customers having to do anything. They don’t even need to click on anything. We can use UFT One to install via scripts. This eases the installation process.

The solution has allowed us to reduce test execution time. If we use it in continuous integration or in headless mode, it improves performance. Between the normal run mode with debugging, and the fast mode in Jenkins, it can reduce it by about 30 percent. That's a lot.

We can run the solution on virtual machines. This greatly affects our ability to control machine configuration and allocate appropriate resources for testing. We wouldn't be able to conduct tests or to carry out work without this solution. This is both very helpful and useful and we consider this a necessity.

The most valuable features include

• the simplicity with which the product can be maintained
• the ability to reuse its components
• the record and play
• AI

We haven't been using the AI feature for very long.

These features allow us to provide good functionality to all our customers without the overhead of maintenance costs, while at the same time allowing us to work with many customers with varying capabilities on different projects. With only a few technicians we can help a lot of customers.

Running the solution on virtual machines allows us to run tests in parallel. It reduces a lot of the time it takes to test or to do certain kinds of work. We are dealing with customers who give an API to their customers and they're using our tools in the background. As a result we must use it to scale the load for these tests. This is a very important and useful feature.

There is a lot of room for improvement when it comes to friction-free continuous testing across the software life cycle, as a local installation is required to run UFT. Most of the time, administrative rights are required which necessitate much trouble to integrate it seamlessly. When integrated, it works fine, but to maintain it in CI, special systems and privileges must be utilized. This is challenging for us.

In addition, UFT One has a Jenkins plugin that provides us the connection we need to OpenText so that we can obtain our UFT test cases. The problem is that the plugin does not come with exception handling, meaning that if we enter the wrong credentials we don’t know why it does not work. This can lead to the Jenkins server crashing.

Another issue is that we can't address the UFT output to the Jenkins console. This means that when carrying out our tests in a continuous integration server, we cannot know what the UFT tested, step-by-step.

The usability can also be improved. When we receive new versions of UFT, some of the icons are altered so that things are not recognizable to us or to the customer.

Another issue is that the application requires slow work. If you go too fast while debugging, the Step Over button may easily change to the Stop button.

The Git integration is also a point when it comes to continuous integration. There are aspects that are not recognized by Git. We cannot do a side by side comparison of changes, such as comparing the QSL side and the object repository side.

When they updated UFT from version 14 to 15, they changed the data table structure of UFT, such as the first data line turning into the column name. This is a problem as our customers may have different versions of UFT. An example would be if we wish to change the data table of version 15 but a customer has version 14, it can be problematic. This destroys the tests.

Another question we have is why everything is in read mode during the execution. With other IDEs, like Visual Studio, you can change the variables while you execute or debug something, and this is not possible in UFT. It's only in read mode, so you can’t play with variables or objects.

Also on our list is the fact that UFT allows you to work on 11 or 12 tests. If you want to change something with search and replace, you can only change it in the 11 or 12 tests that are open in the solution. But what if we have a 13th test case that is not included in the solution? We then need to open that test after we have already searched and replaced. That's a little bit inconvenient because other IDEs give you the opportunity to make those changes everywhere, in every script, not only the 11 or 12.

We have already addressed some of these issues with technical support, but not all of them have been handled. For example, we brought up the issue of the icons changing with every version some years ago and nothing has happened. It gets worse and worse from version to version.

We also have menus and instructions for our customers, but because all the screenshots become outdated with the next version, we have to do maintenance on them all the time. And it’s not because of new functionality. Most of the time, only the icon style and the design is changing and sometimes it’s the positioning that changes and we are not able to reconfigure it. We end up having to do a lot of work without any need for it.

The old VBS language can be a nuisance. It could be easier to use and it could be better integrated in continuous integration pipelines. And it could always be faster.

OpenText UFT One has been available for around two years. We have been using it since inception.

The stability is very good, except for the example I mentioned regarding the data table. Most of the time you can switch to the next version without any problems. The old features and behaviors are, in terms of the code base, the same. It’s just that you have to find the icons, asking yourself “Where is my feature?” But the stability is very good.

We use the product as often as we can. Between 50 to 100 people are using the solution. We are constantly looking for additional customers and projects so we have ongoing plans to increase usage.

The overall scalability is very good and utilizing the licensing server allows us to scale the solution as we need. One area which can be improved involves the running of instances on a single machine.

Overall, if you are able to reproduce an issue, their technical support can help you. But sometimes it can be very hard to find a technician with a high level of technical background and knowledge of the product, so that they can understand the situation, the problem, and the behavior. This can be a challenge. Sometimes we have had to escalate to get a technician with the necessary background and knowledge.

We utilized QuickTest Pro (known now as OpenText Unified Functional Testing) for between eight and 10 years.

We found the initial setup to be very easy. It is very robust and leaves no room for making errors. The availability of config files for setting up all the installations from a single master configuration is nearly perfect. The customer would have no problem simply opening the machine and using it.

As for deployment, the time can vary. Sometimes there are only minor changes and sometimes there are a lot more changes. Including tests, and to be sure it’s working in all cases, it should take no more than one business day.

It’s the same for upgrades. OpenText support has advised us that, in case of an error or a problem with upgrades, they cannot be sure whether that problem would exist on a clean installation. So we always uninstall the entire product and install it on a clean system.

We use one or two people for deployment and maintenance, in the role of test automation engineers.

Even without being able to provide exact figures, this product has given our company a return on its investment.

If you use it all the time and for different use cases then it is a good price. If you only use it one time a day for half an hour then it is pricey.

The ability of the solution to cover multiple enterprise apps, technologies, and environments is very important to us and it forms part of our company policy. It is a point we had to validate before going with this solution. The reason for this is that we must meet the technical needs of our customers, many of whom lack a technical background.

UFT One provides cross-browser and desktop application support, although the cross platform support, which is not good, is not so important to us at the moment. These capabilities are important to us because our customers are using different kinds of technologies, some that are newer, some that are very old, and all kinds that are in between. To provide a good solution, the cross-browser and cross-platform functionalities are very helpful and necessary.

UFT One gives us integration capabilities with the API and GUI components, which is very important to us since we must occasionally alternate between the two. We can use the API to make calls through scripts, so we don’t have to use the GUI for UFT One. That’s why it’s important for us to have the REST API.

We can run the solution on virtual machines. This greatly affects our ability to control machine configuration and allocate appropriate resources for testing. We wouldn't be able to conduct tests or to carry out work without this solution. This is both very helpful and useful and we consider this a necessity. We have 100 percent usage of UFT on virtual machines -- All our instances are running on them. This allows us to help the customer access his application under test. The customer can configure the system with permissions and the like. All these points are, in some cases, not possible on hardware in our company, because of political restrictions, security reasons, et cetera.

The solution has allowed us to reduce test execution time. If we use it in continuous integration or in headless mode, it improves performance. Between the normal run mode with debugging, and the fast mode in Jenkins, it can reduce it by about 30 percent. That's a lot.

Overall, it's really easy. Try it out. There is nothing one can do wrong.

The use cases for OpenText UFT One vary from one department to another. We've got so many applications within Dominion Energy, but as of now, most groups are scripting the test cases themselves, even though they're not programmers and they don't have a true understanding of Visual Basic, which is a language used to script QTP. So the groups out there are doing it independently. I think they're doing mostly a record and playback, data-driven approach, which means they parametrize the data. But they're not specifically programmers, they can't make those scripts very sophisticated. And that's what I'm seeing. So it was my suggestion that we develop a framework for them in Selenium.

I don't think that OpenText UFT One has really improved it much. Until we move over to a framework where they don't have to spend so much time in creating data-driven scripts that become obsolete once a new version of the application becomes available. It may be doing some things for them, but I think it's probably improved their overall efficiency by maybe 20%. But once they have the framework, I think they will be able to operate this framework 24/seven in unattended mode. And that's when you see 100%, 110% improvement in efficiency. So we're not there yet.

We're not using the web services testing piece. They should, but I think they're using other open source tools such as Postmaster. But they're using QTP strictly for scripting automation test cases.

In terms of what could be improved, they need to reduce the cost because it is pretty high. It's approximately $3,000 per user and if we're going to spread this throughout the organization, we'll need to spend a whole lot of money. The company can afford it, but we're going to try to promote Selenium as the open source automation tool.

All of these automation tools are a tad finicky. They tend to freeze on us once in a while and we get an 85% pass ratio every time we run them, but 15% of the time these tools will fail. And it's not the tool, it's that the browser that they're opening may freeze up when it's time to do something on an application. I haven't looked at Selenium yet. I'm going to get some exposure to it later in the year or next year. But that's the tool that I'm going to focus on and replace QTP with. Because Selenium is free of charge and it's the standard in large corporations these days.

As for what should be included in the next release, I don't know much about that because I haven't used QTP in a while. I don't know how much better Selenium is than QTP except for the fact that it's open source. But as far as the features are concerned, I was okay with using QTP back in 2007 when I used it.

Since I'm not an automation tester, I last used OpenText UFT One in 2007. But now I'm promoting it. I'm also promoting Selenium as an open source solution for future automation testing because the company can set up that framework and everybody can use it. And I'm having a meeting with the users next week on that. So we're going to be promoting Selenium over UFT.

But I have used UFT within the last 12 months.

I think it's a stable product because it's been around for well over 14, 15 years now. And I think it's stabilized QTP and UFT.

I think OpenText UFT One scales very well, but because it's not widely used... You can use one license per seat or per user who's automating it. So it doesn't need to scale, it works well enough with one single license per user. It's not meant for more than two users using the same license anyway.

Mostly developers use this product. They have a development background in Visual Basic and the use of the tool. With my current client, it's the business analysts that are doing the automation using this tool and it's not being used effectively. You have to have some form of development background, especially in Visual Basic.

I've never used it for QTP or UFT, but I know some people who are supporting this product in the client site. They're okay with it. They get a response within 24 hours.

I'd give support a nine out of 10.

I've always been familiar with QTP and UFT. The other product that's taken over the marketplace is Selenium because it is open source, free of charge. It is in 90% of all the organizations, whereas QTP I believe has lost the market share.

The initial setup for UFT is straightforward.

My advice to anyone regarding this solution is that if they have the money to purchase it, they could, but Selenium would be the first choice because it's more widely used.

UFT quite expensive. It's about $3,000 per seat, whereas Selenium is free of charge. So if you had 20 users who need to use it, you'd have to spend close to $60,000 on QTP plus annual maintenance costs. Whereas with Selenium, it's free of charge and you get all the support you need on the internet.

On a scale of one to ten, I would give OpenText UFT One a 10 because it is a reliable product, it works, it's as good or better than similar solutions especially because you get technical support from real people. Additionally, upgrades are always provided on a consistent basis. Whereas with Selenium, because it's open source, you're relying on the community to give you that technical support if you have issues and if you can't resolve them, there is really nobody to give you a patch or anything. So I think that with QTP having OpenText behind it, you've got some protection.

The price is only $3,000. I don't know how many QA analysts you would have in any given company. Probably no more than five or 10. So if it's a large corporation, it can easily afford $15,000 to $25,000. I don't see that being an issue.

UFT One is great for recording and automating test cases.

The most valuable feature is that it is fast during test execution, unlike LoadRunner.

One area for improvement is its occasional slowness.

I have been working with OpenText UFT One for a long time.

UFT One was generally stable and didn't have significant downtime or performance issues. The only notable drawback was its slower performance during certain tasks.

UFT One itself appeared to be fairly scalable, as it generally runs one test at a time. However, it can be integrated into LoadRunner for combined testing, although I haven't delved deeply into that aspect.

The installation and setup of UFT One were relatively easy. I had to install it on my computer, and the only requirement was access to a license server. Overall, it wasn't a complex installation process. The deployment took about an hour.

I would recommend UFT One to those considering its use. It is straightforward to set up, especially with the AI capabilities, although it can be slow at times. Despite the occasional slowness, it is much easier to use now compared to earlier versions and can save a significant amount of time compared to manual functional testing. Overall, I would rate the solution as a nine out of ten.