TSUNG-LIN WU - stock.adobe.com
Wie man Hürden für die Testautomatisierung überwindet
Viele Unternehmen suchen nach Wegen, um Continuous Testing in ihre DevOps-Pipeline zu integrieren. Wo liegen die größten Hürden dabei – und wie kann man sie überwinden?
Bei der Softwareentwicklung und -bereitstellung zählt Geschwindigkeit. Wer zu spät kommt, der läuft Gefahr, Chancen zu verpassen und den Anschluss zu verlieren. Etablierte Unternehmen sehen sich heute zunehmend im Wettbewerb mit innovativen Start-ups, die agiler unterwegs sind und den Markt umkrempeln.
Diese Newcomer haben den großen Vorteil, dass sie auf einer grünen Wiese starten und keine Altlasten mit sich herumschleppen. Dadurch tun sie sich leichter, ihre Prozesse gleich von Grund auf optimal aufzusetzen und Continuous Testing in die DevOps-Pipeline zu integrieren. Das wiederum ermöglicht es ihnen, neue Anwendungen und Releases schneller bereitzustellen.
Unternehmen, die seit Jahren am Markt sind, haben dagegen meist mit komplexen, historisch gewachsenen Application Stacks zu kämpfen. Diese reichen von Mainframes über jahrzehntealte benutzerdefinierte Anwendungen und Anwendungspakete bis hin zu modernen Schnittstellen. Prozessen sind oft tief verwurzelt, und es herrschen strenge Compliance-Anforderungen. Wie gelingt es, unter diesen Bedingungen ein angemessenes Automatisierungsniveau beim Testing zu erzielen? Es gibt vier wichtige Strategien, die dabei helfen können.
1. Die Automatisierung über den gesamten Technologie-Stack vereinfachen
Traditionelle Ansätze zur Testautomatisierung verfolgen einen Skript-basierten Ansatz. Das verursacht erheblichen Aufwand und steht dem Projekterfolg häufig im Wege: Zunächst entwickelt und implementiert man ein Automatisierungs-Framework, testet es und bereinigt Fehler. Anschließend fügt man Skripte hinzu, um das Framework zu nutzen.
Wenn sich die zu testende Applikation ändert, müssen sowohl die Skripte als auch das Framework überprüft und möglicherweise aktualisiert werden. Dieser Aufwand vervielfacht sich in einem heterogenen Application Stack. Denn für die verschiedenen Technologien brauchen die Tester unterschiedliche Frameworks.
So konzentriert sich Selenium, das beliebteste moderne Testautomatisierungs-Framework, zum Beispiel ausschließlich auf Web User Interfaces (UIs). Für mobile Benutzeroberflächen benötigt man dagegen Appium, ein Framework das ähnlich, aber nicht identisch ist. Um einen Ende-zu-Ende-Testfall zu automatisieren, müssen Mitarbeiter also mehrere Frameworks erlernen und miteinander verknüpfen. Das kostet Zeit, erfordert Training und bindet Ressourcen, die an anderer Stelle fehlen.
Damit widerspricht der Skript-basierte Ansatz dem eigentlichen Ziel der Testautomatisierung: das Testing einfacher und schneller zu machen. Um dies zu erreichen, ist vielmehr eine Lösung gefragt, die die Automatisierung von Testfällen über den gesamten Technologie-Stack hinweg ermöglicht – von einer zentralen Plattform aus, ohne Code und mit minimalem Aufwand.
2. Die Testwartung verbessern
Ein anderer Grund, warum viele Testautomatisierungsprojekte scheitern, ist die Testwartung. Sie ist häufig so aufwendig, dass die erzielte Zeitersparnis wieder zunichte gemacht wird. Tests sorgfältig zu pflegen ist wichtig, um verlässliche Ergebnisse zu erhalten. Denn sonst schleichen sich zu viele False Positives oder False Negatives ein.
Bei der Wartung gibt es zwei große Herausforderungen: Tests, die instabil sind und solche, die sich schwer aktualisieren lassen. Wenn ein automatisierter Test fehlschlägt, obwohl sich die Anwendung nicht geändert hat, ist das ein Stabilitätsproblem. Lösen lässt es sich zum Beispiel mit stabileren Identifikatoren. Unternehmen sollten dieses Thema von Anfang an bei ihren Automatisierungsinitiativen mitberücksichtigen. Außerdem gilt es zu beachten, dass auch ungeeignete Testdaten oder instabile, unvollständige Umgebungen Tests zum Scheitern bringen können.
Der Schlüssel für das zweite große Problem – die Aktualisierbarkeit – liegt darin, Tests aus Modulen aufzubauen, die in der gesamten Testreihe wiederverwendet werden können. Wenn sich Geschäftsprozesse ändern, sollten sich einzelne Module leicht aktualisieren lassen und die betroffenen Tests automatisch synchronisiert werden. Um den Aufwand für die Testwartung generell zu reduzieren, ist es zudem wichtig, die Testsuite möglichst schlank zu halten. Dafür empfiehlt sich Linear Expansion als Test Case Design. Mit dieser Methode weiß das Team genau, welche Tests hinzugefügt werden müssen, wenn sich die Anwendung weiterentwickelt.
3. Auf API-Tests umstellen, wann immer es möglich ist
Bisher machen UI-Tests den größten Teil der funktionalen Testautomatisierung aus – nur ein kleiner Teil der Tests wird auf API-Ebene durchgeführt. Erstrebenswert ist dagegen ein umgekehrtes Verhältnis.
API-Tests sind besser für moderne Entwicklungsprozesse geeignet. Sie sind solider und leichter zu pflegen als UI-Tests und können früher in jedem Sprint implementiert und ausgeführt werden. Außerdem können sie auch Funktionen überprüfen, die außerhalb des Anwendungsbereichs von UI-Tests liegen. Dazu kommt, dass sich API-Tests viel schneller ausführen lassen. Daher eignen sie sich gut, um Auswirkungen von neuen Builds auf die Benutzererfahrung zu prüfen.
4. Die richtigen Tools auswählen
Es gibt viele kostenlose Tools und Open-Source-Testautomatisierungs-Tools auf dem Markt. Bei der Wahl der richtigen Lösung sollten Unternehmen jedoch stets an die Gesamtbetriebskosten denken und zum Beispiel auch Kosten für Trainings, die Entwicklung von Test-Frameworks oder die Testwartung einberechnen.
„Am Ende sind es die Menschen und die Unternehmenskultur, die über Erfolg oder Misserfolg der Testautomatisierung entscheiden.“
Viktoria Praschl, Tricentis
Vielleicht möchten verschiedene Teams unterschiedliche Tools einsetzen. Das kann sinnvoll sein. Denn Mitarbeiter, die eine kleine mobile App betreuen, haben andere Anforderungen als ein Team, das die Auswirkung häufiger Upgrades auf SAP-basierte geschäftskritische Transaktionen testet. Entscheidend ist, dass die Automatisierungslösung es jedem Team erlaubt, das beste Tool für seine Bedürfnisse zu wählen, dabei aber ein zentrales Reporting bietet.
Fazit: Die Strategie muss zum individuellen Bedarf passen
Nicht jede der genannten Empfehlungen ist auch für jedes Unternehmen relevant. Wer zum Beispiel nur eine einzige Schnittstelle oder eine einzige Technologie testen muss, hat kein Problem mit zu großer Komplexität. Auch die Wartung ist einfach, wenn Teams nur ein paar grundlegende Tests für eine weitgehend statische Anwendung automatisieren möchten. Sobald es aber um Applikationen geht, die sich über verschiedene Technologien erstrecken und sich schnell weiterentwickeln, sollten Unternehmen auf eine Lösung setzen, die eine einfache Automatisierung und Wartung von Ende-zu-Ende-Testfällen im gesamten Stack ermöglicht.
Die Wahl der richtigen Technologie und Strategie sollte immer auf den tatsächlichen Bedarf abgestimmt sein. Genauso wichtig ist es, Prozesse umzustellen und Mitarbeiter mit Change Management zu unterstützen. Denn am Ende sind es die Menschen und die Unternehmenskultur, die über Erfolg oder Misserfolg der Testautomatisierung entscheiden.
Über die Autorin:
Viktoria Praschl ist VP Sales Central Europe bei Tricentis.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
