Ein Erfahrungsbericht aus der Private Beta (Version 25.2)

Seit Jahren ist OpenText Functional Testing (ehemals UFT One ) [FT] fester Bestandteil vieler Enterprise-Testlandschaften. Bisher war VBScript die vorgegebene Skriptsprache für automatisierte Tests innerhalb von OpenText Functional Testing (FT).

Mit der Einführung einer nativen Python-Unterstützung wird OpenText einen Schritt in Richtung moderner Entwicklung gehen. Wir hatten die Gelegenheit, die neue Python-Integration im Rahmen einer Private Beta (Version 25.2) intensiv zu evaluieren. Unser Ziel war es, herauszufinden, wie gut sich FT in Kombination mit Python bereits jetzt im Arbeitsalltag bewährt und wo aktuell die Grenzen liegen.

Abbildung 1: Neue Test-Erstellung in FT mit Python als Sprache auswählbar.

Die Evaluierung erfolgte anhand konkreter Testfälle aus unserem Arbeitsalltag, mit realistischen Daten, Anwendungen und Abläufen. Unser Fokus lag dabei auf Web-, Java- und Windows-Desktop-Anwendungen. Die automatisierten Tests enthielten strukturierte Testdaten, DeviceReplay, sowie den integrierten Batch Runner von FT zur seriellen Ausführung mehrerer Tests.

Abbildung 2: Demonstration einer Python-For-Schleife in FT

Der Umstieg auf Python bringt viele Vorteile. Die Sprache selbst ist deutlich moderner und vielfältiger als VBScript. Kontrollstrukturen wie if, for, while sind nicht nur verfügbar, sondern fühlen sich endlich „richtig“ an, inklusive Listen, Fehlerbehandlung mit try/except, Dictionaries, Lambda-Funktionen und objektorientierter Struktur.

Abbildung 3: Login-Prozess mit Fehlerbehandlung in Python (try/except)

Die Objektunterstützung war weitgehend identisch zu VBScript. Bekannte Objekte wie Browser, Page, WebElement, JavaWindow oder WinObject lassen sich direkt mit Python ansprechen. Auch Descriptive Programming funktioniert.

Abbildung 4: Seitentitel-Prüfung mit Python If-Bedingung

Erfreulich war, dass sich das bekannte Automation Object Model (AOM) auch mit Python nutzen ließ. So konnten wir mehrere Tests außerhalb von FT planen, starten, Ergebnisse auswerten und Logs schreiben, direkt aus einem Python-Skript. Diese Fähigkeit ist besonders interessant für CI/CD-Prozesse oder nächtliche Regressionen. Kombiniert mit einem einfachen Logging war es möglich, mehrere Tests nacheinander mit Statusauswertung laufen zu lassen, ganz ohne manuellen Eingriff.

Auch die Utility-Objekte wurden umfangreich getestet. SystemUtil, Environment, RandomNumber, XMLUtil, Reporter, Description, DeviceReplay, PasswordUtil, alles wurde angesprochen, viele davon mit realen Beispielen, wie z. B. Passwortverschlüsselung, der Simulation von Mausbewegungen oder dem Auslesen / Schreiben von Testparametern.

Wir konnten auch viele Checkpoint-Arten evaluieren: Standard-, Bitmap- und TextArea-Checkpoints funktionierten solide, während Text-Checkpoints sporadisch fehlschlugen, offenbar durch Schwierigkeiten bei der Erkennung der relevanten Objekte. Ebenso funktionierten Object Repositories, inklusive Shared Repositories, gut. Die Einbindung des Object Repositories ist sprachübergreifend möglich, sodass es in VBScript- und Python-Tests gleichermaßen genutzt werden kann.

Darüber hinaus konnten wir mit dem Batch Runner von OpenText mehrere Tests, geschrieben sowohl in Python als auch in VBScript problemlos seriell ausführen. Die Testausführung und Ergebnisprotokollierung liefen dabei stabil und effizient.

Ein weiterer wichtiger Punkt ist die Nutzung externer Python-Bibliotheken. FT verwendet im Hintergrund eine reguläre Python-Installation. Dadurch lassen sich auch Third-Party-Libraries wie requests verwenden, sofern sie im entsprechenden site-packages-Verzeichnis installiert sind. Damit steht die gesamte Bandbreite der Python- Bibliotheken zur Verfügung, sofern die Installation korrekt erfolgt.

Doch neben diesen Fortschritten gibt es auch klare Grenzen. Manche davon waren technisch begründet, andere konzeptionell. Eine der größten Einschränkungen ist auch, dass es keinen „Call to Action“ zwischen den Sprachen gibt. Zum jetzigen Zeitpunkt steht kein Python-Konverter für VBScript-Tests zur Verfügung.
Die Integrationstiefe von Python ist zudem noch eingeschränkt, denn Recovery Scenarios werden nicht unterstützt, die Keyword View ist deaktiviert, und auch der gewohnte F1-Hilfekontext stand für Python-Tests nicht zur Verfügung.

Features wie Drag & Drop per DeviceReplay funktionierten formal (der Test bestand), hatten aber keine sichtbare Auswirkung in Java-GUIs. Alle Aufnahmearten (Analog, Low Level, Insight) sind auch in Python-Tests vollständig nutzbar. Das Verhalten unterscheidet sich nicht von VBScript, aber der praktische Nutzen hängt stark vom Anwendungstyp ab, da Low-Level und Analog Recording nur eingeschränkt korrekt liefen, insbesondere bei dynamischen Webanwendungen.

Einige Features waren nicht Bestandteil der Betaversion. Das waren vor allem die Integrationen zu Tools wie Application Quality Management (ehemals ALM) und Business Process Testing.

Die gute Nachricht: Für neue Projekte ist Python in FT durchaus einsatzbereit. Tests lassen sich strukturiert und verständlich schreiben, moderne Sprachkonstrukte machen den Code wartbarer und robuster. Die Einschränkungen betreffen vor allem Integrationsthemen, plattformübergreifende Kompatibilität und Hilfsfunktionen aus der UI.

In gewachsenen Testlandschaften mit hohem VBScript-Anteil ist ein direkter Umstieg hingegen schwierig. Wer aber Tests neu aufsetzen möchte oder einen sauberen Neuanfang plant, kann mit Python in FT nach der Veröffentlichung produktiv arbeiten, auch wenn manche Features (noch) fehlen.

Die Unterstützung für Tools zur Umwandlung und sprachenübergreifende Aufrufe (VBScript–Python) ist in Planung und soll in zukünftigen Versionen verfügbar sein.

OpenText hat mit Python in FT einen wichtigen Schritt gemacht. Die Umsetzung ist in vielen Bereichen bereits überzeugend und lässt sich produktiv nutzen, wenn man die derzeitigen Grenzen kennt. Wer heute neu startet und ein Team mit Python-Kompetenz hat, kann direkt loslegen. Wer hingegen auf tiefe Integrationen mit OpenText™ Core Application Quality Management, BPT oder Recovery angewiesen ist, sollte noch abwarten.

Wir sehen Python in FT nicht bloß als Ersatz für VBScript, sondern als wertvolle Ergänzung. So wird FT deutlich anschlussfähiger an moderne Entwicklungs- und Automatisierungsstandards.