OpenText UFT One Reviews

We are working with a desktop-based application and we use the solution to automate testing of the application.

UFT One has helped us to reduce testing timelines. Earlier, during our manual testing days, it would take 15 days to certify a release, but with UFT One and automation, we are able to achieve that within five days. That's how important it is. It also improves the quality of our testing.

We have also seen an improvement in test coverage, going from 80 percent to over 90 percent.

In addition, it helps in identifying defects earlier. With manual testing, that 15-day timeline meant there were times when we would find defects on the 11th or 12th day of the cycle, but with automation we are able to run the complete suite within a day and we are able to find the failures. It helps us to provide early feedback.

There are a few limitations when it comes to automating desktop-based application testing. You need a medium to run the test cases. We used to run it as a test suite. OpenText provides that in terms of a test management tool as ALM, but when we think of integrating with a distributed version control system, like Jenkins, there isn't much integration available. That means we need to make use of external solutions to make it work. We have other apps which help us to integrate all the tests into a dashboard. So one area for improvement would be to allow us to run that test suite.

We would also like to see improvement when it comes to generating reports.

OpenText UFT One is the latest edition, but I have been using UFT for four years.

UFT One provides pretty good stability.

Scalability isn't really applicable to us because we have 10 virtual machines and UFT is installed in all of them. Jenkins is what takes care of the scalability, based on the workload. It allocates the jobs to any number of servers that are available.

I don't know how many people are using UFT One in our company, but on our team we have 15 people working with it. They are testers and automation engineers.

Plans to increase usage depend on the new initiatives that are coming up. For about a year and a half we have been using UFT on 15 virtual machines, to its full potential. There are plans to increase its usage, because there are new projects coming up and we intend to deploy UFT on them.

If there are issues, when we reach out to the support team, they are able to assist us. It may be something like we were running an older version and there was a new deployment that created this kind of issue. But the support team is always able to assist us. I would rate their technical support at nine out of 10 or even a 10.

We didn't have a previous solution. We were looking for a solution where, once the elements of the object repository are created they stay there. Also, when there are changes to the application, how quickly would it be able to transition as a result? We were mainly looking for object identification and consistency of the tool.

There aren't many tools on the market for automating desktop application testing, but one of them is OpenText UFT. We tried UFT and it seemed to be suitable, so we started using it for automation testing. It suited our requirements for desktop application testing.

We tried TestComplete, but I was not part of the team when the decision was made to go with UFT One.

Everyone has their own requirements, but based on my experience with UFT, I have found it to be very consistent. If anyone is looking to automate web-based or mobile-based applications, UFT is very good. My advice would be to try it and explore UFT a lot.

Using it, we have learned how to design our framework and how to adapt it to improve our test suite. We have learned how to write effective test cases and how to improve the usability of the functions that we add.

AI is kind of exciting but, at the same time, it's not available for desktop-based applications yet. So we are waiting to make use of AI. In general, AI helps to reduce testing time. It increases the amount of reusability and it also makes the tester's life easier by asking them to identify the objects and differentiate them. In addition, it helps to identify any elements that could be missed by the human eye. Those are the features that we think will be helpful for us, once they are available for desktop application testing.

I've found the most valuable feature to be the ease of object identification using the products spy tool.

As with any test automation tool, the ability to run repeatable tests unattended during off hours saves lots of manual testing hours.

I would like to see IDE improvements (collapsible code, being able to open multiple test files simultaneously, having stack trace information). Some of these IDE features have been addressed in the more recent versions.

The solution works for the most part, but the IDE is horrible (although I hear version 12 has a revamped IDE and is much better) and as a result of VBScript being the language, there is no stack trace information available so debugging some errors is not an easy task.

I would like to also see support for other languages than just VBS. Java, Full VB, C#, etc.

I've used it for three years.

The application will occasionally crash or be unable to reach the License Server which causes test suites to fail.

The tech support is pretty good. Compared to Micro Focus’s SilkTest, it is much better. Although I haven’t used SilkTest in about 5 years so it may have improved.

I was not involved in the evaluation of this product. I inherited it.

I don’t really have information on the pricing/licensing as I wasn’t involved in that and wouldn’t be able to comment on the ROI. This solution has been in place for about five years and the tests are pretty reliable so I would think it has a pretty good ROI, but just guessing.

This solution probably wouldn't be my first choice. I have used Silk Test and Selenium. Selenium would probably be my first choice due to the high ROI, reliability, being able to have a IDE choice and support of multiple languages.

Its ease-of-use. It doesn’t take long to train staff on it. We use a third-party to develop the scripts for us, and they find it easy to up-skill staff to use UFT.

We use it mainly for regression and it's very useful for that. We reduce a lot of stats around cost savings in the regression packs that we run.

Cost is one area where there is room for improvement. We have to start looking at a leaner team and moving into using the Selenium scripts. We have a lot of areas using Selenium, as well, within the bank. I'm trying to get out of using it, only just for regression, as well.

We don’t have any stability issues at the moment. Some of the issues that we've had really would be around browsers and browser compatibility. But that's mainly to do with in-house issues, because the industry that I'm in can be a bit slow to adapt new browsers and new software. It's more the way that it interacts with that, than the application itself that causes stability problems.

We have 12 licenses at the moment. Cost is one factor that pushes us to use another tool as well.

I would have been involved in the initial setup when it was originally installed. It was too long ago. It was originally QTP. That was a good few years ago. I used to look after the licensing, and the license servers, and all that kind of stuff and that's fine. It is very, very simple. The new licensing model is a lot easier.

Our environment is web-based, with over 2000 pages. There is no such thing as a primary use case since it is such a large and easily modifiable product. We have more than 1700 test cases already.

UFT has improved our ability to regression test. This frees up the test team to work on only the new portions of the software without having to worry that we are introducing new errors in other areas without knowing it.

The function library has made automation a much easier process since we do not use record and playback. Our scripts create data and then manipulate the data that has been created.

It could work with more browsers other than Internet Explorer, and could better handle new things like Ext JS.

We have been using OpenText UFT for seven years.

It allows me to perform all in one place--

• Regression tests (tests which check that the existing functionality of an application still works as it should after other parts of the application have been modified),
• Functional tests (to verify a specific action or function of code), and
• Service testing (automated testing protocol)

I was able to reduce regression and functional test times by 80%.

It could be improved with greater browser compatibility and more frequent updates.

Also, running a simple test is straightforward, but creating a framework that can be reused across other tests is complex and time consuming.

I've used it for three to four years.

I didn't encounter any issues with deployment.

When debugging code in UFT, it would crash, freeze and hang a lot.

We had no issues with scalability.

6/10

8/10

We previously used Selenium Webdriver.

We implemented it with our in-house team.

HP UFT cost a lot and there are other free tools that can do the same and much more.

I joined the company after the decision was made to use HP UFT.

If cost is not an issue, then UFT can be considered. There are other tools on the market that can do the same for less.

The most valuable aspects to me are its versatility and how powerful it is with all the add-ins for so many different platforms.

I love working with database testing with the tool. I also love how UFT can run functional tests on the UI, then execute tests against a web or REST service, then it can use data from the database to test against the front end, and it can finish the test run by kicking off performance testing for the same application.

And all of that can be done from the QC/ALM tool so defects can be linked back to requirements and test cycles.

We do consulting, training and mentoring with the HP tool set, including UFT, so it is kind of our bread and butter. There are a lot of options with the tool. We just finished implementing an automation framework with over 600 tests using UFT.

Last week, I mentored another customer in how to use the tool with their team so they can start automating their tests.

We use it in a lot of different ways. I used it to build a script that automatically checks me in if I have a flight with Southwest to help me get a better boarding group, so it helps with my travel too.

The product is so robust by itself, testing both GUI and backend processes in conjunction with other tools like Loadrunner and ALM. The UFT tool can be such a huge boon to a testing organization that can commit to its use. Over time there is so much testing that can be taken off of the manual testers hands, allowing them to focus on the more complex testing issues.

Those areas I would have spoken of before are being addressed. HP added the LeanFT functionality for UFT 12.51 so users can build tests using Java or C# or other programming languages they might be comfortable with.

I would, however, like to see the application have fewer issues with crashes.

I've used it for over eight years.

That is one of the good things about the UFT tool. It is a mature product from a mature company, so while there are issues from time to time with installations, the tool usually deploys without issue.

Stability can be an issue, and the weaker the resources on the machine running UFT the more likely there will be problems.

Scalability is not an issue as long as an organization can afford the licenses.

Partners who offer support like our company tend to get high marks for that support. HP support is notoriously difficult.

Over the course of my career, I used Rational Robot back before IBM bought them and Silk Test as well as Silk Performer when Segue owned them both. All good tools, but not a fair comparison since I used them so long ago. I will say I loved working with Silk Performer.

There is a wizard for the set-up which I have always found to be simple and straightforward. That same wizard can be used to set up the license server, repair installations, install some add-ins, and some other features. It has always seemed pretty intuitive to me in terms of setting up QTP and UFT.

We generally will implement IR in-house, but then again we train and mentor folks on using these products, so that makes a certain amount of sense.

Read the install notes before you start and make sure your target system meets all the requirements. So often folks call for support when really it was a matter of not reading the installation documentation.

Well, ROI will be specific to a customer and their needs, but I can give an example.

We built automation for a company that needed 17 people for 12 or more weeks to run a regression test. That same test can be run in a week with the UFT tool and one or maybe two people to make sure there are no problems with those test runs. I built automation that created test sets, executed tests with those sets, and validated the results for a testing effort that took three people two or more weeks.

Given all that, ROI is really what automation is all about.

Get training. Being self-taught will leave a lot of frustrating holes that training fills. You can have really bright people but they just won’t know how to use some of the features of the tool because they won’t know those features exist. As a result they can grow frustrated and mistake their lack of knowledge for shortcomings in the product.

• The most valuable thing in my opinion is the ease of moving objects for storage from AUT into the object repository and handling them. 
• Also, built-in features for database connectivity and SQL queries for data retrieval are a time saver. This eliminates the need for descriptive programming and writing huge chunks of code for relatively simple tasks. 
• Step delay and object sync options are also a very useful feature.

• It saves time and manpower. Test development and maintenance are faster and easier thanks to UFT. 
• Also, one tool covers several projects developed in different technologies while the approach to test design can remain the same. A relatively small team of trained professionals can cover a wide range of tests. 
• Due to UFT’s popup messages for errors and test execution results viewer, it is very simple to analyze the test results and figure out what went wrong, reducing the time needed for defect detection and test updates.

• When it comes to improvements, definitely stability and system requirements are something that could be worked on. In cases of longer tests (in forms of so-called Mega Scripts), there can be a seriously huge usage of virtual memory by UFT that can lead to SystemOutOfMemory exceptions which are showstoppers and a huge annoyance. 
• Object recognition can be tricky sometimes. For example, UFT doesn’t recognize the object during test execution, but when you pause the run and click “highlight in app” button in object repository it recognizes the object and you can continue with the run. You still get the “failed” status in run results although it was a UFT error.

We use UFT only for our own test automation needs.

We haven't had any issues with deployment.

See the stability issues we had above.

We've scaled it for our needs.

My advice would be to find at least one experienced automation developer who previously worked with UFT to provide practical know-how to others when implementing it for the first time. 

Learning the basics is easy and intuitive when you receive a proper training. But using UFT the wrong way can turn out to be cost ineffective. UFT is an expensive tool that can save you a lot of time and effort and provide great value for money if used correctly, but also turn out as ineffective related to value-for-money if used the wrong way. 

YouTube tutorials are not the best way of training people for using this tool, the best way is finding people who already have experience to work with it or provide proper training for employees who have never worked with it.

The most valuable feature for me is API Tests for SOAP automation testing.

With HP UFT, we're able to synchronize with HP Quality Center, and API automation tests can be placed into test suites and run automatically through the HP Quality Center scheduler. Results for the tests are set and HP Quality Center is able to report on the test results. Emails can then be sent to notify anyone of the results in real time.

There are scenarios where the tool freezes and locks the user out. Re-opening the tool puts test results in a locked state, making the test read-only. The only way to unlock the test is to have an administrator force close the user’s last login.

Calling GUI tests within an API test or vice versa results in difficult, confusing scenarios on how to update tests properly when it comes to parameters and actions. Most of the time, it is easier to close the tests, open them one at a time, and perform the actions needed before calling the tests together.

I've used it for two years.

The only time I encountered tool issues was when the servers to our ALM database was down.

I personally have never had to deal with customer service or technical support. We have an administrator assigned to that task.

SOAPUI Pro and ReadyAPI were used for API testing. HP UFT was used in conjunction when automation needed to be set up. With the synchronization with HP Quality Center, HP UFT saved time.

I was not a part of the initial set up. Installing the tool on my machine was straightforward based on my company’s instructions.

My company is very firefighting friendly, so the ROI was immense when it came to automation and the amount of time it took to get test suites and regression set up. The amount of test cases a user can create in a short amount of time is incredible.

The ROI is variable depending on the size of the team, the amount of usage they plan on using the tool, and the budget they have on tools, training, and support.

I do not know the exact numbers my company paid for the licenses, but from what I heard on the grapevine, only seat licenses were bought when absolutely necessary and floating licenses were bought for everything else.