Testautomatisierung – warum es in vielen agilen Projekten nicht optimal eingesetzt wird

Testautomatisierung – Fester Bestandteil der agilen Softwareentwicklung

Testautomatisierung ist ein fester Bestandteil der agilen Softwareentwicklung. Trotzdem habe ich oft die Erfahrung gemacht, dass die Testautomatisierung in vielen agilen Projekten nicht optimal eingesetzt wird. Es fängt damit an, dass die Testautomatisierung oft isoliert vom manuellen Testen gesehen wird. Selbst die Testautomatisierungsstufen sind in vielen Fällen nicht aufeinander abgestimmt. Die nächsten Abschnitte gehen näher auf den letzten Punkt ein.

Testautomatisierungspyramide

Wenn wir uns die Testautomatisierungspyramide anschauen (siehe Abbildung 1), sehen wir drei Arten von automatisierten funktionalen Tests: Unit-Tests, Integrationstests und End-2-End-Tests. In der Praxis gibt es noch andere Arten von automatisierten Funktionalen Tests. In diesen Artikel fokussieren wir uns auf diese drei, da die Problematik auch bei Zunahme andere Testarten besteht.

Die Unit-Tests – Was der Softwaretester nicht weiß

Der Prozess startet bei den Unit-Tests. Die Entwickler implementieren in der Regel die Unit-Tests und oft hat der Softwaretester keinen Überblick, aus welchen Komponenten bspw. ein Microservice besteht. Dies führt dazu, dass der Softwaretester keinen oder nur wenig Informationen darüber hat, was auf der Unit-Test-Ebene abgedeckt ist und welche Abdeckung auf Unit-Test-Ebene möglich ist.

Die Integrationstests – Die Problematik führt sich fort

Bei den Integrationstests führt sich dieses Verhalten fort. In der Regel werden auch die Integrationstests von den Softwareentwicklern implementiert. Im Microserivce-Umfeld sollte hier die Business-Logik getestet werden. Dadurch, dass der Softwaretester keinen Überblick über die Testabdeckung auf Integrationstest-Ebene hat, wird oft die Business-Logik auf End-2-End-Testebene abgedeckt. Das führt unteranderem zu Redundanz und einer großen Anzahl an automatisierten Testfällen auf End-2-End-Testebene. Dies hat auch die Konsequenz, dass der Softwaretester die manuellen und automatisierten End-2-End-Tests nicht optimal im Testprozess abstimmen kann.

Erhöhung der Problematik durch Font-End und Back-End Teams

Die Abstimmungsproblematik wird noch erhöht, wenn bspw. die agilen Teams nicht Cross-Funktional sind und ein oder mehrere Back-End-Teams und Front-End-Teams an der Implementierung der Anwendung beteiligt sind. In diesem Fall wissen die einzelnen Tester oft über die Testabdeckung der unterschiedlichen Teams nicht Bescheid.

Was für uns funktioniert hat

Eine Möglichkeit, die wir eingesetzt haben, um den Softwaretestern einen Überblick über die Unit-Tests und Integrationstest zu verschaffen, ist bspw. im Pair Progamming zusammen mit den Entwicklern die Unit-Tests und Integrationstests zu implementieren. Dies führt unteranderem zu den folgenden Vorteilen:

• Der Softwaretester bekommt einen Überblick, welche Testabdeckung auf Unit-Test und Integrationstest-Ebene möglich ist.
• Der Softwaretester hat die Informationen, was bereits auf Unit-Test- und Integrationstest-Ebene abgedeckt ist.
• Der Softwaretester kann mit seinem Testing-Know-How zusammen mit den Entwicklern die Unit-Tests und Integrationstests optimieren.
• Der Softwaretester bekommt bspw. einen Überblick über den Aufbau eines Micro Services

Wird eine Anwendung von mehreren agilen Teams entwickelt, hat der jeweilige Tester eines Teams in der Regel nicht die Kapazitäten, um sich einen Überblick über die Testabdeckung der anderen Teams zu verschaffen. Hier haben wir gute Erfahrung damit gemacht, eine neue Rolle einzusetzen, welche unter anderem Überblick über die Testabdeckung der einzelnen Teams hat und diese optimal aufeinander abstimmt und koordiniert.

 Deine Erfahrung

Welche Erfahrungen hast du mit dem Einsatz von Testautomatisierung in Deinem Projekt gemacht? Über Dein Feedback würden wir uns in den Kommentaren freuen!