Kundenfokus, agile Disziplinen und modulare Architekturen erhöhen heute die Taktzahl von Releases deutlich. Schnelles Feedback der aktuellen Qualität ist zwingend erforderlich. Mike Cohn hat vor einigen Jahren die Testpyramide vorgestellt, mit der er eine ideale Aufteilung des Gesamtaufwands für die Implementierung von verschiedenen Tests beschreibt (siehe Abbildung 1). Der Großteil der Tests wird in den unteren Stufen durchgeführt (z. B. Unittests), weil diese kostengünstiger sind. Der Aufwand von Tests steigt, je weiter oben sie in der Pyramide angesiedelt sind. Akzeptanztests sind meistens besonders aufwendig und werden oft manuell wiederholt. Darum beschränkt man die Anzahl solcher Tests auf das Nötigste.
Abb. 1: Testpyramide
Testen komplexer Systeme
Vor allem bei schnellen Release-Zyklen müssen alle Tests entlang der Entwicklungs-Pipeline in sehr kurzer Abfolge wiederhol- und durchführbar sein. Das erfordert kontinuierliches Testen (continuous testing) und kann nur mit Testautomatisierung funktionieren.
Auf dem Markt gibt es zahlreiche Lösungen von kommerziellen und Open-Source-Anbietern. Mit kommerzieller Software für die Qualitätssicherung kauft man oft eine Full-Stack-Plattform, die zwar fertige Lösungen wie integriertes Reporting bietet, aber sich nur schwer anpassen lässt.
Ein Framework hat dagegen den Vorteil, flexibel zu sein und sich im Idealfall ohne großen Aufwand in die bestehende Infrastruktur integrieren zu lassen (siehe Abbildung 2). Wir haben uns vor einigen Jahren entschieden, auf das Robot Framework (RF) zu setzen.
Abb. 2: Integrationsbeispiel für RF
Akzeptanztests im RF beschreiben
RF beschreibt Testfälle in Anweisungen, sogenannten Keywords. Man kann auf zahlreiche Bibliotheken zurückgreifen, die prägnante und gut dokumentierte Keywords bieten. Die populärste Bibliothek ist die SeleniumLibrary zum Steuern von Weboberflächen. Aus solchen vorimplementierten Keywords lassen sich leicht fachliche Keywords zusammenstellen, sodass die Tests ohne IT-Kenntnisse lesbar werden (siehe Abbildung 3 und 4). Weil auch für Menschen lesbare Keywords wiederverwendbar sind, lassen sich mit der Zeit immer schneller Test-Suiten erstellen, ohne neue Keywords definieren zu müssen. Das sogenannte Keyword-Driven Testing kann man mit RF somit direkt praktizieren.
Abb. 3: Beispiel-Test-Suite mit RED-Entwicklungsumgebung
Abb. 4: Komplexes RF-Beispiel
Zusätzlich wird noch die Gherkin-Notation für Behaviour-Driven Testing unterstützt.
Für die Implementierung der Tests verwenden wir RED, einen auf der Eclipse IDE basierenden Editor, mit dem die Tests komfortabel und effizient bearbeitet werden können. Aufgrund der Einfachheit ist für die Umsetzung in den ersten Schritten kein Entwicklerwissen notwendig. Sobald die Tests in mehreren Projekten wiederverwendet oder Bibliotheken erweitert werden, sind Kenntnisse der Skriptsprache Python erforderlich. Die simple und sehr gut dokumentierte Programmierschnittstelle von RF bietet allerdings auch Laien einen sehr leichten Einstieg und eröffnet Testern die Möglichkeit, nach eigenem Ermessen in die Python-Entwicklung hineinzuwachsen.
Infrastruktur um RF
Die Testfälle werden in Git versioniert. Haben die Tester genug Erfahrung mit den grundlegenden Arbeiten mit Versionsmanagement gesammelt, stehen mit Branching und Merging Werkzeuge zur Verfügung, die zusätzliche Dimensionen beim Testen eröffnen: Dann kann man Tests refaktorieren oder Feature-spezifische Tests vorab entwickeln, ohne den „stable“-Status zu gefährden. Ab hier fangen die Grenzen zwischen Softwareentwicklung und Qualitätssicherung an zu verschwimmen, denn der Tester eignet sich typische Softwareentwicklungsdisziplinen an.
Um Testfälle zu validieren, kann man zum Beispiel eine Git-Lab-CI-Pipeline verwenden, um mit einer Python-Bibliothek namens robotframework-lint (kurz: RF-Lint) die Testfälle auf syntaktische Fehler und Schwächen zu prüfen: Clean-Code-Regeln für Tests. Diese Checks werden bei jedem Git Push in das Repository auf den geänderten Testfällen angewendet. Schlagen die RF-Lint-Regeln an, dann wird der Verursacher per E-Mail informiert. Die Regeln lassen sich leicht erweitern, sodass man zum Beispiel prüfen kann, ob ein GUI-Test den Browser, den er geöffnet hat, auch wieder schließt. Tut dieser Test das nicht, läuft der Host Gefahr, von offenen Browser-Instanzen aus vergangenen Tests ausgebremst zu werden.
Automatisierte Jobs im guten alten Jenkins bereiten die Testumgebungen vor, womit Grenzen zwischen Softwarebetrieb und Qualitätssicherung verschwimmen. Die Jobs zum Ausführen der Tests werden jede Nacht automatisch ausgelöst und lösen über Stunden ganze Batterien von Robot-Tests auf den aktuellsten Entwicklungsständen aus. Das entsprechende RF-Plug-in für Jenkins sammelt die Standard-HTML-Reports ein und informiert die Qualitätssicherung über Monitoring-Kanäle in einem Chat-Tool wie Mattermost. Durch die Präsentation im Chat kann der Tester schnell einen ersten Überblick über die Ergebnisse der letzten Nacht bekommen und landet mit einem Klick in die Chat-Nachricht in den detaillierten Testergebnissen.
Wenn die Standard-Reports zu viele werden und man droht, den Überblick zu verlieren, kann man die Protokolle von RF an einen Logstash schicken und sich mithilfe von Kibana einen Überblick über die Teststände und ihre Historie verschaffen (ELK-Stack aus Elasticsearch, Logstash, Kibana). Sofern die zu testende Applikation ebenfalls sein Log an Logstash schickt, kann man Testergebnisse und Log-Ausgaben direkt miteinander verknüpfen und direkt in die Fehleranalyse einsteigen.
Selbstverständlich gibt es auch fertige Docker-Images, um zum Beispiel die komplette Testumgebung zum Ausführen von Selenium-Tests bereitzustellen. Diese Images müssen nur noch mit den eigenen Tests gefüttert werden und ersparen aufwendiges Administrieren der Testinfrastruktur. Mit der Zeit lösen solche Robot-Container die anfänglich erwähnten Jenkins-Jobs zum Aufsetzen von dedizierten Testsystemen ab.
Robot Test Automation wird Robot Process Automation (RPA)
Automatisierte Testfälle kann man allgemein als Prozess bezeichnen. Prozesse müssen aber kein Abarbeiten von Testkriterien sein, sondern können auch geschäftsrelevante Abläufe sein. Seit der Version 3.1 unterstützt RF deshalb auch ein erweitertes Vokabular zum Automatisieren von allgemeinen Prozessen. In den kommenden Releases in 2019 wird dieses Vokabular mit zusätzlichen Features ausgebaut.
Abwarten braucht aber niemand, denn schon jetzt lassen sich schnell verständliche Automaten bauen, die im Unternehmen repetitive, manuelle und fehleranfällige Prozesse ablösen. Es lohnt, sich einmal außerhalb der IT-Abteilung umzuhören und gestresste Kollegen ausfindig zu machen, die immer noch manuell Excel-Tabellen pflegen, Dateien zwischen FTP-Servern hin- und her schubsen oder Daten einzeln über Browser-Masken erfassen müssen. Solche Tätigkeiten kann man mit RF leicht abdecken.
Tabelle 1: Tools
Fazit
Aus unserer Sicht besticht das Robot Framework durch seine Einfachheit und Flexibilität. Es bietet zahlreiche Möglichkeiten im Kontext der Test- und Prozessautomatisierung. Die wachsende Community und die seit 2018 stattfindende Konferenz RoboCon multiplizieren die Potenziale.
Die Integration der im Artikel beschriebenen Helden wie Jenkins, GitLab, ELK-Stack und Docker gibt im Team Sicherheit, dass bei Änderungen im Rahmen der automatisierten Tests entstandene Fehler frühzeitig aufgedeckt werden. RF ist dabei keine Full-Stack-Lösung, sondern ein Framework, an das man seine individuellen Subsysteme einfach anschließen kann. Auch wenn Sie eine andere Peripherie verwenden, als in diesem Artikel beschrieben, wird das Framework nicht im Weg stehen.
Obwohl RF viele Möglichkeiten bietet, sich in bestehende Infrastrukturen integrieren zu lassen, gibt es im Grunde keinen „falschen“ Weg, es einzusetzen. Überwindet man die anfängliche Unsicherheit der vielen Möglichkeiten, wird man schnell mit Erfolgen belohnt. Disziplinen wie Softwarebetrieb, -entwicklung und Qualitätssicherung können dabei immer mehr verschmelzen. Ein Testteam wird zum „Automatisierungsteam“ und kann mit der Spracherweiterung für RPA konkrete Unterstützung für Abteilungen außerhalb der IT bieten.
