Robot Framework ist ein Open-Source-Framework für die Testautomatisierung, das um einen generischen, erweiterbaren Kern herum aufgebaut ist, der das Parsen, die Ausführung, die Protokollierung und die Berichterstattung übernimmt, sodass Teams nur die Teile implementieren müssen, die für ihr System unter Test spezifisch sind. Es eignet sich besonders gut für heterogene Umgebungen mit Web-, Datenbank-, API- und eingebetteten Schnittstellen, und seine standardisierte Bibliotheks-API hat ein Ökosystem mit Hunderten von vorgefertigten Erweiterungen und Editor-Integrationen hervorgebracht.
Das Wichtigste in Kürze
- Der generische Kern des Robot Frameworks übernimmt einheitlich das Parsen, Ausführen, Protokollieren und Berichten, so dass Teams nur das schnittstellenspezifische Problem für ihr eigenes System lösen müssen.
- Das Ökosystem aus Editoren, Bibliotheken und Integrationen hat einen größeren praktischen Wert als das Kern-Framework allein und wächst unabhängig von Pekka Klärcks direkter Beteiligung.
- Robot Framework passt am besten zu heterogenen Umgebungen; für ein reines Webprojekt, bei dem das gesamte Team TypeScript schreibt, ist ein natives Tool wie Playwright wahrscheinlich die bessere Wahl.
- Fast 7.000 Testfälle von Robot Framework werden verwendet, um Robot Framework selbst zu testen, auch in Fällen, in denen Unit-Testing-Tools technisch gesehen die bessere Wahl wären.
- Die Robot Framework Foundation hat über 80 Mitgliedsunternehmen, doch weit mehr Unternehmen nutzen das Framework, ohne einen finanziellen Beitrag zu leisten, was die langfristige Nachhaltigkeit der bezahlten Kernentwicklung gefährdet.
Woher kommt Robot Framework?
Robot Framework entstand 2004 als Masterarbeit an der Helsinki University of Technology. Pekka Klärck hatte bereits in der Industrie an Softwaretests und Testautomatisierung gearbeitet und für verschiedene Projekte Automatisierungsframeworks von Grund auf neu entwickelt. Bei all diesen Projekten löste er immer wieder dieselben Probleme, obwohl er jedes Mal alles neu baute.
In seiner Diplomarbeit stellte er sich eine praktische Frage: Könnte man die sich wiederholenden Teile wiederverwendbar machen? Beim Studium der vorhandenen Literatur zur Testautomatisierung und beim Bau von Prototypen wurde Pekka klar, dass mehr als nur ein Werkzeugkasten mit Komponenten möglich war. Der Kern eines Frameworks könnte generisch sein, und man könnte diesen Kern mit wiederverwendbaren Bibliotheken erweitern.
Die Idee fand bei Nokia Networks ihren ersten richtigen Platz. Ein ehemaliger Kollege, Petri Haapio, war in das Unternehmen eingetreten und brauchte eine Testautomatisierungslösung für eine heterogene Umgebung, in der es keine internen APIs und nichts Geeignetes auf dem kommerziellen Markt gab. Die Prototyp-Idee wurde dort zu einem funktionierenden Framework und verbreitete sich dann intern in anderen Bereichen.
Nokia Networks erteilte 2008 die Erlaubnis, das Framework als Open Source zu veröffentlichen und förderte seine Entwicklung bis 2015. Danach änderte sich das Finanzierungsmodell.
Wer pflegt das Robot Framework jetzt?
Robot Framework wird von der Robot Framework Foundation gepflegt, einer finnischen Vereinigung, die die Entwicklung fördert. Nokia ist ein Mitglied unter vielen, und die Stiftung zählt inzwischen rund 85 Mitglieder, mit einem wachsenden Anteil aus Deutschland und den Niederlanden.
Die Stiftung wurde aus der Not heraus gegründet. Mehrere finnische Beratungsunternehmen verkauften Dienstleistungen rund um das Robot Framework, und sie sahen das Ende der direkten Förderung durch Nokia kommen. Ein Open-Source-Produkt ohne Wartung ist für jeden, der darauf aufbauende Dienstleistungen verkauft, ein Problem. Konkurrenten mit einem gemeinsamen Interesse gründeten vor etwas mehr als zehn Jahren die Stiftung, um das Projekt am Leben zu erhalten.
Dadurch wurde aus einem unternehmensgesteuerten Projekt eine neutrale Organisation. Diese Neutralität ist für die Akzeptanz wichtig, weil sie die Abhängigkeit von den Prioritäten eines einzelnen Anbieters beseitigt.
Was Robot Framework eigentlich macht
Robot Framework übernimmt die Aufgaben, die für fast alle Automatisierungsprojekte gleich sind. Es analysiert Testdaten, die in seiner eigenen Syntax geschrieben wurden, führt diese Daten aus, stellt eine standardisierte API für Erweiterungen zur Verfügung und erstellt Protokolle und Berichte in einem einheitlichen Format.
Der Nutzen zeigt sich am deutlichsten, wenn du die Automatisierung von Grund auf neu entwickelst. Anstatt dein eigenes Datenformat, deine eigene Berichterstattung und deine eigene Art der Interaktion mit dem System zu erfinden, kümmerst du dich nur um die Systeminteraktion. Das Datenformat kommt aus dem Robot Framework. Das Berichtswesen kommt aus dem Robot Framework. Alles andere bekommst du umsonst.
Da das Format gemeinsam genutzt wird und generisch ist, haben sich starke Werkzeuge um es herum entwickelt. Es gibt Editor-Plugins für VS Code und PyCharm, die die Syntax verstehen. Mit einem benutzerdefinierten Format wärst du in einem reinen Texteditor gefangen.
Wann ist Robot Framework die richtige Lösung und wann nicht?
Robot Framework passt am besten in heterogenen Umgebungen. Wenn dein System Webschnittstellen, Datenbanken, REST-APIs, eingebettete Systeme und benutzerdefinierte Schnittstellen umfasst, bietet dir das Framework fertige Bibliotheken für viele davon und einen zentralen Ort, um sie alle zu steuern.
Das ist nicht immer die richtige Wahl, und Pekka sagt das auch direkt. Wenn du eine einzelne Webseite testest und dein ganzes Team in TypeScript schreibt, ist ein Tool wie Playwright wahrscheinlich die bessere Wahl. Das Team kennt das Tool bereits, und die Vorteile des Robot Frameworks schrumpfen.
Ein Vorteil bleibt auch in diesem einfacheren Fall erhalten. Wenn die Stakeholder die Testfälle lesen und verstehen müssen, kannst du sie mit Robot Framework in einfachen, für Menschen lesbaren Sätzen schreiben und erhältst trotzdem das Protokoll und den Bericht. Der entscheidende Faktor ist, wie viele verschiedene Schnittstellen und wie viel kundenspezifische Integration dein Kontext erfordert.
“Ich weiß selbst sehr gut, dass es nicht immer die richtige Wahl für jedes Projekt ist. Ich will also nicht sagen, dass jeder es benutzen sollte.” Pekka Klärck
Was sich in zwanzig Jahren verändert hat
Die größte technische Veränderung war die Abkehr von der Speicherung von Daten in HTML-Tabellen. Die erste Version war nur intern. In der zweiten Version, der ersten Open-Source-Version, wurden die Testdaten immer noch in HTML gespeichert, was umständlich zu bearbeiten und unter Versionskontrolle zu stellen war. Die Umstellung auf ein reines Textformat machte beides einfacher.
Eine spätere Überarbeitung des Parsers hatte einen größeren Effekt, als die Veröffentlichungshinweise vermuten ließen. Der ursprüngliche Parser konnte sowohl mit HTML- als auch mit Textdateien umgehen und war nach Pekkas eigenen Angaben ziemlich grob. Der Ersatz brachte eine saubere Parsing-API und ein solides Parsing-Modell hervor.
Dieses Parsing-Modell ist der Grund, warum die Editoren so gut funktionieren, wie sie es tun. Sie verwenden das gleiche Modell und erhalten alle Informationen über jedes Token in den Daten. Eine Änderung, die wie ein internes Klempnerprogramm aussieht, hat eine ganze Kategorie von Tools ermöglicht.
Das Ökosystem ist größer geworden als der Kern
Der Teil, auf den Pekka am meisten stolz ist, ist das Ökosystem, gerade weil er es nicht selbst steuern muss. Die Designentscheidungen in Bezug auf Schnittstellen und Erweiterungspunkte ermöglichen es einer Gemeinschaft, auf dem Framework aufzubauen, ohne um Erlaubnis zu fragen.
Wenn man das Robot Framework auf seinen Kern reduziert, ist es immer noch nützlich für Teams, die ihre eigenen Bibliotheken schreiben. Ohne die Editoren, die vorgefertigten Bibliotheken und die Integrationen in Testmanagementsysteme wäre es ein anderes und viel kleineres Angebot. Das Ökosystem ist es, was es praktisch macht.
Es gibt ein Muster, wie der Nutzen entsteht. Eine neue Version wird mit einer verbesserten API ausgeliefert, die für sich allein genommen obskur aussieht. Monate später, manchmal ein Jahr später, erscheinen neue Werkzeuge, die darauf aufbauen. Eine Änderung der Hörerschnittstelle, die vor fast zwei Jahren vorgenommen wurde, ermöglichte selbstheilende Hörer, die Locators im Handumdrehen reparieren.
Das Ökosystem umfasst weit über hundert Erweiterungen, obwohl viele ältere nicht mehr gepflegt werden. Auch eine nicht gewartete Bibliothek kann einen Blick wert sein. Du kannst ihre Ideen aufgreifen, sie pflegen oder etwas Neues darauf aufbauen.
Warum Downloadzahlen wenig aussagen
Die Download-Zahlen von Robot Framework aus dem Python Package Index sind aufgeblasen und als genaue Messung nahezu unbrauchbar. Kontinuierliche Integrationssysteme installieren das Paket immer wieder neu, so dass die rohe Zahl in die Millionen pro Monat geht, ohne dir zu sagen, wie viele Nutzer es wirklich gibt.
Was die Zahlen zeigen, ist ein Trend. Sie sind jetzt viel höher als noch vor ein paar Jahren, was auf Wachstum hindeutet. Die genaue Zahl ist der Teil, dem du nicht trauen kannst.
Berichten zufolge sind die Website-Besuche zurückgegangen, was alarmierend klingt, bis man sich die wahrscheinliche Ursache ansieht. Die Menschen stellen ihre Fragen zum Robot Framework jetzt an KI-Tools, anstatt die Dokumentationsseiten zu besuchen. Das KI-Tool hat das Material bereits gelesen, sodass die Antwort ohne einen Seitenbesuch kommt.
Die Roadmap: Geheimnisse, Dokumente und ein bekannter Designfehler
In der nächsten Version werden geheime Variablen eingeführt. Ein geheimer Wert, der als Argument bestanden oder von einem Schlüsselwort zurückgegeben wird, wird in keine Log-Ebene geschrieben, egal wie detailliert das Logging ist. Du kannst auch Schlüsselwörter definieren, die nur geheime Werte akzeptieren, was in regulierten Umgebungen hilfreich ist, in denen Kennwörter und Token nicht in die Logs gelangen dürfen.
Diese Funktion stammt zum Teil von einem Community-Mitarbeiter der finnischen Bank OP, der von seinem Unternehmen Zeit für die Arbeit an dieser Funktion erhielt, weil der Anwendungsfall für seinen Arbeitgeber wichtig war. Nach der Veröffentlichung richtet sich die Aufmerksamkeit auf das Benutzerhandbuch, ein detailliertes Referenzhandbuch, das auf einer alten Technologie basiert und eine übergroße HTML-Datei erzeugt. Der Plan ist, es zu modernisieren und auf veraltete Informationen zu überprüfen.
In einer späteren Version der 7er-Reihe wird wahrscheinlich Markdown-Unterstützung für die Dokumentation hinzugefügt. Robot Framework unterstützt bereits mehrere Dokumentationsformate, aber nicht Markdown, das sich zum De-facto-Standard entwickelt hat und mit dem KI-Tools arbeiten.
Der schwierigste Punkt ist ein bekannter Designfehler bei der Verwendung von Namensräumen für Schlüsselwörter und Variablen, die über Ressourcendateien importiert werden. Pekka hat sie entworfen und bezeichnet das Design gerne als schlecht. Es zu beheben bedeutet, das Verhalten neu zu entwerfen, es zu implementieren und die alten kaputten Wege mit Verwerfungswarnungen am Laufen zu halten, anstatt bestehende Tests über Nacht zu zerstören. Die Abwärtskompatibilität ist die Einschränkung, die es langsam macht.
Wie das Robot Framework sich selbst testet
Robot Framework wird mit Robot Framework getestet. Das Projekt pflegt fast 7.000 Testfälle für das Robot Framework selbst sowie mehrere hundert Unit-Tests.
Für einige dieser Testfälle wären einfache Unit-Test-Tools besser geeignet, und Pekka weiß das. Das Team treibt sein eigenes Framework absichtlich bis zum Äußersten, um zu sehen, wie es sich dort bewährt, wo ein anderes Tool vielleicht besser geeignet wäre. In normalen Projekten würdest du an diesen Stellen zu Unit Tests greifen.
Für die Größe der Codebasis und den Umfang der Arbeit bleibt die Zahl der Fehlerberichte relativ gering. Das liegt an der pedantischen Programmierung und einer Stiftung, die nicht auf überstürzte Veröffentlichungen drängt. Wenn du es vermeiden kannst, technische Schulden anzuhäufen, bleibt die Codebasis in einem stabilen Zustand, anstatt Pflaster auf halbfertige Funktionen zu kleben.
Der Busfaktor eines Ein-Personen-Kerns
Der Kern von Robot Framework wird größtenteils von einer Person entwickelt, und das bezeichnet Pekka als Risiko. Der Code ist in einem guten Zustand, also macht er sich keine Sorgen, dass das Projekt stirbt, wenn ihm etwas zustößt, aber mehr Leute, die den Kern gut kennen, würden ihn gesünder machen.
Die meisten Beiträge fließen in das Ökosystem und nicht in den Kern, und das ist der einfachste Ort, um zu helfen. Du musst Designentscheidungen nicht mit dem Maintainer abstimmen. Du nutzt die öffentlichen APIs und baust. Auch der Kern erhält Beiträge, aber das Volumen ist geringer.
Längerfristig wollen wir eine Gruppe von Leuten aufbauen, die den Kern gut genug verstehen, um Pull Requests zu reviewen und komplizierte Designentscheidungen zu diskutieren. Die nachhaltige Finanzierung durch die Stiftung ist ein Teil davon, denn sie kann sowohl angestellte Beitragszahler für ihre Arbeitszeit als auch selbstständige Entwickler für bestimmte Arbeiten bezahlen.
Wie du dem Projekt helfen kannst
Die direkteste Hilfe ist die Weitergabe der Nachricht. Pekka will nicht, dass jeder das Robot Framework übernimmt. Er möchte, dass die Teams wissen, dass es existiert, damit sie bei der Evaluierung einer Automatisierungslösung diese ehrlich gegen die Alternativen abwägen können. Wenn sie nicht wissen, dass es Robot Framework gibt, werden sie sich nie dafür entscheiden, selbst wenn es die bessere Lösung wäre.
Der Bekanntheitsgrad variiert stark von Land zu Land. In Deutschland ist der Rahmen in weiten Teilen der Branche bekannt. In Thailand und Brasilien haben sich aktive Gemeinschaften gebildet, manchmal mit wenig direktem Kontakt, oft verbreitet durch jemanden, der es gelernt und in seiner eigenen Sprache darüber geschrieben hat. In einem Nachbarland wie Dänemark hingegen kennen es viele Menschen vielleicht gar nicht.
Die Mitgliedschaft in der Stiftung ist die zweite konkrete Form der Unterstützung. Die Mitgliedsbeiträge sind bescheiden, niedriger als eine einzelne kommerzielle Lizenz für viele Test-Tools, und sie finanzieren nachhaltige Entwicklungs- und Ökosystemprojekte wie den Editor. Mehr als 80 Unternehmen sind Mitglied, während viele andere das Framework nutzen, ohne einen Beitrag zu leisten.
RoboCon als Treffpunkt
Die RoboCon ist die Konferenz des Projekts, die im Februar 2026 vor Ort in Helsinki stattfindet und im März online veröffentlicht wird. An den letzten Ausgaben vor Ort nahmen etwa 300 bis 350 Personen teil, vor der Pandemie waren es eher 500.
Die nächste Ausgabe wird in Finnland stattfinden, und die übernächste wahrscheinlich auch, da es das zehnte Mal sein wird und die Planung lange dauert. Darüber hinaus erwägen die Organisatoren, die Konferenz nach Deutschland oder in ein anderes Land mit einer starken Nutzerbasis zu verlegen, um Menschen zu erreichen, die zum ersten oder zweiten Mal an der Konferenz teilnehmen. Zwei parallele Konferenzen zu veranstalten, wurde ausgeschlossen, da dies die Gemeinschaft spalten würde.
Wenn du an der Online-Konferenz teilnimmst, hast du auch Zugang zu den Vorträgen vor Ort. Die Aufzeichnungen werden nach und nach veröffentlicht, so dass du einen bestimmten Vortrag nur dann sehen kannst, wenn du dabei bist. Bei den Vor-Ort-Treffen sind die bekannten Gesichter und die Atmosphäre am besten, aber auch Neulinge sind willkommen.
