OpenText Functional Testing and Python - a realistic look at the current status

A report from the Private Beta (Version 25.2)

For years, OpenText Functional Testing (formerly UFT One) [FT] has been an integral part of many enterprise testing landscapes. Until now, VBScript has been the default scripting language for automated tests within OpenText Functional Testing (FT).

With the introduction of native Python support, OpenText will be taking a step towards modern development. We had the opportunity to thoroughly evaluate the new Python integration as part of a Private Beta (version 25.2). Our aim was to find out how well FT, in combination with Python, is already proving its worth in everyday work and where the current limitations lie.

The evaluation was carried out using concrete test cases from our daily work, with realistic data, applications and processes. Our focus was on web, Java and Windows desktop applications. The automated tests included structured test data, DeviceReplay, and FT's integrated Batch Runner for serial execution of multiple tests.

Functional Testing Scripts

Switching to Python brings many advantages. The language itself is significantly more modern and versatile than VBScript. Control structures like if, for, while are not only available but finally feel „right“, including lists, error handling with try/except, dictionaries, lambda functions, and object-oriented structure.

Object support was largely identical to VBScript. Known objects such as Browser, Page, WebElement, JavaWindow or WinObject can be addressed directly with Python. Descriptive Programming also works.

Pleasingly, the well-known Automation Object Model (AOM) could also be used with Python. This allowed us to plan, start, evaluate results and write logs for several tests outside of FT, directly from a Python script. This capability is particularly interesting for CI/CD processes or nightly regressions. Combined with simple logging, it was possible to run multiple tests sequentially with status evaluation, entirely without manual intervention.

The utility objects were also extensively tested. SystemUtil, Environment, RandomNumber, XMLUtil, Reporter, Description, DeviceReplay, PasswordUtil – everything was covered, much of it with real-world examples, such as password encryption, simulating mouse movements, or reading/writing test parameters.

We were also able to evaluate many checkpoint types: standard, bitmap, and textarea checkpoints worked solidly, while text checkpoints failed sporadically, apparently due to difficulties in identifying the relevant objects. Likewise, object repositories, including shared repositories, worked well. The integration of the object repository is possible across languages, so it can be used in VBScript and Python tests alike.

Furthermore, with OpenText's Batch Runner, we were able to successfully run multiple tests serially, written in both Python and VBScript. Test execution and result logging remained stable and efficient.

Another important point is the use of external Python libraries. FT uses a standard Python installation in the background. This allows third-party libraries such as requests to be used, provided they are installed in the corresponding site-packages directory. This means the entire range of Python libraries is available, as long as the installation is performed correctly.

Current Limits of Python Integration

However, alongside these advances, there are also clear limitations. Some of these were technically founded, others conceptually. One of the biggest limitations is also that there is no „call to action“ between the languages. At present, no Python converter for VBScript tests is available. Furthermore, the integration depth of Python is still limited, as recovery scenarios are not supported, the keyword view is disabled, and the usual F1 help context was also not available for Python tests.

Features like drag & drop via DeviceReplay worked formally (the test passed) but had no visible effect in Java GUIs. All recording types (Analogue, Low Level, Insight) are also fully usable in Python tests. The behaviour is no different from VBScript, but the practical benefit depends heavily on the application type, as low-level and analogue recording only worked correctly to a limited extent, especially with dynamic web applications.

Some features were not part of the beta version. These were mainly integrations with tools such as Application Quality Management (formerly ALM) and Business Process Testing.

What does this mean for practice?

The good news is that Python is fully usable for new projects in FT. Tests can be written in a structured and understandable way, and modern language constructs make the code more maintainable and robust. The limitations primarily concern integration issues, cross-platform compatibility, and UI helper functions.

In established test landscapes with a high VBScript proportion, a direct switch is difficult. However, those who want to set up tests anew or are planning a clean start can be productive with Python in FT after its release, even if some features are (still) missing.

Support for conversion tools and cross-language calls (VBScript–Python) is planned and will be available in future versions.

Conclusion

OpenText has taken a significant step with Python in FT. The implementation is already impressive in many areas and can be used productively if you are aware of the current limitations. Those starting anew today with a team that has Python expertise can get started right away. However, those who rely on deep integrations with OpenText™ Core Application Quality Management, BPT, or Recovery should wait.

We don't just see Python in FT as a replacement for VBScript, but as a valuable addition. This makes FT significantly more compatible with modern development and automation standards.