I'm more familiar with Functional Testing. OpenText Functional Testing for Developers is a different product set that functions as an IDE for writing custom code. We don't leverage that product because OpenText Functional Testing has been built so well that we don't have the need to just write standard code. We're leveraging more business people to create scripts versus automation engineers.

Having the platform available for business users to create tests who understand the product and understand the business workflows is huge for adoption within an organization. It also allows for standard code writing. If you run into a challenge that AI can't adapt, you can supplement your team with automation engineers who can create custom solutions.

OpenText Functional Testing has an impressive ability to connect to mobile devices and its ability to test so many different types of software, whether it be mainframe, APIs, mobile, web, or desktop. The extensibility it has to test overall cost is a huge bonus compared to other products. The ease of being able to create scripts using the AI tools are the differentiating factors.

Reducing the levels of support is something they could continue to improve. They tend to have an entry-level person that may not be as familiar with the product that fields the calls, which creates another day of delay to get to the level that's needed. This is a common practice across most companies where you call, you get the entry-level person, and then they work their way up to help screen calls so that they are more focused.

OpenText Functional Testing speeds up the overall ability to get through a large volume of tests. Being able to run them in parallel allows for scalability overall. If you have 10,000 tests and you run them back to back, that might take five days to run. Running them in parallel allows you to consume multiple runtime licenses and just execute the tests that don't have conflicting priorities and get through a lot of volume much quicker.

I would rate the support for this product a seven on a scale of one to ten. The support staff is the same as for Digital Lab.

Compared to other products like Tricentis, OpenText Functional Testing is about a third of the cost and there are no minimum license requirements. For our customers, it has opened the door for being able to get them to adopt the products because the cost is so much less. The ease of use reduces a lot of barriers for hiring engineers and people that an organization may not have the budget to bring on.

The key difference is that you can write custom code in OpenText Functional Testing whereas Tricentis is more of a no-code solution. OpenText Functional Testing is a low-code solution, meaning that I can use the AI tools to capture scripts as if it were a record and playback tool, but it's creating the script in the background that can be manipulated. With Tricentis, if it doesn't work, you cannot create code to cause the tool to run the automation. The flexibility of OpenText Functional Testing opens it up for much more creativity and introduces much better solutions.

I am uncertain about what is meant by advanced scripting. The overall review rating for this product is nine out of ten.

During our last conversation, I mentioned that I have experience with OpenText Functional Testing.

I have had experience working with OpenText Functional Testing for three years.

We use OpenText Functional Testing for functional testing and UI testing using UFT.

In my organization, OpenText Functional Testing is deployed on-premises.

The best features of OpenText Functional Testing include descriptive programming, the ability to add objects in the repository, and its ease of use for UI compared to other tools. It also supports VB Scripting, where we can use our data structure skills in the tool to solve complex functional testing.

OpenText Functional Testing is a scalable solution. Users can buy licenses and expand resources widely in their organization. With more licenses, testing capabilities can be expanded.

Areas of OpenText Functional Testing that have room for improvement include having an option to store objects in the public repository when using Object Spy and adding objects, as it currently stores them locally. Additionally, there are hanging issues where it becomes unresponsive, which can be improved.

I have had experience working with OpenText Functional Testing for three years.

OpenText Functional Testing is a stable solution. We have been using it for three years without facing any major issues.

OpenText Functional Testing is a stable solution. We have been using it for three years without facing any major issues.

OpenText Functional Testing is a scalable solution. Users can buy licenses and expand resources widely in their organization. With more licenses, testing capabilities can be expanded.

I would rate technical support for OpenText Functional Testing around seven to eight on a scale from one to ten.

I am not interested in this course or taking this course, so I do not know the purpose of this call.

The initial setup of OpenText Functional Testing is not hard; it is easy. Users just need to have the knowledge to install the packages and then add those add-ins.

I am working in an organization that has a partnership with OpenText, though I am not sure what kind of partnership or relationship my organization has with OpenText.

I have no idea about the pricing of OpenText Functional Testing. The organization handles the pricing and investments.

My company name is Agilent Technologies Incorporated, and my title is Engineer. My email address is mirza.h@non.agilent.com.

Regarding AI integration in OpenText Functional Testing, we currently use AI features where we do not need to identify objects; we just need to write the text in the AI, and it will find the button wherever it is on that page. It would be great to have AI-driven analytics or predictive models improving test accuracy, but I would want to understand exactly what that does and how it helps functional testing.

I rate OpenText Functional Testing an 8 out of 10.

We migrated a number of the tests from OpenText UFT One to SOAtest. The biggest change was moving from validating in the GUI with OpenText UFT One to validating in the database. We are not currently testing the browser extensively because our webpage is not customer-facing but is instead an administrative tool.

OpenText UFT One offered valuable features by allowing us to build up libraries to streamline repetitive tasks, making scripting much easier. However, it required knowledge of the scripting language, VBScript, which is limited compared to Visual Basic. Despite handling web pages effectively, dependency on the browser for validation presented stability issues when Windows would exhaust memory, causing regression testing crashes.

OpenText UFT One required knowledge of VBScript, which is a limited version of Visual Basic. We frequently encountered stability issues when the browser dependency caused Windows to consume memory without releasing it, leading to crashes during regression testing. This experience suggests a need for improvements in handling memory efficiently.

One of the key stability issues was that Windows would consume memory without releasing it, leading to regression testing crashes.

It is not current, but when we dealt with HP, I would rate the support as a six or a seven.

We switched from OpenText UFT One to SOAtest.

Setting up OpenText UFT One was generally straightforward. However, we had to develop some DLLs to perform certain tasks that the system couldn't handle by itself, requiring additional effort. We built various libraries to improve scripting efficiency and speed, which took time and evolved over the course of our use.

I might rate OpenText UFT One around a five or six, based on my past experience, so my rating would be a 5. Name usage should be limited to personal names for publication. I am currently in a low-level manager position and plan to retire in three months, which may affect my access to follow-up communications.

I have used UFT for web application automation, desktop application automation, and Oracle ERP automation.

UFT provides object identification, which is one of the easiest to use. It requires less coding, has built-in features for API testing, and most importantly, it supports more than just web applications. UFT supports Oracle, SAP, PeopleSoft, and other non-web applications, making automation feasible.

UFT still requires some coding. If it could move closer to a no-code or low-code solution, it might dominate the market again.

Additionally, customer support could be improved as they take days to respond to a ticket, which is a significant drawback.

I have had more than ten years of experience with UFT, probably around 14 years.

Customer service is a big drawback. From my personal experience, after creating a ticket, it takes three to five days for them to acknowledge it and then send it to somebody. Organizations can't wait for this lengthy process, especially when they are under pressure with their timelines.

I have worked with open-source tools like Java Selenium, C Sharp Selenium, and also with NoCode tools. Compared to the tools that require coding from scratch, UFT's time is half or less than half.

Setting up UFT is not complex. I would rate it probably eight out of ten in terms of ease. However, the licensing needs to go through some processes involving servers and machines.

The server admin, the installation team, or the developer would be involved in deploying the product.

The development time using UFT can be cut down into half as compared to coding from scratch. While NoCode tools take less time, UFT is more efficient than tools like Selenium that require full coding.

There are many open-source tools with no cost, and there are no-code tools that are less expensive than UFT. The pricing of UFT, being an established tool, could be better if reduced.

I have used Selenium and some other tools before UFT.

I love working with UFT as it makes my work easier as a developer, architect, and lead. However, I would recommend it with caution due to the cost implications.

Overall, I would rate UFT as an eight out of ten.

We use OpenText as an archive server for archiving purposes from SAP, or we use OpenText in the context of vendor invoice management.

We can easily achieve a return on investment in one, two, or three years. It depends on the business revenue.

The OpenText solution is the best of breed and the best solution on the market for large customers. That is why we use OpenText.

The user interface could be improved.

I've been working with SAP since 1996 and 1997.

The stability of the solution is rated nine out of ten.

The scalability of the solution is rated eight out of ten.

The technical support is rated eight out of ten, but it depends on how much you pay for the support and how big you are as a customer.

The initial setup is complex.

We can easily achieve a return on investment in one, two, or three years. It depends on the business revenue.

The pricing or licensing policy of OpenText is a bit expensive, however, it's one of the best solutions in the market.

I would recommend the solution as it's one of the best tools in the market. I'd rate it seven out of ten. To make the solution a ten out of ten, it could be more user-friendly.

I use UFT One for GUI testing, specifically to test web applications across various technologies. I also use it for automating desktop application tests, including applications built in Java. Additionally, I conduct mobile testing for Android applications, utilizing parametrized actions.

Automation of tests is done very fast with UFT One. In a couple of hours, many tests can be created, which significantly reduces costs related to QA testers. This efficiency means there is less need for programming knowledge, making test automation quicker than with tools like Selenium or Cypress.

The object repository is one of the best in the market, allowing creation of a repository useful for all tests. I also appreciate the AI testing capabilities, making it easy to create tests without programming knowledge. The integrations with other products are simple and effective.

There could be improvements in report export features similar to SmartBear. Additionally, incorporating behavior-driven development tests would enhance the capabilities of UFT One.

I conduct testing using UFT One.

UFT One is very stable. It is a good tool in the market.

It is very scalable. The tool can be installed on all computers used by developers or test automation engineers, and more licenses can be purchased for larger deployments.

Customer service is managed by OpenText, previously Micro Focus and HP, and they offer very good services. Support cases are easily created and attended to promptly, depending on urgency.

I use UFT One more technically. I have used SmartBear and Tricentis for comparison, noting differences like testing paradigms.

The initial setup is very easy and the tool comes with a wizard. It's a simple process to configure the necessary parameters.

It is simple to deploy UFT One. The tool comes with a setup wizard, just requiring parameter input.

Automation is done very fast, leading to improvements in the QA process and reducing the time needed for test automation.

The cost is reasonable considering it is one of the best tools in the market. It's cheaper than Tricentis Tosca but more expensive than some others.

I have used other tools like Tricentis and SmartBear. They have different paradigms, such as model-based testing.

UFT One is a very strong tool for automating testing and improving application quality.

I'd rate the solution nienout of ten.

The solution's recording option is the most beneficial for test script creation and maintenance. Using the protocols, I can test a huge variety of applications in a company. If I implement OpenText UFT One in a project, I can test almost 90% or more of the tools used in highly digitalized banks.

The most useful feature is the recording option because it allows an expert user and a junior user to do a script in comparable ways.

The solution should have additional features, but not much. It already has some sort of artificial intelligence that must be developed. It needs to be in trend. The solution needs better marketing, training, promotion, and visibility because it is not visible.

Often, people with open-source tools and only open-source knowledge take projects that OpenText should have taken.

I have been using OpenText UFT One for 20 years. I use the solution myself and recommend it to my customers.

There are issues with the technical support. Resolving your issues takes quite a long time until you get a guy who knows the task. I have worked for almost 20 years with OpenText products. I often prefer to use my crew with 10 or 15 years of experience rather than call their technical support team. I call the support team when a development or a patch is necessary and when it's a bug I can't fix because I'm not a developer inside their system.

OpenText UFT One is a very expensive solution. The solution's pricing is too high for the level of support and quality they offer. OpenText has extremely powerful tools. If you ask me to choose the best tool for a huge international telecom, an international bank, or an international oil and gas company, I will choose OpenText.

However, the tool has glitches that are visible to the customer. Since OpenText asks for a very high price, they should solve those glitches in at least a couple of years. Since there are glitches that have been unsolved for many years, I consider the pricing to be too high for what they offer.

I follow the OpenText pricing model because OpenText is actually selling, not me. I sell to my customers through my company, but I have to sell according to OpenText price metrics. When I propose functionalities to the customer, I propose the whole bundle, and then we discuss the price. The price is written individually on every offer.

The solution's cross-browser and multi-platform testing capabilities positively impact my testing efficiency because I don't have to change the tool. I'm using the cross-browser capability in old tools. It's even better if I use a printer with cross-browser functionality in manual testing. I can switch from one tool to another quite quickly. It's not only UFT; it's an integrated platform.

I integrate all the products easily. I know the entire architecture and integration, and I only work based on integration.

Most people do not understand that various tools like OpenText UFT One, LoadRunner, or Quality Center are integrated and work together. If you want to apply the entire methodology described in the International Standardization Organization standards, you have to think of these tools as a whole, not separately.

Most customers make the mistake of considering them separate items, especially when discussing pricing. These tools are powerful when they are integrated and work together. Otherwise, there are many variations in the market.

I primarily work with OpenText and recommend their products. If the customer wants another product, like Selenium, based on price or their agreed-upon internal matrix of tools, I have to work with Selenium.

Overall, I rate the solution ten out of ten.

I use the solution in my company for process automation and test automation.

The most valuable feature of the solution stems from the fact that it offers a lot of application types. The tool offers original scripts. If you respect original stuff, then you will like it. Earlier, it was called QuickTest Professional (QTP), and it was later changed and branded as OpenText UFT One. The tool is easy to use and is an original solution. If someone has had an experience with the tool for a long time, they can use it even now.

From an improvement perspective, I want the product to maintain the original way it was working in the past. Previously, the product was a script-based solution. Presently, the tool offers non-script, no-code, or low-code functionalities, making it an area where improvements are required. With the low code and no code part, the tool does not focus much on the capabilities and support of the automation plans. The price of the tool is too high, and it is also an area where improvements are required.

I have been using OpenText UFT One for more than five years.

Stability-wise, I rate the solution a seven out of ten.

It is not a scalable solution. I rate the tool's scalability a five out of ten.

My customers own big companies and they have money to buy the tool, so they buy legacy system that work for ten to twenty years. If they want to automate, they need to use the tools that are compatible. Considering the old and big organizations in Thailand, I think there are around ten to twenty customers that use the tool.

There have been hard times with the support of the tool. The tech team did not meet our expectations when we approached them with very difficult issues.

I rate the technical support a six to seven out of ten.

The product's initial setup phase is easy and straightforward. You have to know the objective of the software, and then you will understand that the setup phase is easy.

Anyone can complete the product's installation phase with the help of the installation guide that it offers and download the tool.

Most of my staff members were involved in the installation process.

The solution is deployed on an on-premises version.

The solution can be deployed in an hour.

The automation part makes it difficult to provide any real benefits in terms of ROI. We need to implement the product well enough to benefit from it. Right now, the tool's cost is very high. The tool has a lighter version, which is better than the real tool, but right now, it is not good enough for automation. Based on the policies of organizations, we may need to purchase the tool because the newer automation and testing solutions in the market do not support legacy systems. OpenText UFT One supports most legacy and new systems, and so its support metric is higher than the other products in the market.

The tool's price is high.

I need to evaluate many products, including the ones from Tricentis, the open source tools, like UiPath.

The product can integrate with the process or test management tools. If you want to schedule and automate the run, and if a solution is in a certain process with some condition, OpenText UFT One can be set up and be a part of the workflow. Anywhere, if you understand DevSecOps or NetOps concepts, then OpenText UFT One can be used with the DevOps concept as well. I think it's quite easy to use if you know the product's command line in Windows, and it can be enabled by any tool that runs it. Though OpenText UFT One has API indicators, the scripts in Windows can also be helpful.

Speaking of the challenges the tool helps users overcome in terms of testing workflows, I can say that the tool can be used for automation and testing purposes, and the benefits of it is that the solution can produce results and execute them in a certain period of time, making it one of the main capabilities of OpenText UFT One and OpenText's process automation and testing functionalities. When it comes to creating scripts, if you are familiar with OpenText UFT One, things will be easy for you.

The AI technology that needs to be involved in the tool is to discover the best object on the screen. AI will match what we think is the right thing in the right place. If we click the cancel button, the users should be able to find the cancel button on the screen and then click it. Users should be able to find the object on the screen when they try to click it.

Around twenty engineers maintain the tool.

I rate the tool a seven out of ten.

We use the solution on web applications. Recently, we used it for a data validation service. We use it for functional test cases. For example, when someone opens an account in a bank, we test that process. This involves backend validations and UI validations on the mainframe. Then, we check if the same data appears correctly on the web application.

We use OpenText UFT One to automate end-to-end flows that involve multiple applications. We can handle combinations of backend, mainframe, and web applications. If we use Selenium, it's not suitable for all these combinations.

The most valuable features are its support for multiple technologies, ease of coding, object repository, and ability to design our own framework. The recording playback feature allows those unfamiliar with coding to use the tool.

The tool needs to improve its performance since it can become heavy.

I rate the tool's stability an eight to nine out of ten. The scripts are stable.

I haven't reached out to the tool's support yet. It is an old tool with documentation and websites for reference.

OpenText UFT One's deployment is straightforward. The tool gets installed when you click "next". By default, all other prerequisites will get installed automatically. You don't have to do anything.

We have ALM licensing, and the tool is free of cost.

The impact of implementing OpenText UFT One in our testing strategy has been somewhat conservative. It depends on how automation tools are utilized within the organization. Our approach has been quite planned, but overall, automation efforts haven't increased.

The main differences between OpenText UFT One and other functional testing tools are features like record, playback, and the object repository.

I rate it an eight out of ten.

OpenText UFT One is currently used in our company, MLC, which Insignia Financial has recently purchased. Our organization is in the process of migrating our platform to the ones used in Insignia Financial, and as a part of our planning, we aim to standardize the tools in our company.

I do not use testing tools in the company. There is a separate testing team in our organization that uses testing solutions. I am only involved in the area of technical service for the platform. I look into areas like the ecosystem's cost, licensing, and standardization. Some in-house personnel in our company manage the area of testing capability, but a lot of it is outsourced to some other party.

The product wasn't easy for developers to learn and pick up in the area revolving around scripting for automation, and there was a lot of resistance from developers, causing my company to rely on specialist resources. The aforementioned area can be considered for improvement in the product.

I have been using OpenText UFT One for years. My company is a customer of the product.

My company has not had an issue with OpenText UFT One since we have been using it for the past three to four years. My company did not face any issues with the testing capabilities of the product, but we need to consider rationalizing the technology and toolsets present in our organization. There were some challenges with the product, but there were people in our company who were not from the development team to take care of the part that involved scripting. With the product, most of the automation part was taken care of by the testing team in our company. There weren't many differences in our company due to the issues in the solution because of how our company had outsourced certain work for which we were paying anyway.

Our company currently has around 90 testers on a program, but the numbers may vary and depend on whether a normal project ramps up or down. For the migration process, my company has around 400 testers since it is a process where there will be a ramp-up till November, after which there will be a need for only 90 to 100 users when the ramping-down process starts.

The testing teams in our company would contact the product's technical team. Our company has a different team to take care of the development area. From my company's management perspective, the developers did not like using OpenText UFT One and would prefer other tools like JMeter.

I use OpenText for areas like COBOL.

I think that in my company, a testing platform known as Mercury was used. After my company purchased a new testing platform, we are looking into what needs to be done.

OpenText UFT One was the third testing tool that was used in our organization. The issue in our company always stems from the fact that the GMs for testing have a certain comfort level based on which they bring their own set of people, and then they try to change the tool. My company has refrained from changing the tool we currently use in our organization because there is a lot of waste of money every time there is a product change. My company is dealing with the shoes related to how many tests are needed and how we can leverage the teams because, presently, we focus on having more permanent people in our organization, for which the standardization of tools is important.

In our company, we use IBM TOWER, with which we have discussions with OpenText. IBM TOWER is a legacy product that is really bad with the security part. IBM TOWER is an expensive product to upgrade, making it an area of worry for our company. There are multiple subsidiaries of our organization where IBM TOWER is used. IBM TOWER can be considered a product that falls under the category of an end-of-life tool.

The pricing of the product is an issue. The other product that my company is considering against OpenText UFT One is an equally bad solution. The aforementioned statement proves that pricing may not be a criterion when planning to purchase a solution, but our company needs to look into how much investment we have on the platform we use compared to other subsidiaries where some alternate products are used.

Against OpenText UFT One, my company considers a product named Tosca.

My company faces a challenge presently since we have got to do a migration by the end of the current year. One of the options that our company has in order to ensure that we do not lose the benefits of automation and regression testing is to delay the changes of tools in our company until the migration process is carried out.

Speaking about how the tool is used in our company for automated functional and regression testing, I would say that OpenText UFT One is used for regression testing. The tool's level of regressions is used for system tests, SITS, and some UFT regression tests as well. The issue we face in our company is when we migrate or consolidate data on some of the platforms since we have to rewrite some of the scripts. Owing to the aforementioned issue my company faces with the tool, we are looking for a way to see how we can automatically change, migrate, or consolidate data on another platform.

My company is looking at some of the performance testing tools in the market. My company looks at the products in the market separately based on the different tests for which we require them so that there is not much of an overlap of functionalities in different tools for the test cases. My company wants to also look into solutions that can provide all the functionalities in one product. The other non-functional testing areas, like monitoring and integration capabilities with ServiceNow and other tools, can also be tested.

Our company has an architecture team that looks into the product that we use, after which the team puts forth some options for us, but the head of the testing team and testing SMEs carries out the evaluation process. I don't have hands-on experience in the aforementioned area.

Considering the last three years, there has been a good level of satisfaction from the use of the product that our company has experienced. The testing teams in our company did not complain about OpenText UFT One. There were some issues in terms of the development phase since our company could not roll it out to the DevOps team as the developers couldn't pick up the product easily.

I rate the overall tool a seven out of ten.