Robot Framework ist ein Open-Source-Framework für Testautomatisierung mit einem generischen, erweiterbaren Kern. Dieser Kern übernimmt Parsing, Ausführung, Logging und Reporting, das Team implementiert nur noch den Teil, der für das eigene System unter Test spezifisch ist. Am stärksten ist das Framework in heterogenen Umgebungen mit Web-, Datenbank-, API- und Embedded-Schnittstellen. Über seine standardisierte Bibliotheks-API ist ein Ökosystem aus Hunderten fertiger Erweiterungen und Editor-Integrationen entstanden.
Das Wichtigste in Kürze
- Der generische Kern von Robot Framework erledigt Parsing, Ausführung, Logging und Reporting einheitlich. Ein Team löst nur noch das Schnittstellenproblem des eigenen Systems.
- Editoren, Bibliotheken und Integrationen bringen im Alltag mehr als der Kern allein, und dieses Ökosystem wächst auch ohne Pekka Klärcks direktes Zutun.
- Robot Framework passt am besten zu heterogenen Umgebungen. Für ein reines Webprojekt, in dem das ganze Team TypeScript schreibt, ist ein natives Tool wie Playwright meist die bessere Wahl.
- Fast 7.000 Robot-Framework-Testfälle testen Robot Framework selbst, auch dort, wo Unit-Test-Werkzeuge eigentlich näherlägen.
- Die Robot Framework Foundation hat über 80 Mitgliedsunternehmen. Deutlich mehr Firmen nutzen das Framework, ohne etwas beizutragen, und das gefährdet auf Dauer die bezahlte Kernentwicklung.
Woher Robot Framework kommt: eine Masterarbeit aus Helsinki
Robot Framework begann 2004 als Masterarbeit von Pekka Klärck an der Technischen Universität Helsinki. Klärck kam aus der Praxis: In mehreren Projekten hatte er Frameworks für Softwaretest und Testautomatisierung von Grund auf gebaut. Jedes Mal löste er dieselben Probleme, und jedes Mal fing er wieder bei null an.
Seine Masterarbeit ging deshalb einer praktischen Frage nach: Lassen sich die Teile, die sich ständig wiederholen, wiederverwendbar machen? Beim Durcharbeiten der Literatur zur Testautomatisierung und beim Bauen von Prototypen merkte er, dass mehr möglich war als ein Baukasten aus Komponenten. Der Kern eines Frameworks konnte generisch sein, und diesen Kern ließ sich mit wiederverwendbaren Bibliotheken erweitern.
Ein echtes Zuhause fand die Idee bei Nokia Networks. Petri Haapio, ein früherer Kollege, war dort eingestiegen und suchte eine Automatisierungslösung für eine heterogene Umgebung. Interne APIs gab es nicht, und auf dem kommerziellen Markt fand sich nichts Passendes. Aus den Prototypen wurde ein funktionierendes Framework, das sich danach intern auf weitere Bereiche ausbreitete.
2008 gab Nokia Networks das Framework als Open Source frei und finanzierte die Entwicklung bis 2015. Danach änderte sich das Finanzierungsmodell.
Wer Robot Framework heute pflegt
Heute steht die Robot Framework Foundation hinter dem Projekt, ein finnischer Verein, der die Entwicklung finanziert. Nokia ist ein Mitglied unter vielen. Inzwischen zählt die Foundation rund 85 Mitglieder, und der Anteil aus Deutschland und den Niederlanden wächst.
Gegründet wurde sie aus der Not. Mehrere finnische Beratungshäuser verkauften Dienstleistungen rund um Robot Framework und sahen kommen, dass Nokias direkte Förderung auslaufen würde. Ein Open-Source-Produkt ohne Pflege ist ein Problem für jeden, der darauf ein Geschäft aufbaut. Also taten sich Wettbewerber mit einem gemeinsamen Interesse zusammen und gründeten vor gut zehn Jahren die Foundation, um das Projekt am Leben zu halten.
Damit wurde aus einem firmengetriebenen Projekt eine neutrale Organisation. Für die Verbreitung zählt diese Neutralität, denn niemand hängt mehr von den Prioritäten eines einzelnen Anbieters ab.
Was Robot Framework eigentlich macht
Robot Framework übernimmt das, was in fast jedem Automatisierungsprojekt gleich ist. Es liest Testdaten in seiner eigenen Syntax ein, führt sie aus, bietet eine standardisierte API für Erweiterungen und erzeugt Logs und Reports in einem einheitlichen Format.
Am deutlichsten wird der Nutzen, wenn du eine Automatisierung von Grund auf aufbaust. Du erfindest kein eigenes Datenformat, kein eigenes Reporting und keinen eigenen Weg, mit dem System zu sprechen. Du kümmerst dich nur noch um die Interaktion mit dem System. Das Datenformat liefert Robot Framework. Das Reporting liefert Robot Framework. Den Rest bekommst du geschenkt.
Weil das Format gemeinsam genutzt wird und generisch ist, ist rundherum gutes Tooling entstanden. Für VS Code und PyCharm gibt es Plugins, die die Syntax verstehen. Mit einem selbst erfundenen Format säßest du im reinen Texteditor fest.
Wann Robot Framework die richtige Wahl ist und wann nicht
Robot Framework spielt seine Stärken in heterogenen Umgebungen aus. Umfasst dein System Weboberflächen, Datenbanken, REST-APIs, Embedded-Systeme und eigene Schnittstellen, bringt das Framework für viele davon fertige Bibliotheken mit und steuert alles von einer Stelle aus. Im größeren Feld der Testautomatisierung ist das seine eigentliche Nische.
Die richtige Wahl ist es nicht immer, und das sagt Pekka auch offen. Testest du eine einzelne Webanwendung und schreibt dein ganzes Team TypeScript, ist ein Tool wie Playwright vermutlich besser. Das Team kennt die Werkzeuge schon, und die Vorteile von Robot Framework schrumpfen.
Ein Vorteil bleibt allerdings auch dann. Müssen Stakeholder die Testfälle lesen und verstehen, schreibst du sie mit Robot Framework als einfache, gut lesbare Sätze und bekommst trotzdem Log und Report dazu. Entscheidend ist am Ende, wie viele unterschiedliche Schnittstellen und wie viel individuelle Integration dein Kontext verlangt.
“Ich weiß selbst sehr gut, dass es nicht für jedes Projekt die richtige Wahl ist. Ich will also nicht sagen, dass jeder es benutzen sollte.”
(Pekka Klärck)
Was sich in zwanzig Jahren verändert hat
Der größte technische Schritt war der Abschied von Testdaten in HTML-Tabellen. Version 1 lief nur intern. Version 2, die erste Open-Source-Version, speicherte die Testdaten noch in HTML, und das war mühsam zu bearbeiten und mühsam zu versionieren. Mit dem Wechsel auf ein reines Textformat wurde beides einfacher.
Ein späterer Neubau des Parsers hatte größere Folgen, als die Release Notes vermuten ließen. Der ursprüngliche Parser kam mit HTML- und Textdateien zurecht, war nach Pekkas eigener Aussage aber ziemlich grob. Sein Nachfolger brachte eine saubere Parsing-API und ein solides Parsing-Modell.
Genau diesem Modell verdanken die Editoren, dass sie so gut funktionieren. Sie nutzen dasselbe Modell und kennen jedes Token in den Daten. Was nach interner Umbauarbeit aussah, hat eine ganze Kategorie von Werkzeugen möglich gemacht.
Das Ökosystem ist größer als der Kern
Am meisten stolz ist Pekka auf das Ökosystem, gerade weil er es nicht selbst steuern muss. Die Entscheidungen rund um Schnittstellen und Erweiterungspunkte erlauben es der Community, auf dem Framework aufzubauen, ohne jemanden um Erlaubnis zu fragen.
Auf den Kern reduziert wäre Robot Framework immer noch nützlich, für Teams, die alle Bibliotheken selbst schreiben. Ohne die Editoren, die fertigen Bibliotheken und die Anbindungen an Testmanagement-Systeme wäre es aber ein anderes und viel kleineres Angebot. Praxistauglich wird es durch das Ökosystem.
Der Nutzen kommt dabei meist mit Verzögerung. Ein Release bringt eine erweiterte API, die für sich allein unscheinbar wirkt. Monate später, manchmal ein Jahr später, tauchen neue Werkzeuge auf, die darauf aufsetzen. Eine Änderung an der Listener-Schnittstelle vor knapp zwei Jahren hat zum Beispiel selbstheilende Listener möglich gemacht, die Locatoren zur Laufzeit reparieren.
Zum Ökosystem gehören weit über hundert Erweiterungen, auch wenn viele ältere nicht mehr gepflegt werden. Selbst eine verwaiste Bibliothek kann einen Blick wert sein. Du kannst ihre Ideen übernehmen, sie selbst weiterpflegen oder etwas Neues darauf aufbauen.
Warum Downloadzahlen wenig aussagen
Die Downloadzahlen von Robot Framework im Python Package Index sind aufgebläht und als genaues Maß fast wertlos. CI-Systeme installieren das Paket wieder und wieder, die Rohzahl geht in die Millionen pro Monat und sagt trotzdem nichts darüber, wie viele echte Nutzer es gibt.
Was die Zahlen zeigen, ist ein Trend. Sie liegen heute weit höher als vor ein paar Jahren, das deutet auf Wachstum hin. Der exakten Zahl kannst du nicht trauen.
Die Besuche auf der Website gehen Berichten zufolge zurück. Das klingt beunruhigend, bis man die wahrscheinliche Ursache betrachtet: Viele stellen ihre Fragen zu Robot Framework inzwischen einem KI-Tool, statt die Dokumentation aufzurufen. Die KI hat das Material längst gelesen, die Antwort kommt ohne Seitenbesuch.
Die Roadmap: Secrets, Dokumentation und ein bekannter Designfehler
Das nächste Release bringt geheime Variablen. Ein geheimer Wert, der als Argument übergeben oder von einem Keyword zurückgegeben wird, landet in keinem Log-Level, egal wie ausführlich geloggt wird. Außerdem kannst du Keywords definieren, die nur geheime Werte annehmen. Das hilft in regulierten Umgebungen, in denen Passwörter und Tokens auf keinen Fall in Logs auftauchen dürfen.
Die Funktion geht zum Teil auf einen Community-Beitragenden bei der finnischen Bank OP zurück. Er bekam von seinem Arbeitgeber Arbeitszeit dafür, weil der Anwendungsfall dort wichtig war. Nach dem Release rückt der User Guide in den Fokus, ein ausführliches Referenzhandbuch auf alter Technik, das eine einzige übergroße HTML-Datei erzeugt. Der Plan: modernisieren und auf veraltete Inhalte durchsehen.
Ein späteres Release der 7er-Reihe bringt voraussichtlich Markdown-Unterstützung für die Dokumentation. Mehrere Dokumentationsformate kann Robot Framework schon, Markdown aber nicht, obwohl es sich zum De-facto-Standard entwickelt hat und KI-Tools damit arbeiten.
Die schwierigste Baustelle ist ein bekannter Designfehler bei den Namensräumen für Keywords und Variablen, die über Ressourcendateien importiert werden. Pekka hat sie selbst entworfen und nennt das Design ohne Umschweife schlecht. Um es zu beheben, muss das Verhalten neu entworfen und umgesetzt werden, und die alten Wege müssen mit Deprecation-Warnungen weiter funktionieren, statt bestehende Tests über Nacht zu zerschießen. Die Abwärtskompatibilität macht das Ganze langsam.
Wie Robot Framework sich selbst testet
Robot Framework wird mit Robot Framework getestet. Das Projekt pflegt fast 7.000 Robot-Framework-Testfälle für das Framework selbst und dazu mehrere hundert Unit-Tests.
Für manche dieser Fälle wären klassische Unit-Test-Werkzeuge besser geeignet, und Pekka weiß das. Das Team treibt das eigene Framework bewusst bis an die Grenze, um zu sehen, wie es sich dort schlägt, wo ein anderes Werkzeug natürlicher wäre. In einem normalen Projekt würdest du an diesen Stellen zu Unit-Test-Werkzeugen greifen.
Gemessen an der Größe der Codebasis und an dem, was sie leistet, kommen relativ wenige Fehlerberichte herein. Das liegt an pedantischer Programmierung und an einer Foundation, die keine überhasteten Releases verlangt. Wer technische Schulden gar nicht erst anhäufen muss, hält die Codebasis stabil, statt halbfertige Funktionen mit Pflastern zu bekleben.
Der Busfaktor eines Ein-Personen-Kerns
Den Kern von Robot Framework entwickelt im Wesentlichen eine Person, und Pekka nennt das selbst ein Risiko. Der Code ist in gutem Zustand, deshalb fürchtet er nicht, dass das Projekt stirbt, wenn ihm etwas zustößt. Gesünder wäre es aber mit mehr Leuten, die den Kern gut kennen.
Die meisten Beiträge fließen ins Ökosystem und nicht in den Kern, und dort ist Mithelfen auch am einfachsten. Du musst keine Designentscheidungen mit dem Maintainer abstimmen, du nutzt die öffentlichen APIs und baust los. Auch der Kern bekommt Beiträge, nur deutlich weniger.
Langfristig soll eine Gruppe entstehen, die den Kern gut genug versteht, um Pull Requests zu reviewen und über knifflige Designentscheidungen zu diskutieren. Eine nachhaltige Finanzierung über die Foundation gehört dazu, denn sie kann angestellte Beitragende für ihre Arbeitszeit ebenso bezahlen wie selbstständige Entwickler für einzelne Aufträge.
Wie du das Projekt unterstützen kannst
Am direktesten hilfst du, indem du davon erzählst. Pekka will nicht, dass alle Robot Framework einsetzen. Er will, dass Teams wissen, dass es existiert, damit sie es bei der Auswahl einer Automatisierungslösung ehrlich gegen die Alternativen abwägen können. Wer es nicht kennt, wählt es nie, auch wenn es besser passen würde.
Wie bekannt das Framework ist, hängt stark vom Land ab. In Deutschland kennt es ein großer Teil der Branche. In Thailand und Brasilien sind aktive Communities entstanden, oft mit wenig direktem Kontakt, meist weil jemand es gelernt und in der eigenen Sprache darüber geschrieben hat. Im Nachbarland Dänemark dagegen kennen es womöglich viele gar nicht.
Die zweite konkrete Form der Unterstützung ist eine Mitgliedschaft in der Foundation. Die Beiträge sind moderat, niedriger als eine einzige kommerzielle Lizenz vieler Testwerkzeuge, und sie finanzieren die nachhaltige Entwicklung und Ökosystem-Projekte wie den Editor. Mehr als 80 Unternehmen sind Mitglied, viele weitere nutzen das Framework, ohne etwas zurückzugeben.
Die RoboCon als Treffpunkt
Die RoboCon ist die Konferenz des Projekts. Zum Zeitpunkt des Gesprächs 2025 war die nächste Ausgabe vor Ort in Helsinki für Februar 2026 geplant, mit einer Online-Ausgabe im März. Zu den letzten Präsenzausgaben kamen etwa 300 bis 350 Leute, vor der Pandemie waren es eher 500.
Die Ausgabe 2026 war bereits in Finnland gebucht, die übernächste sollte sehr wahrscheinlich ebenfalls dort bleiben, denn es wäre die zehnte, und die Planung hat einen langen Vorlauf. Danach überlegen die Veranstalter, die Konferenz nach Deutschland oder in ein anderes Land mit großer Nutzerbasis zu holen, um Leute zu erreichen, die zum ersten oder zweiten Mal dabei sind. Zwei parallele Konferenzen kommen nicht in Frage, weil sie die Community spalten würden.
Mit einem Ticket für die Online-Konferenz bekommst du auch Zugang zu den Vorträgen vor Ort. Die Aufzeichnungen erscheinen nach und nach über die Jahre verteilt. Wer einen bestimmten Vortrag bald sehen will, muss also dabei sein. Vor Ort triffst du die vertrauten Gesichter und die Atmosphäre, und Neulinge sind ausdrücklich willkommen.
Häufig gestellte Fragen
Warum ein generisches Testautomatisierungsframework nutzen, anstatt eines von Grund auf neu zu entwickeln?
Ein generischer Kern übernimmt die Aufgaben, die sich in jedem Automatisierungsprojekt wiederholen: das Parsen von Testdaten, deren Ausführung, die Testprotokollierung und die Berichterstellung. Was übrig bleibt, ist der schnittstellenspezifische Teil, also die Interaktion mit deinem eigenen System. Ein gemeinsames Datenformat zieht zudem entsprechende Tools an. Editor-Plugins für VS Code und PyCharm verstehen die Syntax, während du bei einem selbst entwickelten Format auf einen einfachen Texteditor angewiesen bist.
Wer finanziert die Entwicklung des Robot Framework?
Die Robot Framework Foundation, ein finnischer Verein mit rund 85 Mitgliedern, fördert die Arbeit. Nokia Networks hat 2008 die Veröffentlichung des Frameworks als Open Source genehmigt und dessen Entwicklung bis 2015 finanziert. Mehrere konkurrierende finnische Beratungsunternehmen haben daraufhin die Stiftung gegründet, um das Projekt am Leben zu erhalten. Die Mitgliedsbeiträge sind moderat und liegen unter dem Preis einer einzelnen kommerziellen Lizenz für viele Tools zum Testen.
Sollte ein Team, das bereits mit TypeScript arbeitet, Robot Framework für Browser-Tests nutzen?
Wahrscheinlich nicht. Für eine einzelne Webanwendung und ein Team, das sich mit TypeScript auskennt, ist ein natives Tool wie Playwright in der Regel die bessere Wahl, da das Team mit dem Tool vertraut ist und die Vorteile des Frameworks dadurch schwinden. Ein Argument kann dennoch den Ausschlag geben: Wenn Stakeholder die Testfälle lesen müssen, sind einfache, für Menschen lesbare Sätze sowie das Standardprotokoll und der Standardbericht von Wert.
Zeigen die Zahlen zu den Paket-Downloads, wie viele Leute ein Test-Framework nutzen?
Nein. Systeme der kontinuierlichen Integration installieren Pakete immer wieder neu, sodass die Zahlen von Robot Framework aus dem Python Package Index monatlich in die Millionen gehen, ohne etwas über die tatsächlichen Nutzer auszusagen. Nur der Trend ist aussagekräftig, und der zeigt im Vergleich zu vor ein paar Jahren nach oben. Sinkende Zugriffszahlen auf die Dokumentation täuschen in gleicher Weise, da viele Fragen stattdessen an KI-Tools gerichtet werden.
Warum ist das Ökosystem rund um ein Test-Framework wichtiger als sein Kern?
Auf den Kern reduziert bleibt Robot Framework zwar für Teams verwendbar, die alle ihre Bibliotheken selbst schreiben, aber es wäre ein viel kleineres Angebot. Weit über hundert Erweiterungen, Editor-Plugins und Integrationen in Testmanagement-Systeme machen es im Arbeitsalltag praktisch einsetzbar. Viele ältere Bibliotheken werden nicht mehr gepflegt; ihre Ideen lassen sich jedoch nach wie vor wiederverwenden, wiederbeleben oder weiterentwickeln.
Macht es Sinn, ein Test-Framework mit sich selbst zu testen?
Robot Framework unterhält fast 7.000 eigene Testfälle sowie mehrere hundert Unit-Tests. Einige dieser Fälle würden technisch gesehen besser zu reinen Unit-Test-Tools passen, und das ist beabsichtigt: Das Team treibt das eigene Framework bis an seine Grenzen, um zu sehen, wie es sich bewährt. In einem normalen Projekt würdest du an diesen Stellen auf Unit-Test-Tools zurückgreifen.
Wie können automatisierte Tests mit Passwörtern umgehen, ohne dass diese in den Logs auftauchen?
Eine kommende Version von Robot Framework führt geheime Variablen ein. Ein Geheimnis, das als Argument übergeben oder von einem Schlüsselwort zurückgegeben wird, wird auf keiner Protokollstufe geschrieben, egal wie detailliert die Protokollierung ist, und Schlüsselwörter können so definiert werden, dass sie nur geheime Werte akzeptieren. Die Funktion stammt von einem Mitwirkenden bei der finnischen Bank OP, wo der vorschriftsmäßige Umgang mit Passwörtern und Tokens eine wichtige Rolle spielte.
Wie riskant ist es, wenn eine einzige Person den Kern eines Open-Source-Werkzeugs entwickelt?
Pekka Klärck bezeichnet den von einem einzigen Maintainer gepflegten Kern als echtes Risiko, auch wenn der Code in gutem Zustand ist, sodass er nicht damit rechnet, dass das Projekt stirbt. Das erklärte Ziel ist eine Gruppe, die den Kern gut genug kennt, um Pull Requests zu prüfen und komplizierte Designentscheidungen zu diskutieren. Die meisten Beiträge fließen stattdessen in das Ökosystem, wo öffentliche APIs keiner Koordination bedürfen.
