OpenText UFT Digital Lab Reviews

There are various use cases, each tailored to the specific needs of our customers. When we consider Application Lifecycle Management (ALM), the use case significantly differs from Unified Functional Testing (UFT). Our primary objective is to assist customers in optimizing their software development life cycles. This involves facilitating decisions based on platform usage and the data entities they input into the system. We help them link these components, conduct automated functional and performance testing, and ultimately provide a definitive decision-making process. The goal is to ensure that when a customer is ready to launch a product or software, they can make a well-informed decision, either to proceed confidently or address any issues that may arise based on the data and testing results available within their systems.

There are numerous valuable features such as automation, the ones that facilitate importing and synchronization capabilities between our platform, Jira, and Azure DevOps. Also, traceability between various entities is of paramount importance. When introducing a new requirement or user story, it's crucial to establish links to associated defects, track test runs, and monitor test statuses. This traceability allows us to comprehensively map and document every aspect of the application delivery life cycle.

We use it in financial services companies to automate mobile solutions and applications.

It allows multiple devices to be used and gives flexibility in adding devices when a project is needed. Most of the time, I have several devices where it is predefined. We can use it, but sometimes, we must scale it in a particular situation. It's very flexible.

It is very important because we can use a different approach to software testing, for example, to find a way to execute UFT software testing with only one execution. This reproduces all the platforms that we need.

I use the solution in my company to test desktop applications.

The decision-making capabilities of the product help the product grow.

The fact that it allows users to test on real mobile devices instead of emulators is something that projects have told us is beyond compare. Your app or your website won't behave on an emulator like it will on a real mobile device, no matter how great the emulator is - even if it's the one that comes from the OS developer that ships with the development studio. There's just no substitute for a real mobile device with its hardware constraints and the way it will behave in the hands of a user.

We like to host the tools centrally. We would need them to be multi-tenants, so different projects could log on and have their own set of devices and their own set of apps, and they wouldn't see data from other projects that are using it. Right now, the way that we're managing it is we're requiring no clients are able to access it, so if we do happen to see something that belongs to another project, it's not a big deal. But true segregation of devices and apps, packaged apps, that have been uploaded to the tool, is something that is important to us. It's not there right now.

It's relatively easy to use and it allows you to use decentralized devices to test with. I don't know if it's that important. There are some negative drawbacks to it, but it's flexible. It's a different option with them being centralized.

The ability to test mobile devices, which is pretty important. We can test different flavors of mobile devices, different versions of the operating systems on those mobile devices. That's pretty important for us.

Has more testing on real devices along with emulators. Using the existing enterprise tools, like UFT, or even if you want to go open source, you can use them and it's a real user-functional performance, we are able to achieve that.

Mobile Center is pretty new for HP. Other than the HP solution, we also use Mobile Labs. The ability to test and open it up to the development teams so it's the entire shift left. You try to give something to the development team ahead of time rather than them trying to analyse how it could work and it's on a real device which they need to support. That's number one.

Number two is cutting down cost of procuring the actual devices. Now you can create a private cloud within the organization so people understand what ability you need to have a consolidated set of devices and utilizing the solution.

This helped my prior organization immensely due to the ability to remotely manipulate devices, even by offshore vendors. Additionally, coupling automation with UFT and/or LeanFT led to more robust and faster testing of software releases. Furthermore, the addition of the Amazon device farm in version 2.0 make this solution a serious leader in the mobile testing space.

The network virtualization (Shunra NV) saves real money for users as data plans are not required to simulate real world conditions. Additionally, the Amazon device farm and ability to add emulation allows users to have access to almost any device one could think up!

• Management of a pool of devices that can be made available globally for automated, manual or performance tests, via a slick interface.  
• Strong integration with HPE tools, ALM, UFT, Sprinter and LeanFT, and the integration with non HPE tools.  
• Strategic solution that pulls in real world analytics from AppPulse Mobile to aid in definition of strategy and integrates with Network Virtualisation to see how the device will run under real network conditions.  
• Primary usage is on real devices but also supports emulators.  
• The 2.0 release extends capability to AWS device farm.

It is enabling a global strategy to be put in place.  Our largest implementation is with a global team.  The solution provides a controlled device farm with the right devices (selected based on analytics), that are readily available (can be reserved), have the right app and can be used for manual or automated tests.  

Manual testing (with Sprinter) is accelerated with steps being captured automatically with exploratory testing, storyboards being captured and device logs etc. automatically being attached to defects (that can be sync'ed back to non-HPE tools or raised directly in non-HPE tools).  Net effect, developers get the right info to address issues quickly and efficiently.

Automation allows fast and efficient testing across a range of devices, this would not be feasible manually.  The skills and good practice used for non-Mobile directly apply. Shared Object Repositories and Application Models make a big difference for maintainability - object recognition has always been a HPE strength.

There has been a notable shift in emphasis, from the on device get it to work, to strategy and how the full benefit of the solution, with analytics and NV is used.