UFT One review: what it is, tutorial and pricing

UFT recognises objects through add-ins, each of which understands one technology: Web, Java, .NET, SAP Solutions, Oracle, PowerBuilder, Siebel, Terminal Emulator, UI Automation and others. The Add-in Manager chooses which load when UFT starts, and a test records which add-ins it needs. With the right add-in, a SAP grid or a Java table is a typed object with meaningful methods; without it, the same control is a generic window that only accepts coordinates. Most first-day failures, and many after a technology upgrade, trace back to add-in loading or a version the support matrix does not cover.

UFT separates how an object is identified from what the test does with it. Each test object has a class, such as WebEdit or SAPGuiButton, and a description: a few property values, by default the mandatory properties for its class, plus assistive properties and an ordinal identifier when needed to tell similar objects apart. Descriptions live in an object repository. Each action has a local repository, and shared repositories, stored as .tsr files, can be associated with many actions, so a changed button is fixed once. Repositories are managed through the Object Repository Manager and merged with OpenText’s merge tool, because they are not text files.

A GUI test is a folder of actions, each a VBScript script with its own local repository and data sheet. The data table, a spreadsheet with a global sheet and one per action, drives iterations, so the same steps run once per row. Function libraries hold reusable VBScript functions associated with a test, and recovery scenarios handle unexpected pop-ups. Checkpoints compare object properties, text, bitmaps or databases against expected values. The structure rewards design: tests built from small reusable actions and libraries stay maintainable, while recorded monoliths do not.

UFT drives applications through Windows itself, so a GUI test needs a real user session with a desktop. A run options setting lets tests execute on a remote machine whose session is locked or disconnected, but logging off is not supported, and a local machine that locks during a run can fail it. Every running instance also holds a licence. Those two facts shape execution: dedicated Windows machines or virtual machines, kept signed in, with parallelism bounded by concurrent licences. ParallelRunner, a command-line tool, runs web tests across browsers and mobile tests on lab devices in parallel, each run consuming a licence.

Structure decides whether a UFT suite survives. Keep one shared object repository per application area, associate it with the actions that need it, and keep local repositories empty or close to it. Put business steps such as signing in or creating an order in function libraries, so tests read as sequences of business actions. Use descriptive programming, Description.Create and ChildObjects for objects whose properties change at run time, such as table rows, and keep descriptions minimal: two or three stable properties with regular expressions where needed. Give each shared repository an owner, because concurrent edits to a binary file are resolved only through the merge tool.

Replace recorded literals with data table parameters as soon as a test works once. The global sheet drives test iterations; each action sheet can drive action iterations, so a login action can run once while an order-entry action runs for every row. Import sheets from Excel for business-owned data, and keep secrets out of the table by encrypting them with the Password Encoder and using SetSecure. For values that differ by environment, such as URLs or credentials, use environment variables loaded from an XML file per environment rather than editing tests. A suite organised this way can switch between test and staging with a single file.

OpenText supports CI through its Application Automation Tools plugin for Jenkins, an Azure DevOps extension, a GitLab guide and the opentext/functional-testing GitHub Action. The action runs on a self-hosted Windows runner with UFT installed, downloads FTToolsLauncher, runs GUI and API tests stored in the repository, or ALM test sets, and archives the results. Test paths must be relative to the repository root, and parameterised file-system runs go through an MTBX file. The runner service must run in a signed-in Windows session for GUI tests. For other CI servers, the same FTToolsLauncher utilities run tests from the command line and convert reports to JUnit XML.

Scale is a licensing question first. ParallelRunner, in the installation’s bin folder, runs web tests across several browsers and mobile tests on lab devices at once, but UFT itself must be closed while it runs and each run holds a licence. The Docker images move headless Chrome web tests and API tests onto containers that can be created per run, again with concurrent licences only; desktop technologies such as SAP GUI or terminal emulators still need full Windows machines. In our experience the practical pattern is a small pool of Windows virtual machines, kept signed in, each with one concurrent licence and a CI agent, with long suites split by business area across the pool.

AI-based steps are useful where object properties are poor, for example canvas-drawn controls or applications that regenerate ids. Set the context once, then address controls by type and visible label; keep them for those screens rather than replacing a working repository. Treat the 26.x additions as a roadmap to pilot. Python is in beta as a test language, and Microsoft lists VBScript as deprecated in Windows, to become a feature on demand before removal. We found no OpenText statement on how that affects future UFT versions, so check the support matrix before each Windows upgrade and keep new framework code in small, well-named functions that could be ported.