Testautomatisierung kann in verschiedenen Dimensionen erfolgen und mithilfe unterschiedlicher Methoden durchgeführt werden. Eine Grundlage zur Strukturierung und Priorisierung von Tests bietet uns die von Mike Kohn erfundene Testpyramide. Üblicherweise gliedert sie sich in Komponententests, Integrationstests, System – und Abnahmetests: Doch wann ist welche Testart von Bedeutung und welche Rolle spielt dabei die Automatisierung?
Dieser Beitrag soll Antworten liefern.
Geschichte und Enstehung der Testpyramide
In den Anfangsjahren der Softwareentwicklungen (1950er-1980er Jahre) erfolgte die Qualitätssicherung oft unsystematisch. Erst 1979, mit der Entstehung von strukturierten Konzepten wie dem V-Modell & Wasserfallmodell, legte Glenford Myers ein erstes Buch namens „The Art of Software Testing“ über systematische Qualitätssicherung vor. Myers sah den Nutzen von Softwaretests nicht darin zu prüfen, dass eine Software korrekt läuft, sondern proaktiv nach Fehlern zu suchen. Sein Blickwechsel brachte damals einen ganz neuen Spirit in das Test-Engineering.
Im Zuge agiler Methoden, etwa um die Jahrtausendwende, klagten Entwicklerteams häufig über zu lange Testphasen am Ende eines Entwicklungsprozesses – zügiges, automatisiertes Feedback war gewünscht. Selenium wartete mit einer Lösung auf und legte einen neuen Meilenstein in der Testautomatisierung. Doch Mike Kohn, der Begründer von Scrum, sah ein immer wiederkehrendes Problem: Viele Entwickler legten ihren Fokus zu sehr auf End-to-End-Tests, die zeitaufwändig und teurer waren. Daraufhin stellte er in seinem Buch „Succeeding with Agile“ (2009) erstmals die Testpyramide vor, wobei er Folgendes betonte:
„Je tiefer in der Pyramide, desto schneller und stabiler sind die Tests.“
Das International Software Testing Qualifications Board definiert die Pyramide laut Glossar heute wie folgt:
„Ein graphisches Modell, welches das Verhältnis der Testumfänge der einzelnen Teststufen darstellt, mit mehr Umfang an der Basis als an der Spitze.“
Im Folgenden wollen wir uns die einzelnen Teststufen nun etwas genauer anschauen. Die unterste Ebene wird dabei aufsteigend zuerst vorgestellt.
1. Komponententests:
Komponententests, auch Unit-Tests genannt, bilden die Basis der Testpyramide. Sie prüfen einzelne Methoden oder Funktionen. Anders formuliert testen sie, ob kleine Codeabschnitte genau das tun, was sie sollen. Sie werden häufig von den Entwicklern selbst geschrieben und oft auch „automatisierte Entwicklertests“ genannt. Komponententests sind im Vergleich zu den anderen Teststufen schneller zu konzipieren und rein technischer Natur.
Beliebte Tools zur Automatisierung: Mocha, Jest, JUnit, pytest
Beispiel Online-Shop: Prüft, ob das Rabattieren durch einen Gutschein die richtige Summe liefert.
Englische Definition ISTQB: „The testing of individual software components“.
2. Integrationstests:
Die auf der ersten Ebene getesteten Komponenten werden durch den Integrationstest auf ihr korrektes Zusammenspiel überprüft. Genauer gesagt, prüft der Integrationstest, ob verschiedene Services und Module fehlerfrei miteinander harmonieren.
Beliebte Tools zur Automatisierung: Postman, RestAssured, Cypress
Beispiel Online-Shop: Prüft, ob der API-Endpunkt den korrekten Preis eines Artikels aus der Datenbank bereitstellt.
Englische Definition ISTQB: „Testing performed to expose defects in the interfaces and interaction between integrated components.“
3. Systemtests:
Wie es der Name schon erahnen lässt, nimmt dieser Test das ganze System ins Visier. Häufig werden hier gleich mehrere grafische Benutzer- und Datenbankschnittstellen im Zusammenspiel geprüft. Systemtests können End-to-End-Userszenarien abdecken und verlangen häufig auch fachliche Expertise von den Testschreibenden.
Beliebte Tools zur Automatisierung: Selenium, Cypress, WebdriverIO, Postman, RestAssured
Beispiel Online-Shop: Prüft den gesamten Bezahlvorgang, um ein Produkt im Shop zu kaufen.
Englische Definition von ISTQB: „The process of testing an integrated system to verify that it meets specified requirements.“
4. Abnahmetest:
Der Abnahme, auch als Akzeptanztest oder E2E-Test bekannt, stellt sicher, dass die Applikation aus Sicht des späteren Anwenders wie gewünscht funktioniert. Häufig dient dieser Test dazu, die zu Beginn der Softwareentwicklung definierten Anforderungen vom Kunden abnehmen zu lassen. Abnahmetests sind in der Regel wartungs- und zeitintensiver.
Beliebte Tools zur Automatisierung: Selenium, Playwright, WebdriverIO, Cypress
Beispiel Online-Shop: Prüft den gesamten Workflow eines Users, von der Anmeldung bis zur Kaufbestätigung aus dem Warenkorb.
Englische Definition ISTQB: „Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.“
Fazit zur Testpyramide
Die Testpyramide ist nun seit über 15 Jahren im Test-Engineering verbreitet und dient definitiv als solide Orientierungshilfe, um eine effiziente Teststrategie zu entwickeln. Jedoch sollte nicht unerwähnt bleiben, dass die starre Hierarchie häufig nicht gänzlich zur Realität passt. Gerade in Frontend-Projekten und in Micoservice-Architekturen sind UI-Tests und Integrationstests der feste Bestandteil einer guten Testautomatisierungsstrategie. Auch konzentriert sich die Pyramide meiner Meinung nach zu stark auf funktionale Tests, Last- und Performance-Tests bleiben hier völlig unbeachtet.
Weiterführende Links
FAQ
Was ist die Testpyramide und wofür wird sie eingesetzt?
Die Testpyramide ist ein Konzept zur Strukturierung von Softwaretests nach Priorität und Umfang. In der Praxis dient sie dazu, Tests effizient zu planen: viele Unit-Tests an der Basis, weniger Integrationstests in der Mitte und wenige End-to-End-Tests an der Spitze.
Warum ist die Testpyramide wichtig?
Die Testpyramide hilft, Zeit und Ressourcen zu sparen. Aus Erfahrung zeigen Projekte, die die Pyramide ignorieren, oft hohe Wartungskosten bei End-to-End-Tests, während gut strukturierte Testpyramiden stabiler und schneller sind.
Welche Testarten gehören zu den Stufen der Pyramide?
> Unit-Tests bilden die Basis und prüfen einzelne Funktionen.
> Integrationstests befinden sich in der mittleren Ebene und prüfen das Zusammenspiel mehrerer Komponenten.
> End-to-End-Tests bilden die Spitze und simulieren vollständige Nutzerprozesse.
In Projekten nutzen viele Unternehmen z. B. WebdriverIO für die E2E-Tests und Mocha für Unit-Tests.
Ist die Testpyramide für alle Projekte geeignet?
Ja, grundsätzlich für alle Softwareprojekte. Allerdings kann die genaue Höhe der Pyramide je nach Projekt variieren. Bei kleinen Projekten können Integrationstests reduziert werden, während komplexe Anwendungen mehr End-to-End-Tests benötigen.
Gibt es Alternativen zur klassischen Testpyramide?
Ja, z. B. das Test-Diamant- oder Test-Eisberg-Modell. In meiner Erfahrung lohnt es sich, die Grundidee der Pyramide beizubehalten, da sie eine gute Balance zwischen Testabdeckung, Geschwindigkeit und Wartbarkeit bietet.
Wie kann ich die Testpyramide in Projekten umsetzen?
Ich empfehle, die Testarten konsequent zu trennen, Unit-Tests automatisiert auszuführen und End-to-End-Tests nur für wenig Pfade zu nutzen. Tools wie WebdriverIO oder Playwright erleichtern die Umsetzung der Spitze der Pyramide erheblich.