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.