Functional Testing

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 .

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.