Robot Framework ist ein generisches, technologieagnostisches Automatisierungs-Framework, das auf dem Keyword-Driven-Testing-Ansatz basiert. Es bringt keine eigene Automatisierungstechnologie mit, sondern verbindet über Keyword-Libraries beliebige Technologien wie Selenium, Playwright oder Appium. Keywords lassen sich schichten: von technischen Low-Level-Aktionen bis zu fachlichen High-Level-Testschritten, ohne dass Nutzer Python-Code schreiben müssen.
Das Wichtigste in Kürze
- Robot Framework hat über drei Millionen Downloads pro Monat und einen Slack-Kanal mit 32.000 Mitgliedern, was es zu einem der meistgenutzten Open-Source-Testautomatisierungs-Frameworks weltweit macht.
- Die Robot Framework Foundation finanziert sich durch Mitgliedsbeiträge von rund 77 Unternehmen, darunter Cisco und Nokia, sowie durch die jährliche Robocon-Konferenz, was ein Budget von etwa 250.000 Euro pro Jahr ergibt.
- Robot Framework ist technologieagnostisch und lässt sich mit rund 700 Bibliotheken auf PyPI kombinieren, von Web- und Mobile-Tests über Datenbankanbindung bis hin zu Terminal-Emulationen wie 3270-Systemen.
- Wer Open Source nutzt, sollte Bugs melden, Fragen stellen und Dokumentation verbessern, denn Maintainer ohne direkten Kundenkontakt sind auf dieses Feedback angewiesen, um sinnvolle Weiterentwicklungen zu priorisieren.
- Firmen, die eigene Testbibliotheken entwickelt haben, können durch Open Sourcing dieser Lösungen von Fremdbeiträgen profitieren: Andere Unternehmen finanzieren dann Features, von denen alle Nutzer gleichzeitig profitieren.
Was ist das Robot Framework?
Das Robot Framework ist ein generisches, technologieagnostisches Automatisierungs-Framework. Es bringt keine eigene Automatisierungstechnologie mit, sondern dockt beliebige Technologien wie Selenium, Playwright oder Appium darunter an.
Ursprünglich war das Robot Framework als Keyword-Driven-Testing-Framework gedacht, explizit für abnahmetestgetriebene Entwicklung. Inzwischen ist der reine Testing-Fokus in den Hintergrund gerückt. Anforderungen aus der Community führten dazu, dass das Framework heute auch RPA und andere Automatisierungen abdeckt. Deshalb spricht man jetzt von einem generischen Automatisierungs-Framework.
Vom Aufbau her lässt sich das Robot Framework gut mit Cucumber vergleichen. Es gibt eine Spezifikationssprache und darunter Schritt-Implementierungen in einer anderen Sprache, meist Python. Das Framework führt den geparsten Text aus, ruft pro Schritt eine automatisierte Funktion auf, prüft den Rückgabewert und protokolliert das Ergebnis. Über einen Gherkin-Parser unterstützt das Framework auch behavior-driven Testing mit Given-When-Then und Feature-Files.
Wie funktioniert der Keyword-Driven-Ansatz?
Die Stärke des Robot Frameworks liegt darin, dass sich Testschritte in Schichten aufeinander aufbauen lassen. Aus kleinen Schritten entstehen größere, fachliche Bausteine.
Ein Beispiel macht das greifbar. Ein Low-Level-Keyword wie “Set Text” mit einem Lokator auf das Username-Feld lässt sich zu “Set Username” zusammensetzen. “Set Username”, “Set Password” und “Click Login” ergeben gemeinsam ein “Login User”. Darüber liegt dann ein High-Level-Keyword wie “Melde dich als Administrator an”.
Diese Kaskadierung hat eine praktische Folge: Wer von jemandem ein fertiges Klick-Keyword bekommt, kann daraus etwas Fachliches bauen, ohne selbst eine Zeile Code zu schreiben. Viele Nutzer schreiben Robot-Framework-Tests, ohne je Python angefasst zu haben, weil sie auf vorhandene Bibliotheken aufsetzen.
Wie viel Technik-Know-how brauchst du?
Fachexperten arbeiten gut mit dem Robot Framework, wenn sie eine gewisse Technik-Affinität mitbringen. Die Einstiegshürde liegt bewusst niedrig.
Die Syntax ist auf Lesbarkeit ausgelegt, ähnlich wie Gherkin. Keywords und Argumente werden durch zwei oder mehr Leerzeichen getrennt, ohne geschweifte Klammern oder funky Sonderzeichen. Genau solche Syntax-Hürden treiben Fachanwender sonst schnell weg.
Mit der Verfügbarkeit fachlicher und technischer High-Level-Keywords kommen Fachanwender weit. Die Beteiligung sinkt, sobald eigene Keywords in Robot-Framework-Syntax geschrieben werden müssen. Wer eigene Libraries implementiert, landet im Python-Code und braucht den typischen Testautomatisierer. Mehrere Tools setzen außerdem grafisch auf das Framework auf und erlauben es, Testsequenzen per Drag-and-drop zusammenzuklicken. Dahinter entsteht dann wieder Robot-Code.
Das Ökosystem ist die eigentliche Superkraft
Für nahezu jeden Anwendungsfall existiert eine passende Bibliothek. Im Robot Framework heißen diese Adapter Keyword Libraries.
Die Bandbreite reicht von App- und Web-Tests über Embedded-Testing bis zu Terminal-Emulationen. Es gibt sogar eine 3270-Library, mit der sich Greenscreen-Host-Systeme testen lassen. Auf PyPI finden sich an die 700 Projekte rund um das Robot Framework, auf GitHub ist es als eigene Sprache gelistet.
Hier liegt der Unterschied zu Selenium oder Playwright. Diese sind erst einmal nur Fernsteuertechnologien für das System under Test. Um daraus einen Testschritt zu bauen, braucht es eine Abstraktionsschicht, den Glue-Code zwischen Treiber und fachlichem Keyword. Die Selenium Library zum Beispiel, eine der ältesten Bibliotheken, bringt rund 150 technische Keywords wie “Type Text”, “Get Title” oder “Title Should Be” mit. Aus dieser Historie ist ein riesiges Bibliotheks-Ökosystem gewachsen.
Warum ist das Robot Framework für End-to-End-Tests stark?
Das Robot Framework spannt einen Schirm über beliebige Technologien und eignet sich damit für echte End-to-End-Tests. Genau das können auf Web fokussierte Werkzeuge nicht leisten.
Reale Systeme bestehen selten aus einer einzigen Anwendung. Eine Desktop-App hat einen Server, eine Datenbank, ein API, vielleicht ein Mobile Device oder angebundene IoT-Sensoren. Ein Werkzeug wie Cypress deckt nur das Web-Frontend und etwas API-Testing ab. Es kann keine Datenbank anbinden und keine Desktop-WPF-Applikation testen.
Verschiedene Adapter lassen sich kombinieren und über eine gemeinsame Keyword-Plattform steuern: Web, Desktop, App, Datenbank. Vor einem Test kannst du etwa einen Datenbank-Dump einspielen und anschließend die Oberfläche prüfen. Du bleibst in einer Sprache und bedienst trotzdem die gesamte Systemlandschaft.
Auch eigene Technologien lassen sich anbinden. Wer C# statt Python bevorzugt, baut einen entsprechenden Adapter und eigene Bibliotheken für komplexe Testobjekte mit eigenen APIs. Fertige Bibliotheken für andere Teile des Systems, etwa eine Webseite, lassen sich daneben weiter nutzen.
Wie testest du datengetrieben?
Datengetriebenes Testen funktioniert über den Robot Framework Data Driver. Damit definierst du einen einzigen Test und gibst eine Datenquelle an, aus der das Framework zur Laufzeit für jede Zeile einen eigenen Testfall erzeugt.
Diese Testfälle landen anschließend einzeln im Report. Der Data Driver lädt im Standardfall CSV und XLSX. Er kann PICT anbinden, ein Open-Source-Tool von Microsoft für Pairwise-Testing, und eigene Data Reader unterstützen. Manche Anwender haben Reader gebaut, die ihre Testdaten direkt aus einer Datenbank ziehen.
Der Anwendungsfall stammt aus der Praxis. Versicherungen müssen oft die gleiche Testsequenz mit hunderten Tarif-Datensätzen und vielen Parametern durchspielen. Für Datenbanken selbst gibt es daneben eine Database Library auf SQL-Basis, die von DB2 über MySQL bis Oracle beliebige Datenbanken anbindet.
Wie finanziert sich ein Open-Source-Projekt wie dieses?
Die Robot Framework Foundation trägt die Weiterentwicklung und finanziert sich über Mitgliedsbeiträge und die jährliche Konferenz. Das Jahresbudget liegt bei rund 250.000 Euro.
Der finnische Verein wurde 2015 gegründet, von sechs konkurrierenden Consulting-Unternehmen plus Nokia, die gemeinsam Geld in einen Topf legten. Heute hat die Foundation rund 76 bis 77 Mitglieder, darunter Cisco, DB Schenker, die NRW Bank, die Landeshauptstadt München und Fresenius Medical Care.
Die Beiträge sind gestaffelt. Eine Einmann-Beratung zahlt 500 Euro im Jahr, Unternehmen beginnen bei 1.500 Euro und steigern sich über 3.000, 6.000 bis zu 12.000 Euro. Der Hebel ist deutlich: Auf jeden eingezahlten Euro kommen rund 70 weitere aus der Gemeinschaft. Die zweite Einnahmequelle ist die Konferenz RoboCon in Helsinki.
Mit dem Geld bezahlt die Foundation einen Vollzeit-Mitarbeiter für Marketing und Organisation sowie zwei Kernentwickler als Freiberufler, darunter den ursprünglichen Erfinder Pekka Klärck. Sie reviewen Pull Requests, prüfen Qualitätsstandards und pflegen die Dokumentation.
Eine breite Basis schützt vor dem toten Pferd
Eine Community mit vielen Trägern ist das beste Risikomanagement für ein Open-Source-Projekt. Wer auf ein Framework setzt, sollte wissen, dass es nicht morgen aufhört.
Die Gefahr ist real. Gauge von ThoughtWorks wurde irgendwann nicht mehr finanziert. SpecFlow ist faktisch tot und lebt nur als Fork weiter. Cucumber Inc. kaufte die Namensrechte und entließ später die Mitarbeiter, die Cucumber implementierten. Cucumber überlebt vor allem, weil seine Community zu groß zum Scheitern ist.
Mit diesen rund 70 Mitgliedern hast du eine massive Basis. Selbst wenn ein Boardmember aufhört, stehen sieben andere da, die weitermachen. Und wenn die gehen, kommen neue nach. René Rohner
Beim Robot Framework verteilt sich die Last auf viele Schultern, im Foundation-Board ebenso wie in den freiwilligen Arbeitsgruppen für Syllabus, Webseite und Dokumentation. Mit über drei Millionen monatlichen Downloads und einem Slack-Kanal mit 32.000 Mitgliedern ist das Projekt vital.
Open-Source-Beitrag fängt beim Fragen an
Du musst kein guter Coder sein, um zu einem Open-Source-Projekt beizutragen. Feedback, Bug-Reports und Dokumentation sind oft genauso wertvoll wie Code.
Viele Nutzer schweigen aus einer falschen Hemmung. Sie denken, sie hätten die Software ja geschenkt bekommen und dürften sich nicht beschweren. Maintainer haben aber keine Kunden, die ihnen Anforderungen liefern. Sie sitzen im eigenen Saft und wissen oft nicht, welches Feature als Nächstes fehlt. Wer höflich sagt, wo die Schmerzpunkte liegen, hilft dem Projekt direkt.
Konkrete Beitragswege ohne Code:
- Fragen stellen im Slack-Kanal oder per Issue
- Bugs reporten, gerade als Tester eine naheliegende Stärke
- Feature-Requests formulieren
- Dokumentation verbessern, etwa per Pull Request, wenn etwas unklar war
Die Browser Library macht das sichtbar. Über einen Contribution-Bot landet jeder, der ein Ticket eröffnet, einen Bug meldet, Code oder Doku beisteuert oder Geld einzahlt, auf einer Wall of Fame. So werden hunderte Beiträge sichtbar.
Gebt die coole Lösung zurück in die Gemeinschaft
Beratungsunternehmen können selbst entwickelte Bibliotheken open-sourcen, statt sie im eigenen Keller verstauben zu lassen. Das schafft einen Mehrwert, der sich über mehrere Kunden multipliziert.
RoboSapiens zeigt das Modell. Die Bibliothek automatisiert SAP-GUIs und wurde von einem Kunden vollständig bezahlt. Auf gemeinsame Idee hin wurde sie open-source gestellt. Ein zweiter Kunde fand sie nützlich und finanzierte ein weiteres Feature, von dem der erste Kunde kostenlos profitierte. Ein dritter Kunde legte ebenfalls nach.
Wenn du etwas baust, das du ohnehin nicht verkaufen würdest, prüfe das Open-Sourcen als Option. Achte darauf, keine Firmendaten direkt in den Code zu schreiben, sondern die Lösung anonym zu halten. Es tut weniger weh, als die meisten befürchten, und du kannst dich dazu beraten lassen.
Wohin entwickelt sich das Robot Framework?
Das Robot Framework wurde über die letzten Jahre stark refactored und in der Technologiebasis erweitert. Wer es zuletzt 2018 angeschaut hat, sollte einen zweiten Blick wagen.
Besonders die Tooling-Unterstützung ist gewachsen. Für Visual Studio Code gibt es eine vollwertige IDE mit Step-Debugging im Python- wie im Robot-Code, vollständiger Auto-Completion und statischer Code-Analyse per Linter. Eine bessere PyCharm-Integration ist in Arbeit und wird von der Foundation mitfinanziert, weil viele Nutzer aus der Python-Welt damit arbeiten.
Robot Framework 8 ist für das kommende Jahr geplant, mit einigen API-Features für anspruchsvolle Anwender. Ein großes Killer-Feature im Kern steht nicht an, und das ist Absicht. Das Framework ist stark dezentralisiert. Echte Neuerungen entstehen oft in einzelnen Bibliotheken wie der Browser Library, ohne den Kern zu berühren.
