Leitfaden für Software-Tests Einsatz der Testautomatisierungspyramide in der Softwareentwicklung

Anbieter zum Thema

Parasoft® Deutschland GmbH

MicroConsult Academy GmbH

emlix GmbH

Die von Mike Cohn entwickelte und von Martin Fowler populär gemachte Testautomatisierungspyramide hat unsere Sichtweise auf Softwaretests verändert. Sie zeigt, welche Tests und wie viele von jeder Art durchgeführt werden sollten. Doch was macht die Testautomatisierungspyramide für automatisierte Softwaretests so wichtig?

Mit Hilfe der Testautomatisierungspyramide ist es gelungen, effizientere Tests zu entwickeln und den Kunden zuverlässigere Software zu liefern.

Die meisten Vorteile der Testautomatisierung liegen auf der Hand:

• Kosten- und Zeitersparnis.

• Höhere Genauigkeit durch Eliminierung menschlicher Fehler.

• Möglichkeit, Tests zu wiederholen, wiederzuverwenden und an individuelle Softwareanforderungen anzupassen.

Wenn bei der Softwareentwicklung ein enger Zeit- und Budgetrahmen eingehalten werden muss, bringt allerdings die Automatisierung alleine nicht den gewünschten Erfolg. Ressourcen und Zeit bleiben weiterhin begrenzt. Wie kann man also die richtigen Arten von automatisierten Tests im richtigen Umfang entwerfen, um die Tests mit den Entwicklungspraktiken zu erweitern? Genau hierfür kann die Testpyramide als guter Leitfaden dienen.

Die Testpyramide durchlaufen

An der Basis befinden sich Unit-Tests, die die detailliertesten Tests darstellen, von denen ein Unternehmen viele haben sollte. Die nächsthöhere Ebene der Pyramide besteht aus Service-Layer- oder Integrationstests. Hier wird geprüft, wie die Softwarekomponenten miteinander interagieren, unabhängig davon, ob es sich um interne oder externe Integrationen handelt. An der Spitze steht der End-to-End-Test (E2E), er ist der komplexeste und testet die Software als Ganzes, um sicherzustellen, dass sie von Anfang bis Ende wie erwartet funktioniert.

Wenn man den Umfang der eigenen Testsuiten in jeder Schicht an dieser visuellen Metapher einer Pyramide ausrichtet (siehe Einleitungsbild), kann man die Tests skalieren, um eine zuverlässigere Software zu erhalten.

Die Basis: Unit-Tests

Ein Unit-Test wird an einem kleinen Teil des Codes durchgeführt, normalerweise an einer Funktion/Methode oder sogar an einer Klasse, um festzustellen, ob diese ihre Funktion korrekt erfüllt. Es sind einfache und schnelle Tests, deshalb sollte ein hoher Prozentsatz der Tests auf dieser Ebene durchgeführt werden. Wenn ein Unit-Test fehlschlägt, erhalten die Entwickler eine Benachrichtigung und können schnell feststellen, welche unbeabsichtigten Folgen ihre Code-Änderungen haben. Dies dient als wichtiges Sicherheitsnetz für zuverlässige Codeänderungen.

Trotz all ihrer Vorteile sind Unit Tests nicht das Nonplusultra des Testens. Bei Tests mit einem so engen Umfang und der Verwendung von Test-Doubles (wie Mocks und Stubs) geht die Überprüfung verloren, wie große Teile der Software zusammenarbeiten.

Wer Geschäftsanforderungen verifizieren will, tut sich mit Modultests schwer, denn ‚man sieht den Wald vor lauter Bäumen nicht‘. Eine Richtlinie, die Modultests den User Stories zuordnet und während der Bearbeitung verfolgt, kann allerdings helfen, Risiken im Zusammenhang mit bestimmten Funktionen zu identifizieren, wenn Instabilitäten in Modultests auftreten.

Das Zentrum: Service-Layer- bzw. Integrationstests

Integrationstests bilden die mittlere Ebene der Standardtestpyramide. Während Modultests sehr detailliert sind, kommen auf dieser Ebene Tests zum Einsatz, die zunächst überprüfen, ob größere Codepakete korrekt zusammenarbeiten. Aufgrund der Popularität von verteilten Systemarchitekturen mit Microservices und Cloud Deployments sind Integrationstests heute wichtiger denn je. Die Zeiten der Entwicklung monolithischer Anwendungen sind längst vorbei, und die unabhängig voneinander eingesetzten Softwarekomponenten vieler moderner Systeme lassen sich über ihre exponierten Schnittstellen miteinander integrieren, oft über REST oder einen Message Broker wie Apache Kafka oder ActiveMQ. Altsysteme werden nach und nach entkoppelt und in neue Softwarekomponenten zerlegt, die einfacher zu skalieren und zu testen sind, auch wenn ihre Bereitstellung komplexer ist.

Diese Tests sind langsamer als Modultests und erfordern die Bereitstellung der Software in einer Testumgebung, können aber heikle Probleme aufdecken, die bei Modultests übersehen werden. Im Vergleich zu End-to-End- oder Systemtests sind sie für ein effizientes Testen der Software unerlässlich. Aufgrund des größeren Testumfangs erhöht sich der Zeitaufwand für die Fehlerdiagnose und -behebung. Wie bei den Modultests können Integrationstests jedoch wiederholt werden, bis alle Tests erfolgreich sind und die Build-Pipeline bereit ist, zu den End-to-End-Tests überzugehen (oder wieder zurückzukehren).

In der modernen Softwareentwicklung sind Integrationstests ein sehr wenig geprüfter Bereich, da sie als „Mittelweg“ zwischen Entwicklungstests und Qualitätssicherungstests angesehen werden können. Man kann darüber diskutieren, wer diese Ebene testen sollte (Spoiler-Alarm ... die Antwort lautet: BEIDE), denn Integrationstests erfordern einen technisch sehr versierten Tester mit den entsprechenden Werkzeugen.

Die Spitze: End-to-End-Tests

Bei End-to-End-Tests wird der größte Teil des Codes (d. h. die gesamte Softwareanwendung von Anfang bis Ende) getestet. Dabei wird mit Hilfe von Daten und einer Testumgebung der tatsächliche Betrieb der Software simuliert. Diese Tests sind am teuersten in der Wartung und am langsamsten in der Ausführung. Da sie vollständig zusammengesetzte Anwendungen testen, sind sie auch die schwierigste Testphase, in der Probleme diagnostiziert werden müssen. Dafür sind sie am einfachsten zu entwerfen, da sie die geschäftlichen Anforderungen an die Software widerspiegeln. Auch ein weniger technisch versierter Business Analyst oder Product Owner kann definieren, was diese Tests leisten sollen. Dies erklärt möglicherweise die Beliebtheit von BDD (Behavior Driven Development)-Praktiken bei der Testautomatisierung.

Wenn Unternehmen ihren Softwareentwicklungsprozess weiterentwickeln und mit der Testautomatisierung beginnen, geraten viele in die Falle, dass die meisten ihrer Tests in diese Kategorie fallen. Irgendwann stoßen sie auf einen Engpass. Die Entwicklung nimmt agile und DevOps-Praktiken an und wird schneller. Aber das Testen hinkt immer hinterher, weil neue Funktionen nicht getestet werden. Zudem haben Tests im Allgemeinen nur einen begrenzten Einfluss auf die Erkennung von Software-Qualitätsproblemen wegen des zunehmenden Entwicklungstempos. Das macht die Testpyramide so wertvoll, wenn es um die Modernisierung von Teams geht.

Ohne Automatisierung ist es nicht möglich, Schritt zu halten. Noch wichtiger ist, dass man nur mithalten kann, wenn man einen soliden Plan hat, wie getestet werden soll. An diesem Punkt fangen Unternehmen an, „Lean UI Testing“ als Mantra zu schätzen, da sie aus erster Hand sehen, dass ihre Teststrategie nicht mehr mit dem Entwicklungstempo Schritt halten kann. Wenn man feststellt, dass das eigene Unternehmen in diesem Paradigma gefangen ist, sollte man nach Möglichkeiten suchen, funktionale Tests von der UI-Ebene auf die Service-Ebene verlagern. UI-Tests sollten sich weiterhin auf das Testen von clientseitiger Logik, der Benutzererfahrung, der kritischen Pfade und der plattformübergreifenden Zertifizierung konzentrieren.

Eine Testautomatisierungspyramide zur Steigerung der Software-Qualität

Qualität kann nicht in eine Anwendung hineingetestet werden, auch wenn die Testautomatisierungspyramide einen Entwurf für eine effiziente Testautomatisierungsstrategie bietet. Sondern die Pyramide muss auf dem soliden Fundament einer gründlichen Codeanalyse aufgebaut werden, die sich auf das Identifizieren und Vermeiden von Zuverlässigkeits- und Sicherheitsproblemen konzentriert. Unternehmen finden auf dem Markt hochqualifizierte Lösungen zur Unterstützung, so zeigt beispielsweise die Parasoft Testpyramide, wie die Lösungen der Continuous Quality Testing Platform das Testen auf jeder Ebene automatisieren.

Die Ergebnisse dieser Ebenen können in Parasoft DTP, dem Berichts-, Analyse- und Dashboard für die Einhaltung von Vorschriften, konsolidiert werden und bieten so einen einheitlichen Überblick über die Softwarequalität und die Testabdeckung. Damit erhält das Team Einblicke, um den Status ihrer Anwendung zu analysieren und die nächsten Schritte zur Erreichung ihrer Ziele festzulegen. (sg)

* Wilhelm Haaker ist Director of Solution Engineering bei Parasoft.

(ID:50184764)