Die Auswahl an Tools für die End2End-Überwachung von Applikationen ist groß. Ein wesentliches Unterscheidungsmerkmal: die Lizenzform. Die Frage aller Fragen: "Darf" es auch Open-Source sein?
8 Gründe für "ja", 8 Gründe für Robot Framework.
More...
"Der beste Wind hilft dem nicht, der nicht weiß, welches Schiff er nehmen soll." (Sehr frei nach Seneca...)
In diesem Artikel geht es nicht darüber, was "gut" oder "schlecht" ist. Mir ist nur wichtig, dass Du Dir Robot Framework ganz genau angesehen hast, bevor Du Dich an teure Lizenzen bindest - vielleicht bis Du mir später dankbar dafür.
In diesem Artikel habe ich acht sehr gute Gründe zusammengetragen, die beim End2End-Monitoring aus meiner Sicht ganz klar für einen Einsatz von Robot Framework in Kombination mit RobotMK sprechen.
Grund Nr. 1: Das Rad ist bereits erfunden
Wenn Du noch nicht überzeugt bist von Robot Framework und dazu tendierst, alles selbst zu programmieren, dann ist die gute Nachricht: grundsätzlich ist alles schon da.
Denn für Python gibt es unzählige Module, mit denen alles erdenkliche automatisiert werden kann: Windows-GUIs, Web-Inhalte, auch exotischeres wie das Abfragen von REST-APIs lassen sich perfekt mit Python realisieren.
Insofern scheint die Frage also berechtigt:
Was kann Robot Framework, was nicht ohnehin schon mit Python möglich ist?
Kann man das nicht auch alles selbst "generisch" programmieren?
Ja, man kann.
Allerdings solltest Du alle diese Punkte abhaken können:
- Du hast so viel Python-Vorwissen, dass Dir das Programmieren leicht von der Hand geht. Vergleiche das mit einem Schreiner, der sich beim Möbelbau komplett darauf fokussieren kann, wie er das Möbelstück konstruiert und gestaltet.
Arbeitstechniken, die Einstellung und Bedienung seiner Maschinen kennt er im Schlaf. - Du achtest bei der Umsetzung darauf, Dein Rahmenwerk
generisch zu bauen, sodass es sich bei allen Tests um die Fehlerbehandlung, Ergebnisverarbeitung und Abflusssteuerung kümmert.
Schließlich willst Du das nicht jedesmal von vorne bauen ("DRY-Prinzip", don't repeat yourself). - Dein Rahmenwerk hat ein sauberes Interface, sodass neuere Test-Technologien (z.B. Playwright) ohne Probleme integriert werden können.
Schließlich soll Dein Python-Testkonzept ein paar Jahre bestehen. - In Deinem Rahmenwerk sind die Funktionen der verwendeten Module so weit abstrahiert, dass auch Kollegen mit weniger Python-Kenntnissen sich darin einarbeiten können.
- Der Mehrwert, den Du mit Deiner Lösung schaffst, rechtfertigt die von Dir investierte Zeit (das wird nicht wenig sein...)
Du wirst Dich verzetteln, wenn auch nur einer dieser Punkte zu kurz kommt.
Du hast alle diese Punkte erfüllt? Du hast Dein eigenes Test-Rahmenwerk programmiert?
Das ist natürlich ein Ritterschlag für Dich. Aber hoffentlich hast Du das nicht wirklich getan, denn dann hast Du das Rad neu erfunden.
Robot Framework beherrscht die oben erwähnten Punkte schon seit seiner Geburtsstunde vor 15 Jahren. Seitdem wird es kontinuierlich verbessert, die Entwicklung ist aktiver denn je.
Ich zitiere gern den Kollegen Markus Stahl, der die Vorzüge von Robot Framework treffend hier beschrieben hat:
Würde ein Tester Experte im Programmieren sein, wäre er Softwareentwickler geworden.
Markus Stahl - Process Automation Engineer
"Der Werkzeugkasten zur Automatisierung muss zugleich mächtig und leicht einzusetzen sein. Programmiersprachen wie Java, C++ oder Python dürfen dabei nicht das Hauptwerkzeug sein, denn sie fordern vom Tester viel zu viel Einarbeitung und lenken ihn von den fachlichen Anforderungen ab.
Programmierung liegt Testern meistens nicht. Sie ist ein Hindernis, im besten Fall notwendiges Übel, um die eigentliche Tätigkeit auszuführen und sich auf die Fachlichkeit zu konzentrieren. (...)
Robot Framework reduziert den Programmieranteil auf ein solches Minimum, es fühlt sich nicht mehr wie Programmieren an."
Grund Nr. 2: Trennung von Testcode und Auswertung
Die Vorzüge von Robot Framework in Kombination mit Checkmk werden klar, wenn man verstanden hat, wie die Schnittstelle RobotMK arbeitet: Robot-Testergebnisse (im XML-Format) werden unverändert über den Agenten-Output zum Checkmk-Server übertragen.
Erst auf dem Checkmk-System erfolgt die Analyse des XMLs durch den RobotMK-Check.
Die XML-Knotenpunkte können beliebig tief verschachtelt sein - sie entsprechen exakt der Hierarchie der ausgeführten Keywords. Jeder dieser Nodes besitzt eine individuelle Laufzeitinformation.
Mit der pattern-basierten RobotMK-Regel ist die Laufzeitüberwachung feinster Teilschritte und zugleich des "großen Ganzen" möglich.
Grund Nr. 3: Struktur und Flexibilität dank Libraries und Keywords
No need to code.
Der "Keyword-Driven"-Ansatz von Robot Framework macht es möglich, die Methoden von bestehenden Python-Modulen zu verwenden, ohne Python programmieren zu müssen. Vereinfacht gesagt sind Robot-Keywords wie eine weitere Usability-Hülle um solche Module.
Mit der "SeleniumLibrary" beispielsweise steht die komplette Funktionspalette von Selenium in Form eingängiger Keywords zur Verfügung.
Der Test-Admin kann sich nach Belieben neue Keywords erschaffen, in denen er andere bestehende aufruft. Mit solchen "User-Keywords" gewinnen Robot-Tests enorm an Struktur und Lesbarkeit.
Die Bandbreite an Testmodulen ist ein weiteres Alleinstellungsmerkmal, welches Robot Framework von anderen Testwerkzeugen abhebt.
Grund Nr. 4: Die Robot Framework Community
Bei der Wahl eines geeigneten E2E-Tools sollte der Support-Aspekt nicht außer Acht gelassen werden.
Im Falle von Robot Framework und Checkmk tauscht sich eine weltweite Community auf verschiedenen Kanälen aus und hilft sich gegenseitig.
Oft antworten sogar direkt die Entwickler der entsprechenden Robot-Module. Hier werden an einem "großen runden Tisch" Probleme gelöst, Lösungswege gesucht und neue Features diskutiert.
Robot Framework
Checkmk
Tipp: Auch in der Meetup-Szene finden sich immer wieder spannende Talks zum Thema Robot Framework. Nils Balkow-Tychsen zeigt am 11. November 2020 im Meetup "Berlin-Devs-Drinks", wie man mit der Library KubeLibrary Kubernetes-Cluster testet.
Grund Nr. 5: Robot Framework ist plattformunabhängig
Viele andere End2End-Tools sind nur auf einem Betriebssystem (meist Windows) lauffähig.
Die Plattformkompatibilität von Robot Framework deckt sich mit der von Checkmk. Robot-Tests können somit optimal in Checkmk integriert werden, egal ob Windows, Linux, Mac, Android, iOS, ...
Grund Nr. 6: Unabhängigkeit und Sicherheit durch Open Source
Machen wir uns nichts vor: es kostet immer Geld, eine Software-Lösung zu implementieren und Know-How dafür aufzubauen. Da schenken sich Open-Source oder kommerzielle Software nichts.
Im Anschluss daran aber ist Open-Source-Software tatsächlich kostenlos - sie verursacht dann keinerlei Lizenzkosten mehr.
Weder einmalig, userabhängig, monatlich oder jährlich. Es gibt keine Preisschraube, an der nachträglich gedreht werden kann.
Grund Nr. 7: Zentrale Administration über WATO dank RobotMK
Dank der Schnittstelle RobotMK bleibt Checkmk bzw. WATO die Kommandozentrale - nicht nur für die Parametrisierung der Robot-Checks, sondern auch für deren Planung und Ausführung.
Beim Design von RobotMK wurde das Checkmk-Prinzip befolgt:
- keine unnötigen Automatismen auf den Robot-Clients
- der Agent erhebt die Daten, die Auswertungs-Logik bleibt beim Monitoring-Server.
Deshalb ist es auch so einfach, bereits bestehende Robot-Tests ins Checkmk-Monitoring zu integrieren.
"Single point of contact" zur Anpassung von Alarmierungen bleibt für den Checkmk-Admin die WATO-Oberfläche.
Grund Nr. 8: Robot Framework ist die "lingua franca" der Testautomatisierung
Wer Zeit und Geld in ein Software-Produkt investiert, wünscht sich natürlich, von dieser Lösung möglichst lange profitieren zu können.
Die Entscheidung für kommerzielle Software muss nicht verkehrt sein. Sie birgt aber je nach Hersteller das unkalkulierbare Risiko diktierter Produktlebenszyklen oder gar Produkteinstellungen (z.B. durch Strategiewechsel beim Hersteller).
Robot Framework existiert seit 15 Jahren und "gehört" keiner Firma. Das non-profit-Konsortium Robot Foundation besteht aus über 40 Firmen (u.a. KUKA, Deutsche Post Adress, Finnair, Capgemini).
Es sponsert die Entwicklung, Community-Events und Betriebskosten (z.B. Website), hat ansonsten jedoch keinen weiteren Einfluss.
FAZIT
Es ist mit Sicherheit nicht verkehrt, auch ein paar Zeilen eigenen Python-Code schreiben zu können.
Trotzdem - oder vielleicht gerade deswegen - ist meine Empfehlung, für E2E-Monitoring besser heute als morgen Robot Framework einzusetzen.
Bei den ersten Gehversuchen wird der Mehrwert dieses "Rahmenwerks" wahrscheinlich noch im Schatten des Einarbeitungs-Aufwandes stehen (der sich allerdings in Grenzen hält).
Sehr bald wird dann aber klar, dass Robot Framework äußerst mächtiges und ausgereiftes Werkzeug ist, um robuste und verständliche Applikationstests zu schreiben. Libraries und Keywords lassen dabei alle Freiheiten.
Die Entscheidung für das Open-Source-Tool "Robot Framework" ist keine Entscheidung für ein einzelnes Unternehmen.
Sie ist eine Entscheidung für die "lingua franca" der Testautomatisierung, die Menschen auf der ganzen Welt sprechen und verstehen.
Bye, Vendor-Lock-in. 🙂
