Robot Framework ist ein Test-Framework, keine Programmiersprache

TL;DR: Robot Framework entfaltet seinen grössten Nutzen, wenn es ausschliesslich als Testbeschreibungsformat eingesetzt wird. Auf Testfallebene existieren nur Keywords und Variablen, alle technische Logik liegt in Python-Libraries. Dieses Architekturprinzip ist keine Privatmeinung: ISTQB-Standards, IEEE 829, die Fachliteratur zur Testautomatisierung und der RF-Schöpfer Pekka Klärck fordern es übereinstimmend. Ein Testfall mit IF/ELSE ist formal betrachtet kein einzelner Testfall, sondern mehrere implizite Testfälle, die aufgeteilt gehören.

Lesedauer ca. 12 Min · Stand: 2026-04

Robot Framework hat seit Version 4.0 systematisch Programmiersprachen-Konstrukte eingeführt: IF/ELSE, TRY/EXCEPT, WHILE, VAR. Die Community hat diese Features eingefordert, und sie haben ihren Platz in bestimmten Szenarien. Für Testautomatisierung bleibt die Empfehlung der RF-Maintainer trotzdem unverändert: keine komplexe Logik auf Testfallebene. Dieser Artikel zeigt, warum diese Empfehlung in internationalen Standards verankert ist — und wie sich die Architektur in der Praxis umsetzen lässt.

Testfälle sind Spezifikationen, keine Programme

Die gesamte BDD-Bewegung gründet auf einer Prämisse: Tests beschreiben Verhalten, nicht Implementierung. Dan North, der Begründer von Behaviour-Driven Development, beschrieb den Wechsel von «Tests» zu «Szenarien» als tiefgreifenden Paradigmenwechsel. Die Agile Alliance verwendet die Begriffe «scenario» und «specification» statt «test». Gojko Adzic dokumentierte das Prinzip in seinem Jolt-Award-prämierten Buch «Specification by Example» noch deutlicher: Die Automatisierung soll die Spezifikation nicht verändern.

Was bedeutet das für Robot Framework? RF-Testfälle wie Antrag Einreichen oder Bescheid Auf Korrektheit Prüfen sind Verhaltensbeschreibungen in fachlicher Sprache. Sie sagen, was das System tun soll. Wie es das tut, steckt in den Python-Libraries darunter. Sobald IF/ELSE, FOR-Schleifen oder VAR-Syntax auf Testfallebene auftauchen, verschwimmt diese Grenze. Der Testfall wird zum Programm. Und als Programmiersprache ist Python schlicht besser als RF.

Die Cucumber-Dokumentation formuliert den Massstab dafür so: Szenarien beschreiben das beabsichtigte Verhalten des Systems, nicht die Implementierung. Der entscheidende Test lautet: Muss dieser Text geändert werden, wenn sich die Implementierung ändert? Wenn ja, ist es keine Spezifikation, sondern ein Skript.

Was ISTQB, IEEE und ISO dazu sagen

Die Forderung nach logikfreien Testfällen ist keine Geschmacksfrage. Sie ist in internationalen Standards verankert.

Das ISTQB-Glossar (Version 3.7) definiert einen Testfall als ein Set aus Vorbedingungen, Eingaben, Aktionen, erwarteten Ergebnissen und Nachbedingungen. Das ist eine fixe Datenstruktur, kein Algorithmus, kein Platz für Verzweigungen. Bei gegebenen Vorbedingungen und Eingaben gibt es genau ein erwartetes Ergebnis. Der ISTQB CTFL v4.0 Syllabus macht die Trennung noch schärfer: Testfälle beschreiben das «Was», Testprozeduren das «Wie».

Der ISTQB Advanced Level Test Analyst Syllabus (CTAL-TA v4.0) fordert Eindeutigkeit: Es soll nur eine Interpretation pro Testfall existieren. Mehrdeutige Begriffe wie «geeignet», «bei Bedarf» oder «mehrere» sollen vermieden werden. Ein Testfall mit einer IF/ELSE-Verzweigung hätte zwangsläufig mehrere Interpretationen, je nach Systemzustand beim Ausführen. Das widerspricht direkt dieser Forderung.

IEEE 829 (Standard for Software Test Documentation) spezifiziert Testfälle mit «exact input values» und «exact output values». ISO/IEC/IEEE 29119 Part 3 folgt demselben Schema: Vorbedingungen, konkrete Eingaben, Schritte, erwartete Ergebnisse. Part 5 widmet sich explizit dem Keyword-Driven Testing als Methode für deklarative Testbeschreibung.

Keiner dieser Standards sieht bedingte Verzweigungen innerhalb eines Testfalls vor.

Die gTAA-Architektur

Die Generic Test Automation Architecture (gTAA) aus dem ISTQB Advanced Level Test Automation Engineer Syllabus definiert die architektonische Trennung in Schichten. Die Test Definition Layer enthält Testfälle und Testdaten (deklarativ). Die Test Adaptation Layer verbindet mit dem System under Test über APIs und Protokolle (imperativ). Kontrollstrukturen werden erst in der Scripting-Technik «Structured Scripting» eingeführt und gehören zur Ausführungsschicht, nicht zur Testdefinition.

Keyword-Driven Testing wird im TAE-Syllabus als höchste Reifestufe der Testautomatisierung präsentiert. Die Begründung: Testdefinitionen werden so formuliert, dass Testanalysten sie leicht verstehen können.

Das RF Certified Professional (RFCP) Syllabus bildet Robot Framework explizit auf diese gTAA ab. .robot-Dateien entsprechen der Definition Layer. Python-Libraries entsprechen der Adaptation Layer. Die Architektur ist kein Zufall, sondern bewusst auf den ISTQB-Standard abgestimmt.

Conditional Test Logic als formaler Test-Smell

Gerard Meszaros hat in seinem Standardwerk «xUnit Test Patterns» (2007) Conditional Test Logic als formalen Test-Smell klassifiziert. Seine Argumentation: Code mit einem einzigen Ausführungspfad verhält sich immer gleich. Code mit mehreren Pfaden macht es erheblich schwerer, Vertrauen in die Korrektheit zu gewinnen. Tests mit Verzweigungen oder Schleifen sind nicht vollständig deterministisch. Kontrollstrukturen in Testmethoden verdienen laut Meszaros «extreme suspicion».

Der Google Testing Blog veröffentlichte 2014 den vielzitierten Beitrag «Don’t Put Logic in Tests» von Erik Kuefler. Die Kernaussage: In Tests zählt Einfachheit mehr als Flexibilität. Produktionscode beschreibt allgemeine Strategien zur Berechnung von Ausgaben. Tests sind konkrete Beispiele von Eingabe-Ausgabe-Paaren. Je mehr Operatoren, Schleifen und Bedingungen ein Test enthält, desto schwieriger wird es, seine Korrektheit sicherzustellen.

Das Buch «Software Engineering at Google» (Kapitel 12) erhebt «Don’t put logic in tests» zum Kernprinzip, gleichberechtigt mit «Test via public APIs» und «Test behaviors, not methods».

Martin Fowler argumentiert in «Eradicating Non-Determinism in Tests» (2011) grundsätzlich: Nicht-deterministische Tests sind nutzlos und eine virulente Infektion, die eine gesamte Test-Suite ruinieren kann.

Die Pfad-Explosion bei bedingter Logik

Die deutsche Testqualitätsfirma Qualicen hat das Problem quantifiziert. Jede IF-Bedingung in einem Testfall verdoppelt die möglichen Pfade. Vier Bedingungen ergeben 16 mögliche Pfade. Das Testergebnis wird nicht reproduzierbar, weil unklar bleibt, welcher Pfad tatsächlich durchlaufen wurde. Die Empfehlung: Aufteilen in separate Testfälle, je ein Pfad pro Testfall.

Dieses Prinzip ist so etabliert, dass es in statischen Analyseregeln formalisiert wurde. Das ESLint-Plugin für Jest enthält no-conditional-in-test. Playwright hat dieselbe Regel. QUnit nennt seine Variante no-conditional-assertions und begründet sie explizit mit der Erkennung nicht-deterministischer Tests.

Die offizielle RF-Position bestätigt den Ansatz

Die stärkste Bestätigung kommt direkt vom RF-Schöpfer. Das offizielle Dokument «How To Write Good Test Cases», gepflegt von Pekka Klärck und dem RF-Kernteam, formuliert ohne Spielraum: keine komplexe Logik auf Testfallebene, keine FOR-Schleifen oder IF/ELSE-Konstrukte. Testfälle sollen nicht wie Skripte aussehen. Maximal 10 Schritte, fachliche Sprache, verständlich für Product Owner und Kunden.

Im RF-Forum bestätigte Klärck: Wer die Top-Level-Testbeschreibung in Robot schreibt, kann alle Keywords in Python implementieren. Robin Mackaij, ein aktiver RF-Community-Contributor, formuliert es noch direkter: Für Testfälle ist Python eine schlechte Wahl. Er selbst packt den Grossteil der Logik in Python und nutzt RF als Runner-Framework.

QaSkills schreibt es explizit: Komplexe Logik gehört in Python-Keywords, nicht in die RF-Syntax. Das tabellarische Format ist nicht für Programmierung ausgelegt.

Rollentrennung löst das Zwei-Sprachen-Problem

Ein häufiger Einwand gegen RF lautet: Man müsse zwei Sprachen lernen. RF-Syntax und Python. Tesena beschreibt RF als weniger entwicklerfreundlich, weil ein tieferer Einstieg nötig sei. Im RF-Forum fragt ein Nutzer: Warum nicht direkt Python als Programmiersprache und RF nur als Support-Library?

Die Auflösung ist einfach, wenn die Architektur konsequent umgesetzt wird: Niemand lernt beide Sprachen.

Fachtester lernen RF-Syntax: Keywords aufrufen und Variablen übergeben. Das dauert zwei Stunden. Python-Entwickler schreiben die Keyword-Libraries in Python, das können sie sowieso. Product Owner lesen RF-Tests als fachliche Spezifikationen. Jede Rolle nutzt die Sprache, in der sie stark ist.

Jedes neue Programmiersprachen-Konstrukt in RF (VAR, IF, WHILE, TRY/EXCEPT) erhöht die Lernkurve für Fachtester. Beim reinen Keyword-Ansatz sinkt sie auf das Minimum. Xebia warnt in seiner dreiteiligen RF-Analyse: Wenn Nicht-Programmierer anfangen zu coden, entstehen erhebliche Stabilitäts- und Wartbarkeitsrisiken.

Python-Keywords in der Praxis

Die Architektur besteht aus zwei Schichten. In .robot-Dateien stehen Testfälle: fachliche Sprache, nur Keywords und Variablen, keine Kontrollstrukturen. In Python-Libraries steckt die gesamte technische Logik: beliebige Komplexität, volle Python-Funktionalität.

Ein häufig gehörtes Gegenargument lautet: User Keywords (in .robot-Dateien definiert) lassen sich aus Python nicht direkt aufrufen. Das stimmt. Es ist aber irrelevant, wenn Keywords als Python-Methoden mit dem @keyword-Decorator geschrieben werden. Solche Keywords sind reguläre Python-Funktionen. Sie lassen sich direkt aus anderen Python-Methoden aufrufen, ohne Umweg über BuiltIn().run_keyword(). Volle IDE-Unterstützung mit Typ-Hints, Autocomplete und Refactoring. Die Zwischenschicht von .robot-User-Keywords entfällt vollständig.

Ein konkretes Beispiel verdeutlicht den Ansatz. Die .robot-Datei enthält ausschliesslich fachliche Beschreibung:

*** Test Cases ***
Antragseingang Mit Gueltigem Datum Wird Verarbeitet
    Set Variable    ${Datum}    10.12.2024
    Antrag Einreichen Mit Datum    ${Datum}
    Bescheid Sollte Vorliegen
    Bescheid Datum Pruefen    ${Datum}

Die Python-Library implementiert die gesamte Logik. Validierung, Datenbankzugriff, Schnittstellenaufrufe, Fehlerbehandlung — alles in Python, alles testbar mit Standard-Python-Werkzeugen.

@keyword("Antrag Einreichen Mit Datum")
def antrag_einreichen_mit_datum(self, datum: str):
    parsed = self._parse_datum(datum)
    response = self.api_client.submit(antrag_datum=parsed)
    assert response.status == 200, f"Einreichung fehlgeschlagen: {response.status}"

Ein weiteres Argument betrifft das Logging: Python-Logik erscheine in log.html als opaker Keyword-Aufruf. In der Praxis stimmt das nicht. Python-Keywords nutzen robot.api.logger und können beliebig granular loggen. Fachlich benannte Keywords wie Antrag Einreichen oder Bescheid Pruefen sind im Log aussagekräftiger als IF/ELSE-Verzweigungen mit technischen Bedingungen.

RF jenseits von GUI-Tests

Die öffentliche Wahrnehmung von Robot Framework wird von GUI-Testing dominiert. Die populärsten Libraries sind SeleniumLibrary und Browser Library. Die meisten Tutorials behandeln Web-Automation. Vergleichsartikel stellen RF gegen Playwright oder Cypress.

Dieser Vergleich ist ein Kategoriefehler. Playwright und Cypress sind GUI-Test-Frameworks. In Szenarien mit heterogenen Schnittstellen (API, Datenbank, Messaging, Batch, Mainframe) sind sie nicht anwendbar. RF mit Python-Libraries kann jede Schnittstelle bedienen, weil die Library-Schicht beliebig erweiterbar ist.

Die Enterprise-Realität sieht anders aus als die Tutorial-Landschaft. KONE testet seit über 10 Jahren Embedded-Software für Aufzüge mit RF. Texas Instruments betreibt über 2 Millionen Testfälle für Taschenrechner-Firmware via XML-RPC-API. Altran (heute Capgemini Engineering) entwickelte die Mainframe3270-Library für IBM-Mainframe-Tests. SnapLogic veröffentlichte eine komplette RF-Integration für API-Tests, Datenbank-Operationen, Docker, JMS, Kafka und AWS. Sogeti berichtet von Erfahrungen mit RF in komplexen Systemlandschaften, einschliesslich API-Tests, End-to-End-Tests und Backend-Tests.

Die Unsichtbarkeit hat einen einfachen Grund. Texas Instruments erklärt es direkt: Die Software ist proprietär und kann nicht geteilt werden. Enterprise-Backend-Testautomatisierung existiert hinter verschlossenen Türen. Es gibt keine quantitative Erhebung, die die RF-Nutzung nach Testtyp aufschlüsselt.

Das Library-Ökosystem für Nicht-GUI-Szenarien ist breit aufgestellt. Für REST-APIs existiert die RequestsLibrary, für Datenbanken die DatabaseLibrary mit Support für Oracle, MySQL, PostgreSQL, SQLite und DB2. Mainframe-Tests deckt die Mainframe3270-Library ab, ursprünglich von Altran für IBM-3270-Terminals entwickelt. Für Messaging gibt es Libraries für RabbitMQ und Apache Kafka. Ab 2026 kommt eine neue MQLibrary für IBM MQ hinzu, die auf der RoboCon 2026 in Helsinki vorgestellt wird. SSH, Dateisysteme und Prozesse lassen sich über SSHLibrary, OperatingSystem und Process ansprechen.

Jede Python-Library, die über pip installierbar ist, lässt sich mit dem @keyword-Decorator in wenigen Zeilen als RF-Keyword exponieren. Die Erweiterbarkeit ist unbegrenzt, weil die Adaptation Layer reines Python ist.

Keyword-getriebene Tests und LLM-Verständlichkeit

RF-Keywords verwenden natürliche Sprache. Benutzer Sollte Angemeldet Sein oder Antrag Mit Datum Einreichen sind Sätze, die ein LLM als fachliche Beschreibung versteht. Das unterscheidet sich fundamental von Python-Testcode, den ein LLM als Programmierlogik interpretiert.

Eine ACM-Studie (EASE 2024) bestätigt: Strukturierte, keyword-ähnliche Testspezifikationen führen zu schnellerer und qualitativ besserer KI-generierter Testskripterstellung als unstrukturierte Ansätze. Eine Springer-Studie (2025) zeigt, dass die Kombination von RAG (Retrieval-Augmented Generation) mit LLMs die RF-Testqualität und -zuverlässigkeit signifikant verbessert.

LLMs verstehen Python als Code besser als RF-Syntax. Das ist unstrittig. Im Kontext fachlicher Semantik kehrt sich das Verhältnis aber um. Ein Keyword Vertrag Kuendigen Zum Monatsende transportiert fachliche Bedeutung unmittelbar. Die äquivalente Python-Methode cancel_contract_end_of_month() erfordert, dass das LLM erst Code-Semantik in Fachbedeutung übersetzt.

RF entwickelt sich weiter, der Testansatz bleibt

Robot Framework hat seit Version 4.0 systematisch Programmiersprachen-Konstrukte eingeführt. IF/ELSE (RF 4.0, 2021), TRY/EXCEPT und WHILE (RF 5.0, 2022), VAR-Syntax (RF 7.0, 2024). Die Community hat diese Features eingefordert: Die GitHub-Issues zu IF/ELSE und TRY/EXCEPT waren als «priority: critical» eingestuft.

Diese Entwicklung hat Gründe. Run Keyword If war objektiv problematisch: keine Verschachtelung, keine Mehrschritt-Logik. Viele RF-Nutzer arbeiten ohne Python-Unterbau. Für RPA-Szenarien (Robocorps früherer Kernmarkt) ist bedingte Logik auf RF-Ebene unverzichtbar.

Für den Ansatz «RF als Testbeschreibungsformat + Python als technische Schicht» ändert sich nichts. Set Variable funktioniert weiterhin. VAR ist nicht erzwungen. Die neuen Kontrollstrukturen sind verfügbar, aber nicht verpflichtend. Bestehender Code bricht nicht. Die offizielle Best-Practice-Empfehlung von Pekka Klärck bleibt unverändert: keine komplexe Logik auf Testfallebene.

Wer RF konsequent als Testbeschreibungsformat nutzt, profitiert von der Weiterentwicklung des Frameworks (Performance, JSON-Output, Python-3.14-Kompatibilität), ohne die Programmiersprachen-Features auf Testfallebene einsetzen zu müssen.

Quellen

Tests laufen mit IF/ELSE auf Testfallebene und werden zur Wartungslast? Im UTAA-Workshop trennen wir Testbeschreibung und Mechanik nach gTAA-Architektur. Mehr zur Methode oder direkt anfragen.