Viele Teams automatisieren am falschen Ende. Sie bauen Dutzende langsame Oberflächentests, sparen aber an schnellen Unit-Tests – und wundern sich über brüchige, zähe Pipelines. Die Testpyramide liefert das Gegenmodell: ein einfaches Bild dafür, wie sich automatisierte Tests sinnvoll verteilen. Viele kleine, schnelle Tests unten, wenige breite Tests oben. Das Modell ist über fünfzehn Jahre alt und gilt trotz KI-Hype unverändert. Dieser Leitfaden zeigt Ihnen Herkunft, die drei Schichten, das verbreitete Anti-Pattern der Eistüte sowie ehrliche Alternativen wie die Testing Trophy – und was sich im KI-Zeitalter tatsächlich ändert.

Kurz gefasst: Die Testpyramide ordnet automatisierte Tests nach Granularität: viele schnelle Unit-Tests an der Basis, einige Integrationstests in der Mitte, wenige End-to-End-Tests an der Spitze. Martin Fowler beschreibt sie als „a way of thinking about how different kinds of automated tests should be used” (Fowler, 2012). UI-Tests sind teuer und brüchig – deshalb oben wenige.

Abbildung 1: Die Testpyramide – viele schnelle Tests unten, wenige langsame oben.

Was ist die Testpyramide?

Die Testpyramide ist ein Denkmodell für die Verteilung automatisierter Tests über verschiedene Granularitätsstufen. Martin Fowler fasst sie als „a way of thinking about how different kinds of automated tests should be used” zusammen und betont: deutlich mehr maschinennahe Unit-Tests als breite, systemumspannende Tests (Fowler, 2012). Die Form ist die Botschaft.

Die Logik dahinter ist Ökonomie, nicht Dogma. Tests an der Basis sind schnell, billig und stabil – Sie können Tausende davon bei jedem Commit ausführen. Tests an der Spitze prüfen das Gesamtsystem durch die Oberfläche, sind aber langsam und anfällig. Deshalb wenige davon, gezielt eingesetzt.

Warum überhaupt ein Bild? Weil Teststrategie sonst zur Bauchentscheidung wird. Die Pyramide gibt Teams eine gemeinsame Sprache: Gehört dieser neue Test nach unten, in die Mitte oder nach oben? Diese eine Frage verhindert die teuersten Fehlverteilungen.

Den größeren Zusammenhang erklären wir in unserem Überblick zu den Software-Testing-Grundlagen.

Woher stammt das Modell? Mike Cohn und Martin Fowler

Das Konzept geht auf Mike Cohn zurück, der es 2009 in *Succeeding with Agile* als „Test Automation Pyramid” prägte; popularisiert und präzisiert hat es anschließend Martin Fowler (Fowler, 2012). Cohns Originalfassung benannte drei Ebenen: Unit, Service und UI – von unten nach oben.

Cohns Kernanliegen war ein Korrektiv. Agile Teams automatisierten Anfang der 2010er bevorzugt über die Oberfläche, weil das intuitiv wirkt. Genau davor warnt die Pyramide: Wer Stabilität primär über UI-Tests sucht, baut eine teure, fragile Suite.

„Write lots of small and fast unit tests. Write some more coarse-grained tests and very few high-level tests.” — Ham Vocke (Fowler, 2018)

Ham Vockes vielzitierte „Practical Test Pyramid” aktualisierte das Modell 2018 für Microservices und moderne CI/CD-Pipelines. Die Schichtnamen variieren seither – Service heißt heute oft Integration –, die Grundaussage blieb identisch: viel unten, wenig oben.

Welche drei Schichten hat die Testpyramide?

Abbildung 2: Drei Schichten im Vergleich – je höher, desto langsamer und teurer.

Die klassische Pyramide besteht aus drei Schichten, die sich in Umfang, Geschwindigkeit und Stabilität klar unterscheiden (Fowler, 2018). Von unten nach oben: Unit-Tests bilden die breite Basis, Service- bzw. Integrationstests die Mitte, UI- und End-to-End-Tests die schmale Spitze. Je höher, desto weniger.

Warum sitzt unten mehr? Weil Feedbackgeschwindigkeit über Produktivität entscheidet. Ein fehlschlagender Unit-Test zeigt in Millisekunden exakt die Ursache. Ein fehlschlagender E2E-Test sagt nur: „irgendetwas ist kaputt” – und Sie suchen.

Jede Schicht ergänzt die anderen, ersetzt sie aber nicht. Unit-Tests prüfen Logik isoliert. Integrationstests prüfen, ob Module miteinander sprechen. E2E-Tests prüfen, ob kritische Geschäftsflüsse durch das ganze System tragen – sparsam und gezielt.

Wie ein guter Unit-Test konkret aussieht, lesen Sie in unserem Beitrag zum Unit-Test. Für die Mitte vertiefen wir das im Leitfaden zum Integrationstest, für die Spitze im Beitrag zum End-to-End-Test.

Warum sind UI- und E2E-Tests an der Spitze so knapp?

E2E-Tests gehören nach oben, weil sie laut Fowler „brittle, expensive to write, and time consuming to run” sind (Fowler, 2012). Sie haben hohen Wert – sie prüfen das System aus Nutzersicht –, aber jeder einzelne kostet viel und bricht leicht. Deshalb: wenige, dafür die wichtigsten.

Google hat die Argumente 2015 zugespitzt: End-to-End-Tests seien langsam, „flaky” und schwer zu debuggen, weil ein roter Lauf Dutzende mögliche Ursachen hat (Google Testing Blog, 2015). Flakiness ist dabei das tückischste Problem: Tests, die mal grün, mal rot laufen, untergraben das Vertrauen ins gesamte Gating.

Eine ehrliche Klarstellung, weil sie ständig falsch zitiert wird: Die populäre 70/20/10-Aufteilung ist Community-Folklore, kein Google-Zitat. Der Google-Beitrag nennt keine festen Prozentzahlen, sondern formuliert nur, man solle „that pyramid shape” beibehalten (Google Testing Blog, 2015). Nutzen Sie konkrete Zahlen als grobe Orientierung, nicht als Gesetz.

Wie Sie genau diese brüchigen Oberflächentests stabil halten, zeigt unser Beitrag zum Regressionstest.

Was ist das Eistüten-Anti-Pattern?

Abbildung 3: Pyramide vs. Eistüte – das verbreitetste Anti-Pattern der Teststrategie.

Die „Software Testing Ice-Cream Cone” beschreibt die umgekehrte Pyramide: oben breit, unten schmal. Den Begriff prägte Alister Scott 2012 für Teams mit vielen manuellen und automatisierten UI-Tests, aber kaum Unit-Tests (WatirMelon, 2012). Die Eistüte ist das verbreitetste Versagensmuster der Teststrategie.

So entsteht sie meist schleichend. Ein Team hat wenig Unit-Test-Kultur, will aber „testen” – also automatisiert es über die Oberfläche, weil das sichtbar und intuitiv ist. Mit jedem Sprint wachsen die UI-Tests, die Basis bleibt dünn. Die Suite wird langsamer, brüchiger, teurer.

In Kundenprojekten sehen wir die Eistüte fast immer dort, wo Testautomatisierung erst spät und ausschließlich auf E2E-Ebene startete. Die Symptome sind eindeutig:

• Pipelines, die zehn Minuten oder länger laufen, bevor irgendein Feedback kommt

• „Flaky” Tests, die per Re-Run grün gemacht statt repariert werden

• Entwickler, die rote Builds ignorieren, weil sie ihnen nicht mehr vertrauen

• niemand traut sich zu refactoren, weil das Sicherheitsnetz fehlt

Der Ausweg ist kein großer Rewrite. Stoppen Sie das Wachstum der Spitze, und bauen Sie die Basis bei jedem neuen Feature aus. Die Form kippt langsam zurück.

Pyramide, Trophy oder Test Shapes – welches Modell stimmt?

Es gibt mehr als ein Bild, und der Streit darum ist oft definitorisch. Kent C. Dodds schlug die „Testing Trophy” vor: „Write tests. Not too many. Mostly integration.” – mit einem dickeren Integrations-Bauch statt einer breiten Unit-Basis (Kent C. Dodds, 2021). Für Frontend- und Komponentenwelten klingt das überzeugend.

Martin Fowler ordnete die Debatte 2021 ein: Der Streit zwischen Pyramide und Trophy sei größtenteils ein Definitionsstreit darüber, was „Unit” und was „Integration” heißt (Fowler, 2021). Wer „Unit” eng fasst, braucht mehr Integrationstests; wer es weit fasst, landet wieder bei der Pyramide.

Fowlers eigentlicher Rat ist deshalb formunabhängig: Schreiben Sie Tests, die schnell und zuverlässig laufen und nur aus nützlichen Gründen fehlschlagen (Fowler, 2021). Das ist der gemeinsame Nenner aller Modelle. Die Form ist ein Mittel; das Ziel ist schnelles, verlässliches Feedback.

Welche Testarten überhaupt in welche Schicht gehören, ordnet unser Überblick zu den Testarten ein.

Gilt die Testpyramide im KI-Zeitalter noch?

Abbildung 4: Die Pyramide im KI-Zeitalter – KI senkt die Kosten, nicht die Physik.

Ja – und eine peer-reviewte Arbeit stützt das ehrlich. Die „Test Pyramid 2.0” argumentiert, dass KI verbessert, *was* auf jeder Schicht getestet wird (Generierung, Fehlervorhersage), während die *Form* der Pyramide – Geschwindigkeit und Mengenverhältnis – unverändert bleibt (Frontiers in AI, 2025). KI verschiebt das Wie, nicht das Was-wohin.

Das ist die zentrale, oft missverstandene Unterscheidung. KI kann Unit-Tests generieren, Lücken vorschlagen und brüchige Oberflächentests per Self-Healing stabilisieren. Was KI nicht ändert: Ein E2E-Test bleibt langsam und durchläuft den ganzen Stack – egal, ob ein Mensch oder ein Modell ihn geschrieben hat. Physik schlägt Hype.

Daraus folgt eine nüchterne Erwartung. KI senkt die *Schreibkosten* von Tests, nicht ihre *Laufkosten*. Wer mit generierten E2E-Tests die Spitze aufbläht, baut eine schnellere Eistüte – kein besseres Sicherheitsnetz. Der sinnvolle Hebel liegt darin, die teure Basisarbeit zu beschleunigen und brüchige Oberflächentests wartungsarm zu halten.

Genau hier setzt Autemos an: Self-Healing-Locators halten die wenigen, aber wichtigen UI- und E2E-Tests an der Spitze stabil, wenn sich Oberflächen ändern – statt sie rot laufen zu lassen. Die Pyramidenform bleibt, der Wartungsaufwand sinkt. Mehr dazu unter Test-Workflows.

Häufig gestellte Fragen

Wie viele Tests gehören in jede Schicht?

Es gibt keine allgemeingültige Zahl. Die oft zitierte 70/20/10-Regel ist Community-Folklore, kein verbindlicher Standard – Googles Beitrag nennt keine Prozente, nur „that pyramid shape” beibehalten (Google Testing Blog, 2015). Orientieren Sie sich an der Form: viel Basis, wenig Spitze, statt an festen Quoten.

Was ist der Unterschied zwischen Testpyramide und Eistüte?

Die Pyramide steht auf breiter Unit-Basis mit schmaler UI-Spitze. Die Eistüte ist genau umgekehrt: viele langsame UI-Tests oben, kaum Unit-Tests unten (WatirMelon, 2012). Die Eistüte gilt als Anti-Pattern, weil sie langsame, brüchige und teure Test-Suiten erzeugt.

Ist die Testing Trophy besser als die Testpyramide?

Nicht grundsätzlich – es kommt auf den Kontext an. Die Trophy betont Integrationstests und passt gut zu Frontend-Komponenten (Kent C. Dodds, 2021). Fowler hält den Streit für überwiegend definitorisch (Fowler, 2021). Wichtiger als das Bild: schnelle, verlässliche Tests, die nur aus nützlichen Gründen fehlschlagen.

Macht KI die Testpyramide überflüssig?

Nein. KI verbessert, *was* auf jeder Schicht getestet wird, ändert aber die *Form* nicht (Frontiers in AI, 2025). E2E-Tests bleiben langsam und brüchig, unabhängig davon, wer sie schreibt. KI senkt Schreib- und Wartungskosten – die Logik „viel unten, wenig oben” gilt unverändert.

Wo sitzen Regressionstests in der Pyramide?

Regressionstest ist keine eigene Schicht, sondern ein Zweck. Regressionsprüfungen finden auf allen Ebenen statt – als Unit-, Integrations- oder E2E-Test (Fowler, 2018). Praktisch sollten die meisten Regressionstests unten laufen, damit Ihre Regressionssuite schnell bleibt. Mehr dazu im Beitrag zum Regressionstest.

Fazit

Die Testpyramide ist über fünfzehn Jahre alt und überraschend langlebig, weil sie kein Werkzeug beschreibt, sondern eine Ökonomie: Feedback muss schnell, billig und verlässlich sein. Viel unten, wenig oben – das hält Pipelines schnell und Vertrauen hoch. Die Eistüte ist die teure Kehrseite, und sie entsteht fast immer schleichend. Ob Sie Pyramide, Trophy oder „Test Shapes” sagen, ist sekundär; Fowlers Maßstab zählt: Tests, die schnell laufen und nur aus nützlichen Gründen fehlschlagen (Fowler, 2021). Im KI-Zeitalter bleibt die Form stabil – KI senkt die Kosten, nicht die Physik. Halten Sie Ihre Spitze schlank und stabil. Sprechen Sie mit unserem Team, wie Sie Ihre Teststrategie entlang der Pyramide aufbauen.