OpenText UFT Developer Reviews

Our primary use at this time is mainly to automate testing of Windows and web-based GUIs.

The recording feature is quite good as it helps us to find out how things are working. 

There is quite a bit of room for improvement. As time has gone on the product has failed to improve. Basically, Micro Focus' UFT (Unified Functional Testing) was a good product 15 years ago when it was first introduced. They have not really made substantial changes to it since then — which they should have done to make the product more useful and competitive. The gap between it and the competition has shown in the product's lack of development.

To improve the product they could better integrate the API and the GUI testing. At the moment, when you run the GUI testing, you run it in Visual Basic Script — which is a very old Microsoft product that Microsoft no longer supports. For the API testing, you have to write your tests in C# or C++. If you write a functional library for one test process, you can not use the same library with another test. A further problem is that even if you have a functional library written in VBScript, you can not use it for multiple projects. You have to make a copy of the library for each project that you use it with. Then, of course, every time you make a change, you have to replicate the change manually through the different projects and that is a real pain.

A new feature that I would like to see is better integration between the API and the GUI testing so that you could use the same libraries and the same scripting languages and so forth. That is a major missing piece because of their lack of effort in development over time.

The stability of the product is adequate.

When it comes to scalability we never had the opportunity to run UFT in parallel with multiple platforms, so I don't know that the product hits the mark at this point for the type of scalability we would want to test.

We did actually contact the technical support for an issue once. The support was actually quite good. But, honestly, that is what I would expect for a product at this price point.

Micro Focus UFT is an okay solution for specific purposes that we use it for. I also use Katalon Studio and, since Katalon Studios is Java and Groovy-based, it is much better and more up-to-date for testing.

The initial setup was reasonably straightforward. I have no issues there. I don't remember exactly because it was a long time ago, but the setup was not excessively long. It was just like any basic software installation.

We didn't need to use a reseller or a consultant for the implementation. We did it on our own.

As far as comparing to other products, the licensing costs for UFT are very high. I don't remember the cost exactly. The maintenance of the service contract was very high as well and, frankly — compared with more modern tools — it was and is not worth it.

A good thing is that there are not any costs in addition to standard licensing fees, but the standard licensing fees are going to be high in comparison to other products so you don't gain anything.

My advice for those considering this product as a solution is that they should look closely at alternative products to make a good comparison of features, capabilities, and cost. At the moment we are also using a product called Katalon Studio, which is freeware and it does pretty much everything that we want it to do.

The biggest lesson I've learned from using UFT is to compare solutions. I would go so far as to say that even if UFT were free, I would still prefer Katalon Studio.

On a scale from one to ten where ten is the best, I would rate UFT Pro as only a five now. I would rate it so low because over the last 10 or 15 years this product, which was a superior solution at one point, has not really been developed to its capacity.

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.

LeanFT could support additional technologies because we use it for a lot more than just web and Java and some Windows apps. Further support for other technologies would be nice. I can't rattle any off the top of my head but ones that we use internally.

We don't scale it out on as large of a basis as ALM.

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.

I'd say to set it up it's pretty easy. Defining a standardized way that everyone could use it is a little bit harder. It's a very complex tool, there's a lot of ways to use it so I don't know if it's a limitation of the tool per say as just a common industry problem. I wouldn't say that there's anything that made it hard to get to the customers and to start utilizing it.

It's newer so it doesn't support as many technologies which makes the investment a little bit harder for us to absorb more licenses than we currently have or to justify buying any more licenses than we currently have because it only supports a certain subset of our customers.

LeanFT is used a lot more by our less experienced testers and developers who want to get more point-and-click type automation. Then obviously I also manage the automation team, so we use UFT for a ton of all of our XLC automation as well as anything with a UI. So we also bring it into our business functions as well. If we need to do clean-up, data entry, management of manual tasks where you're putting yourself in a UI scenario, we'll run scripts for that for productivity.

We pretty much use that to streamline workflow and enable productivity in a business context in our business unit as well as in our IT shop, so just reducing workload on IT people as well as testing. It's used pretty extensively beyond that.

I'd like to not have to use Selenium. I'd like to be able to do headless scripting and not just always be UI serving.

It's stable.

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

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.

We're still trying to get the adoption on that for the user community. It's very usable though. I rate adoption pretty high, so when people are using it, for instance, UFT, I'd definitely give that a ten because we use that a lot. I'd like to see some enhancements in the product, and we're working with HPE on that.

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.

We use both the on-premises and cloud deployment models of this solution. The testing tool needs to connect to the real environment and that almost always means on-premises. However, you can also use a cloud variant, but then you're working on virtual machines in the cloud.

The most valuable feature for me is the number of protocols that can be tested. It not only tests Web, but also SAP, Siebel, .Net, and even pdf. That's a strong point of this tool because open source tools like Selenium can run only one protocol, like Web, for example. A lot of legacy systems do not use Web as their front end, however. They use a Windows-built .Net application or something else that is not web-enabled.

It's now too heavy and they should be making it faster. We do an attempt at automatic regression testing. We schedule a test to start at a certain time. It takes a lot of time to download the resources and start UFT. Competitors in this area have tools that start faster and run the test faster. For example, if the test at our side will take 10 minutes, another tool will do that in one minute.

I would like to see them add a feature that tells you if you can run parallel sessions in it. If it were a lot faster than the Chrome version that would be a major win.

The product itself is a stable tool when running on a stable machine. However, a lot of things can influence the stability of the tool. Windows updates can have an influence on the stability of the product. Virus scanner local policies can have an influence on the stability of the product.

It's a single run, so that means that you cannot usually use it multiple times in one session.

The problem is that when you run this through a development tool you must be an actual developer to program the script language. Normally there are other script languages for example, .Net or Java. When you have Java development name, then this tool would normally not fit into it because it has another language. It chooses another language, so that would be complicated for developers to use it. And the problem is that sometimes the programming language it too complex for just help us to make scripts.

The reason we chose this solution is because it is the company-wide chosen solution. It integrates with other tools, such as ALM, a test management tool. We are also going to move up to Octane, but Octane also integrates with UFT. Octane also introduces the possibility of connecting to other tools via Jenkins or Bamboo. The main connection with most ports will be UFT, though. If you look at other tools that are compatible in the market, such as IBM or smaller, open-source tools, they will fit for us, but they have the issue that they only work with one protocol. They only work with Web. If you have complex protocols, then you are forced to use the commercial solutions. IBM or another one that's based on another technique would then also work.

For me the setup is simple but I think that when you have to do it for the first time, you have a lot of choices which you can make. Then it would be complex, but I think that with the knowledge that I have it is easy. I can do the installation of such a tool in 30 minutes. It can also be set up in collaboration with other tools, but then you have to set some environment settings before you can do that. If you do not know that, then you will need to search for that information before you have the answer. That's some knowledge that you have to be aware of.

Testing is much more complicated than presented by the provider. They make it look like it's easy, but that's not the case. There is a lot of work put into it and you must also maintain the scripts. Sometimes people think that you don't have to maintain it, but scripts will not update themselves. There is no artificial intelligence in these kinds of tools.

For example, if you have a login page and you get an update then you also have to update your script. This is because it used an object repository where it put in some objects to verify it. When objects change, the script won't run or at least it will fail. There are already tools that have a functionality that can update the object repository that it uses because it sees similarities in the tests that would normally run. The tool sees an update to objects and it can interpret that as a correct version of the tests that should run.

I would rate UFT overall as seven out of ten.

Basically, before LeanFT was introduced by HPE, I was looking at a solution similar to Selenium to integrate some scenarios that UFT was doing well for us; we had to look for other solutions with LeanFT-like leverage. The most important thing about LeanFT is that it gives us the opportunity to introduce developer testing. Initially, because UFT was VBScript based and because of the infrastructure, developers wanted to contribute toward testing, but could not, so they used VBScript and went to eLanguages, which they can use with their development like Java or C#.

They can use the same language that they're using for their unit testing, so they can contribute to that in the very beginning of the lifecycle instead of after the application has been fully developed, at which point it is tested and comments are made on the features.

That is the main aspect: we can put the developer into the testing scenario.

Initially, although they developed some in-house tools, we were looking for a third party to lower the speed provided. With LeanFT, we are trying to create a kind of hybrid infrastructure where we can use our existing scripting and in the same infrastructure we can use LeanFT.

I think the one thing we're basically asking for should be JavaScript support, but I think they will start adding JavaScript support in the future. We haven't moved into that; we’re still into LeanFT. We're still finding out what's in there. Once we know what we can really do in LeanFT, then I think we can start providing feedback regarding enhancements we want to see in the solution.

LeanFT is very new to us (we started six months ago). We are still in the process of using it and converting our scripts with it. That means we still need to see all of the built-in capabilities, but it is getting better and better.

Obviously, we are planning to scale in the future because with LeanFT via the service pack, we can do user checking with continuous integration tools, which was initially not possible with the UFT, so we are trying to convert as many scripts from UFT to LeanFT. It will give us the most flexibility with more ways of working with the CPU.

Technical support has been good so far. Sometimes it takes minutes, sometimes they take more time, but most of the time they're good.

We are doing a lot of testing and there are some scenarios where UFT does not fit into the scenario. Since then, we have been looking for a solution. Initially, we were looking at an open-source solution such as Selenium or some third-party tool to learn. We also wrote some of in-house processes, but they are not getting combined with ALM into the single repository, so we are looking for a sub-solution. We kept telling HP that we needed a solution; otherwise, we had to move from UFT and ALM. Ultimately, they told they came up with LeanFT and you can use it with either Eclipse or Visual Studio code.

I won't say initial setup was complex, but it was not clear how to setup because there was an issue with the licensing. The same licensing was not working with UFT that used to work before, but we got in touch with HP customer support, they got back to us and since then it has been very smooth sailing.

It depends on whether you already have a testing tool that is based on a different infrastructure, such as UFT or Selenium. Then, see how smooth the transition will be. However, to start from scratch, start with LeanFT as opposed to another solution because it can give you the power of managing your tests in ALM and the single repository so you don't have to worry about it. Once you install it, it is kind of the best tech with web-based infrastructure, so you don't have to worry about quality control and so on.

I believe the main feature for using it is the flexibility across different platforms. For example, I can use it whether it's Eclipse using any of the programming languages. The multi-platform usage of LeanFT is really useful.

It's still in the early days, but still I see that we'll move over to it fore the effort savings once the LeanFT roadmap comes into place.

It needs to be able to be used on Chrome, Firefox, and other browsers on Macs and not just Safari. That's a very key requirement for my organization.

It's very scalable. Given the power that it provides in terms of any programming language and any development platform you can use it on, such as Eclipse or any ID platform. So definitely it's more scalable but still there will be room for improvement in terms of the Mac browsers compatibility/support.

We hardly have incidents. There hasn't been much activity as compared to UFT. We will see how it goes in the future.

The complexity was pretty much okay, it's acceptable, so that was good. Once you implement the infrastructure within the organization, the complexity is pretty much similar to any other automation tool.

We didn't actually choose it. Our customers provide LeanFT, so we started using it.

We're still early on with our use but there are a lot of good things that have been promised. Those results have to be realized now. What has been told so far as well as the roadmap which I have been told should come into place pretty quickly.

I like the tool because we can still access the devices' distance. It's not important where you're working. For example, I can use it in Brazil, Chile, and other parts where people are working. After the pandemic, many companies use it for homework. I think using it to administer and manage the devices is very good and effective.

Stability depends on the company's infrastructure and end-to-end infrastructure. When I used the tool in my project, we had a big problem with many users using it simultaneously.

I have been working with the product for three years. 

I rate OpenText UFT Developer an eight out of ten. I recommend it, but you must prepare the environment and infrastructure before applying the tool. You need to scan with user growth in mind. We needed to set up the environment to use it.

We are an IT-based company. We have our own product. I am primarily using Micro Focus UFT Developer for SAP applications such as SAP ECC and SAP HANA.

It is quite stable, and it has got very user-friendly features, which are important in terms of maintaining our scripts from a long-term perspective. It is very stable for desktop-based, UI-based, and mobile applications. Object repositories and other features are also quite good.

UFT Developer is good, but it requires high-level development skills. Scripting is something that everybody should know to be able to work with this product. Currently, it is very development intensive, and you need to know various scripting languages. It would be good if the development effort could be cut short, and it can be scriptless like Tosca. It will help in more adoption because not every team has people with a software engineering background. If it is scriptless, the analysts who wear multiple hats and come from different backgrounds can also use it in a friendly manner.

It is also quite expensive.

I have been using this solution for ten years.

It is quite stable.

It is quite scalable. It can be used for multiple applications. It doesn't only cater to SAP applications. It can also be used for UI-based applications and mobile applications.

We have started with five developer licenses, and we are planning to have more licenses in place for more application automation.

It is deployed directly on my desktop. 

Its cost is a bit high. From the licensing perspective, I am using a concurrent license. It is not a seed license. It is something that I can use in our network. It can also be used by other users. 

It is a great tool. It is not really rocket science. Once you learn it, you can easily adopt it.

I would rate Micro Focus UFT Developer an eight out of ten.