01.12.2022 | News Front Office Digital Finance Know-how Letter
Wer kennt die Situation nicht: Im Rahmen der Linientätigkeiten sollen in regelmäßigen Abständen Tests durchgeführt werden. Diese Tests erstrecken sich von Abnahmetests selbst erteilter Anforderungen über Regressionstests bestehender Datenlieferungen bis zu Userinterface Tests neuer oder bestehender Systeme oder Systemteile. Diese Aufgaben sind in einem langsamen Entwicklungszyklus meist schon schwer unterzubringen. Richtig aufwendig wird es aber erst, wenn die Wartung und der Betrieb der Firmen IT unter der Vorgehensweise DevOps – die wortwörtliche Verschmelzung von Development und (IT-) Operations – operiert. Die dadurch eingeführte kontinuierliche Entwicklung und Produktivnahme von Neu- und Weiterentwicklungen führt zu noch mehr Testaufwand welcher dann entweder vernachlässig wird oder zu aufwendigen Zusatzarbeiten, oft auch am Wochenende vor der Produktivnahme, führt.
Um diesen Aufwänden erstens entgegenzuwirken und zweitens die Qualität der Tests zu verbessern, gibt es umfangreiche Möglichkeiten der Automatisierung dieser Tests. Ein Nebenprodukt dieser Tests stellt die dadurch ebenfalls automatisch erstellte Dokumentation dar.
Testautomatisierung bezeichnet die Automatisierung von Testaktivitäten unter Zuhilfenahme von Automatisierungstools die entweder zugekauft oder selbst entwickelt werden können. Zu empfehlen ist hier im Hinblick auf die Reduzierung von Fehlern in der Testsoftware der Einsatz breit eingesetzter Tools.
Diese Tools werden zum Ausführen von vorgefertigten Tests sowie zum Ansprechen und Steuern der zu testenden Software eingesetzt. Welche dieser Möglichkeiten angewendet wird hängt auf der einen Seite vom durchzuführenden Test und auf der anderen Seite vom zu testenden System ab. Das Ergebnis dieser Testläufe ist ein Protokoll und, je nach Setup, auch eine weiterführende Handlung im Testsetup. So kann ein fehlgeschlagener Test dazu führen, dass alle weiteren Aktivitäten abgebrochen und der Test nach dem Beheben der Abbruchursache neu gestartet werden muss. Ein erfolgreicher Test kann wiederum automatisch einen weiteren Test oder, je nach Stufe im Prozess, einen neuen Prozess zum Bauen eines Deployment Paketes oder das Deployment selbst anstoßen. Natürlich können nach einem erfolgreichen Test auch manuelle Überprüfungen der Ergebnisse notwendig sein die den weiteren automatisierten Prozess bis zu deren Abschluss stoppen.
Klassisches Softwaretesten kann sehr allgemein als die Suche nach Fehlern gesehen werden. Diese Suche wird meist in einem Umfangreichen Testplan beschrieben und mit hohem manuellem Aufwand über das Userinterface durchgeführt. Dargestellt in der klassischen Testpyramide:
Im Unterschied zum klassischen Softwaretesten steht beim agilen Testen nicht das Finden, sondern das Vermeiden von Fehlern im Vordergrund. Dafür ist es jedoch wichtig, dass jeder Entwickler seinen Code mit Hilfe von Unit Tests validiert. Als Basis erfolgreicher Testentwicklung in der Agilen Softwareentwicklung sind die Abnahmekriterien aus den Userstories.
Im Vergleich der beiden Pyramiden zeigt sich, dass die agile Testpyramide mit ihrer soliden Basis aus Unit Tests viel robuster ist als die klassische Pyramide mit dem großen manuellen Teil. Das breite Fundament an automatisierten Tests stellt sicher, dass bei Erweiterungen oder nach dem Beheben von Fehlern funktionierende Teile weiter funktionieren.
Zusätzlich können diese Tests periodisch während der Entwicklung durchgeführt werden und tragen dadurch zu einer Verbesserung der Qualität und einer Reduzierung der Abnahme und Acceptance Testaufwände bei.
Damit ein hoher Grad an Automatisierung erreicht werden kann, ist es notwendig, die sich häufig ändernden User Interfaces nur mit den wirklich notwendigsten Tests zu prüfen.
Nach diesem kurzen Exkurs wieder zurück ins DevOps Umfeld. Wenn wir uns den DevOps Achter betrachten, stellt sich die Frage an welcher Stelle sich welche Tests wiederfinden und welche davon automatisiert werden können. Dabei ist wichtig zu erwähnen, dass Testen nicht nur in der explizit angegebenen Testphase stattfindet, sondern von der Code bis zur Deploy Phase.
Beginnend bei der Code Phase treffen wir hier auf Tests, die sich mit der statischen Qualität des Codes beschäftigen. Das sind Tests zur syntaktischen und semantischen Prüfung des geschriebenen Codes. Dies kann durch die Prüfung von Coding Guidelines und durch eine statische Codeanalyse erreicht werden.
In der Build Phase überlappen sich die statischen Analysen, die während des Compilierens durchgeführt werden können mit dem Ausführen vordefinierter Unit Tests.
Die Test Phase ist geprägt von Integrationstest die in der agilen Testpyramide zwischen den Unit- und den Acceptance- Tests liegen. Den Abschluss der Integrationstests bilden die System-Integrationstests welche in der Release Phase durchgeführt werden.
In der Deploy Phase geht es darum, die Abnahme durch die User zu bekommen. Diese Abnahme setzt sich aus den Acceptance und UI-Test zusammen und benötigt die meisten Interaktionen durch die User. Gleichzeitig bietet diese Phase auch das höchste Potential, um mit Automatisierung eine Verbesserung der Tests und eine Reduzierung der manuellen Testaufwände zu erreichen. Im besten Fall müssen die User hier nur noch wenige explorative UI-Tests durchführen und die Ergebnisse der automatischen Tests prüfen.
Den Abschluss bilden, nach dem Deployment, Smoke-Tests die entweder automatisiert, etwa mit Software Robotern oder durch die User selbst direkt im produktiven System durchgeführt werden. Nach dem erfolgreichen Abschluss dieser Tests steht dem Betrieb der neuen Software nichts mehr im Weg.
Nun zu den zuerst allgemein angesprochenen Tools zur Durchführung automatisierter Tests. Hier bietet sich wie schon bei der Beschreibung der Tests eine Zuordnung zu den DevOps Phasen an.
Beginnend bei der Code Phase finden sich hier Tools wie SonarQube für die statische Code Analyse. Dabei wird, passend zu der jeweiligen Programmiersprache, die Qualität des Codes ohne Ausführung unter verschiedenen Gesichtspunkten analysiert. Zu den hierbei betrachteten Gesichtspunkten zählen die Wartbarkeit, die Sicherheit im Sinne von Fehlerfreiheit und die Sicherheit im Sinne von Verwundbarkeit. Während der Entwicklung sollten diese Tests regelmäßig durchgeführt und die dadurch gewonnenen Verbesserungsvorschläge beachtet und umgesetzt werden.
Die Build Phase kann grob in zwei Teile geteilt werden. Der erste Teil besteht aus der Durchführung der Unit-Tests, welche im jeweils für die benutzte Programmiersprache angebotenen Frameworks erstellt werden. Als Beispiele sind hier JUnit für Java und PyUnit für Python zu erwähnen. Im Zweiten Teil geht es dann um die Ausführung dieser Tests und der Ausführung des eigentlichen Builds bestehend aus dem Compilieren der einzelnen Komponenten und dem zusammenbauen zu einer zusammengehörigen Einheit. Für diese Aufgabe werden Tools wie z. B. Jenkins eingesetzt.
Wird im Entwicklungsprozess auf die Variante des Behavior Driven Developments (BDD) gesetzt, so können in der Build Phase ebenfalls vorgefertigte Tests zum Prüfen der spezifizierten Anforderungen eingesetzt werden. Als Werkzeug wird hierfür sehr häufig Cucumber eingesetzt.
In der expliziten Test Phase geht es vor allem darum, dass sichergestellt wir, dass alle Komponenten im Zusammenspiel einwandfrei funktionieren. Dazu ist es notwendig, die gesamte Software auf einer (Integrations)Testumgebung zu installieren und darauf Tests zum Prüfen der korrekten Zusammenarbeit der einzelnen Module durchzuführen. Die hier eingesetzten Tools sind stark von der Art der Software abhängig. Webbasierte Systeme benötigen andere Tools wie native Software einer oder mehrerer Plattformen. Zu den hier verwendeten Tools gehören unter anderem der Rational Integration Tester, Citrus oder Selenium.
Die Release Phase hat zum Ziel ein fertiges Installationspacket zu erstellen. Auf dem Weg dorthin gilt es zuerst sicherzustellen, dass alle Komponenten die erforderlichen Qualitätskriterien erfüllen und dann sicherzustellen, dass das komponierte Packet ebenfalls die notwendigen Qualitätskriterien erfüllt. Diese Tests bestehen, vor allem in größeren Organisationen, aus einer Fülle von selbstentwickelten und standardisierten Tests bzw. dem Einsatz unterschiedlichster Tools. Damit diese Tests ausgeführt werden können benötigt es ein geeignetes Tool. Als Beispiel hierfür können die Tools von Tricentis (Tosca und qTest) eingesetzt werden. Wichtig zu beachten ist hier, dass es für diese Tests geeignete Testumgebungen benötigt. Üblicherweise werden diese Tests gegen Integrations- oder Acceptance-Umgebungen durchgeführt.
Wie der Name schon sagt, geht es bei der Deployment Phase um das Ausliefern und Installieren der fertigen Pakete auf einer Produktionsumgebung. Die Testaktivität in dieser Phase bzw. nach dem Deployment beschränkt sich darauf, sicherzustellen, dass alle Dienste und Services nach dem Deployment wieder gestartet wurden und für die User erreichbar sind. Diese Überprüfungen können mit den bestehenden Tools durchgeführt werden.
Wurden alle Phasen der Entwicklung und des Testens erfolgreich durchgeführt und abgeschlossen, kommt zum Schluss noch die Ausführung sogenannter Smoke Tests. Dabei werden entweder von den Usern selbst oder von Software Robotern, wie die von Ranorex oder UIPath, einige wenige Tests am produktiven System selbst durchgeführt. Diese Tests sollen anstelle von Standardtests besser komplizierte Aufgaben oder Spezialfälle abdecken und so noch mal das System einem Stressszenario aussetzen. Neben den Erleichterungen während der Testausführungen bieten automatisierte Tests noch einen wesentlichen Vorteil. Und zwar liefern diese, vor allem im Bankenumfeld relevante, Dokumentationen welche nicht nur die Testergebnisse widerspiegeln, sondern auch die Nachvollziehbarkeit gewährleisten.
Sollten Sie bei der Beschreibung der vielen Möglichkeiten neugierig geworden sein oder sie befinden sich selbst schon in einem DevOps Projekt und benötigen Unterstützung, dann sprechen Sie uns am besten gleich an. Wir unterstützen Sie gerne mit unserer langjährigen Erfahrung in der Umsetzung von DevOps wie der Automatisierung von Tests.