Get in touch
Engpässe beim Testen? Seien wir doch mal ehrlich. In vielen Softwareentwicklungsprojekten führt das Softwaretesten noch immer zu einem Engpass, der den Release-Prozess verzögert. Je größer die Projekte – desto spürbarer wird dieser Engpass. Das oft so angepriesene Wundermittel hierbei lautet „Testautomatisierung“ – in der Theorie klingt Testautomatisierung auch danach: Einmal implementiert, ausführbar 24/7. Doch in der Praxis verzweifeln viele Teams beim Einsatz von Testautomatisierung. Zu oft bringen die eingesetzten Ressourcen nicht den erhofften Mehrwert. Sei es, weil die Testautomatisierung nicht die richtigen Informationen liefert und/oder die automatisierten Testfälle nicht zuverlässig sind.
In den nächsten Abschnitten gehen wir auf acht Charakteristiken ein, die sicherstellen, dass die Testautomatisierung den erhofften Mehrwert liefert. Stell dir doch dabei die Frage: Wie viele der acht Charakteristiken erfüllt die von Euch eingesetzte Testautomatisierung?
Softwaretesten verfolgt das Ziel, wichtige Informationen über das Produkt zu sammeln und seinen Zustand aufzudecken. Diese Informationen dienen als Entscheidungsgrundlage für alle am Softwareentwicklungsprozess beteiligten Personen. Nur weil eine Test Suite aus 1.000 automatisieren Testfällen besteht, bedeutet dies nicht, dass die Informationen einen Mehrwert haben. Die zentrale Frage ist, ob die Testautomatisierung die richtigen Informationen über das Produkt liefert. Um die Qualität der Testautomatisierung beurteilen zu können, sollte man sich demnach die Frage stellen, ob sie die als kritisch eingestuften Funktionalitäten abdeckt. Das Charakteristikum „Informativ“ sollte die wichtige Frage beantworten, habe ich die kritischen Risiken identifiziert und abdecket.
Ein Testfall ist eine Frage, die wir der Anwendung stellen. Je präziser die Frage, desto präziser ist die Antwort. Bevor wir entscheiden, auf welche Teststufe (Unit, Integrationstest, End-2-End) wir den automatisierten Testfall implementieren, sollten wir die Frage stellen: „Welches identifizierte Risiko möchte ich mit meinem Testfall abdecken und damit minimieren?“
Will ich das Risiko minimieren,
Fokussierte automatisierte Testfälle identifizieren, ob Ist- und Sollzustand voneinander abweichen. Nachdem wir die Risiken identifiziert haben und die automatisierten Testfälle diese Risiken auf der geeigneten Teststufe abdecken, können wir Fehlerzustände schneller identifizieren. Das Charakteristikum „Risikofokussiert“ sollte die Frage beantworten, auf welcher Teststufe die identifizierten Risiken optimal abgedeckt werden sollen.
Eine große Herausforderung bei der Testautomatisierung stellen unzuverlässige Testfälle dar (=engl. „flaky“). Flaky Testfälle schlagen ohne ersichtlichen Grund fehl. Zuverlässige Testfälle sollten nur fehlschlagen, wenn das Systemverhalten von dem definierten Soll-Zustand abweicht. Dies kann gerade bei automatisierten Testfällen, die über die Benutzeroberfläche ausgeführt werden, eine große Herausforderung sein.
Wenn unzuverlässige Testfälle ein fester Bestandteil der Test Suite sind, führt dies oft zu einer unzureichenden Aufmerksamkeit der Testfälle. Die Unzuverlässigkeit führt zu einem Vertrauensverlust: es wird davon ausgegangen, dass die fehlschlagenden Testfälle flaky sind. Dies führt oftmals zu einem Verzicht von genauen Analysen, da die flaky Testfälle als gegeben angesehen werden. Dies reduziert den Mehrwert der Testautomatisierung. Der Aufwand steht in keiner Relation zum Mehrwert. In der Regel gibt es vier Gründe für flaky Tests:
Die Testautomatisierung sollte fester Bestandteil der Teststrategie sein. Dabei gilt es auf eine kontinuierliche Abstimmung von allen am Softwareentwicklungsprozess beteiligten Personen zu achten. In agilen Teams sind Softwareentwickler:innen typischerweise für die Unit-Tests zuständig. Die Integrationstests werden entweder von den Softwareentwickler:innen oder Softwaretester:innen implementiert. Für die automatisierten End-2-End Testfälle sind meist Softwaretester:innen verantwortlich. In der Praxis fehlt leider oftmals die Abstimmung zwischen allen Beteiligten. Die Softwaretester:innen wissen demnach nicht, was auf der Unit-Test- und Integrationstest-Ebene abgedeckt ist und werden kann. Durch fehlende Kommunikation zwischen den beteiligten Parteien kann es passieren, dass Tests wichtige Risiken nicht abdecken und/oder Redundanzen von automatisierten Tests entstehen. Redundanzen von Tests führen zu höherem Wartungsaufwand und langsamer Testausführung.
Automatisierte Testfälle sollten wartungsfreundlich sein. Gerade zu Beginn des Softwareentwicklungsprozesses ändert sich die Anwendung häufig. Dies führt zu einem hohen Aufwand, da das Team die Testfälle entsprechend oft anpassen muss. Passende Design Patterns reduzieren diesen Wartungsaufwand.
Oft ist es in Softwareentwicklungsprojekten der Fall, dass die Wartung der Testautomatisierung genauso viel Kapazität einnimmt, wie die Implementierung neuer Testfälle, weil bei der Implementierung der Testautomatisierung, die Wartungsfreundlichkeit nicht berücksichtigt wurde.
Die automatisierten Testfälle sollen schnelles Feedback über die Qualität der zu testenden Anwendung liefern. Je höher wir in der Testautomatisierungspyramide kommen (siehe Abbildung), desto langsamer werden die automatisierten Testfälle. Eine Lösung ist es, die automatisierten Testfälle parallel auszuführen. Dies erhöht die Ausführung der Testfälle rasant.
Das Softwareentwicklungsprojekt ist gewachsen. Es kommen inkrementell neue Features dazu, die zu neuen Geschäftsprozessen führen. Diese Prozesse konnten bei der Implementierung der Testautomatisierung nicht bedacht werden. Folglich müssen Testfälle, die die neuen Geschäftsprozess abdecken, oftmals mühsam in das Testautomatisierungsframework integriert werden. Dies birgt die Gefahr von Code-Wiederholungen, was dem Prinzip „Don’t repeat yourself“ widerspricht.
An der Testautomatisierung wirken unterschiedliche Rollen mit. Bei der Implementierung gilt es dies zu berücksichtigen. Das Testautomatisierungsframework sollte so implementiert werden, dass keine wochenlangen Schulungen nötig sind, um aktiv mit dem Testautomatisierungsframework zu arbeiten. Das Testautomatisierungsframework sollte selbsterklärend sein.
