Tools sind keine Lösung für die Testautomatisierung

Eine Testautomatisierungsstrategie beginnt mit dem Problem, das du lösen willst, nicht mit der Wahl eines Tools. Am Anfang steht der Abgleich von Ist- und Soll-Zustand über alle Teststufen, meist dargestellt als Testpyramide mit Unit-, API- und UI-Tests. Die Lücke dazwischen bestimmt den Arbeitsumfang. Werkzeuge, Framework-Design und Automatisierungsarchitektur kommen erst, wenn das Problem klar ist.

Das Wichtigste in Kürze

• Eine Toolauswahl ergibt erst Sinn, wenn das Team geklärt hat, welches Problem die Testautomatisierung lösen und welchen Nutzen sie bringen soll.
• Eine Testautomatisierungspyramide, die Ist- und Soll-Zustand gegenüberstellt, zeigt auch Stakeholdern ohne Technikhintergrund konkret, wohin Aufwand und Geld wandern sollten.
• Dieselbe Funktionalität auf mehreren Pyramidenstufen zu testen ist nicht redundant: Unit-Tests bewerten die Codequalität, UI-Tests prüfen, ob die integrierten User Journeys wie gedacht funktionieren.
• Das Testautomatisierungsframework (Skripte, Business-Logik-Schicht, Codebibliotheken) ist nur ein Teil der Testautomatisierungslösung. Die Einbindung in die Pipeline und die Anbindung externer Systeme gehören genauso dazu.
• Ohne mindestens eine Person im Team, die schon Erfahrung mit Testautomatisierung hat, scheitert die Einführung oder kostet deutlich mehr als geplant.

Erst das Problem, dann das Tool

Am Anfang jeder Testautomatisierungsstrategie steht eine Frage, die gern übersprungen wird: Welches Problem willst du eigentlich lösen? Wer ein Tool kauft, weil es neu wirkt oder weil der Vertrieb überzeugend aufgetreten ist, sitzt am Ende mit Software da, die niemand im Team richtig bedienen kann, und ohne Plan, was sie leisten soll.

Péter Földházi arbeitet seit mehr als zehn Jahren in der Testautomatisierung und hat die ISTQB-Lehrpläne zu Test Automation Engineering und Test Automation Strategy mitgeschrieben. Er arbeitet toolunabhängig. Das Werkzeug kommt nach der Diagnose, nicht davor.

Als Erstes klärst du Umfang und Vorgehen. Wo fügt sich die Automatisierung ins größere Ökosystem ein, welche Art von Tests deckt sie ab, und in welchen Stufen läuft sie? Wenn diese Antworten stehen, ergibt sich die Toolentscheidung fast von selbst.

Einen allgemeinen Sieger unter den Tools gibt es nicht. Für ein Angular-Projekt kann Cypress passen. Für ein Team, das seit Jahren mit Selenium arbeitet, lohnt sich ein Wechsel zu Cypress oder Playwright selten, weil das vorhandene Wissen etwas wert ist. Wähl das Tool passend zum Kontext, nicht zum Trend.

Manuelles Testen ist nicht ausgestorben, und das sagt etwas

Vor mehr als zehn Jahren hieß es überall, manuelles Testen sei am Ende und bald werde alles automatisiert. Die Vorhersage ist nicht eingetreten.

Heute automatisieren mehr Unternehmen, darunter viele, die früher nur manuell getestet haben. Das ist echter Fortschritt. Aber Automatisierung ist keine Pflicht, die jeder der Branche schuldet. Sie ist eine Lösung, die ihren Platz nur verdient, wenn sie eine echte Herausforderung angeht.

Ohne klares Ziel oder mit zu großem Personaleinsatz kann Automatisierung mehr kosten, als sie zurückbringt. Die Frage, die du immer wieder stellen solltest: Welchen Wert bringt die Automatisierung im Verhältnis zu dem, was sie kostet?

Welche Ziele Testautomatisierung verfolgt

Testautomatisierung dient den Zielen, die du benennen kannst, und am klarsten benennst du sie, wenn du dir anschaust, wo die Fehler herkommen.

Ein reales Assessment bei einem Spielehersteller zeigt das. Ausgangspunkt waren nicht die Programmierpraktiken oder die vorhandene Automatisierung, sondern das Fehlerbild insgesamt. In acht Wochen kamen fast 5.000 Fehler zusammen, und nur rund 30 Prozent davon konnte das Unternehmen beheben.

Die Folgen sah man in der Lieferung. Alle paar Monate mussten zwei oder drei Sprints nur für Fehlerbehebung herhalten, und die Velocity fiel in dieser Zeit auf null.

Genau so ein Problem kann Automatisierung angehen. Mit besseren QS-Praktiken und einer Automatisierung, die Probleme früher im Lebenszyklus findet, könnte die Behebungsquote Richtung 50 Prozent steigen und die Zahl der gemeldeten Fehler von 5.000 auf 2.000 sinken, weil die Probleme früher auffallen. Der Nutzen ist konkret, nicht abstrakt.

Die Testpyramide macht den Ist-Zustand für alle sichtbar

Bevor du eine Strategie baust, mach ein Assessment und trag den Ist-Zustand in die Testautomatisierungspyramide ein. So siehst du, welche Testarten es gibt und wie viel auf jeder Stufe automatisiert ist.

Die Pyramide funktioniert, weil man zum Lesen kein technisches Wissen braucht. Jemand aus der Geschäftsführung, der das Budget verantwortet, aber nicht weiß, was ein API-Contract ist, versteht das Bild trotzdem: starker Fokus auf der UI-Ebene, Fehler werden immer noch spät gefunden, das Geld für Tests fließt spät.

Mit diesem Bild ist das Argument für Shift-Left schnell gemacht. Du zeigst, wo Tests früher ansetzen könnten, und skizzierst, wo das Team in sechs Monaten realistisch stehen kann. Diese Darstellung macht aus einem abstrakten Argument eine Entscheidung.

Die ideale Pyramidenform ist dabei meist gar nicht das Ziel. Das praktische Ziel ist das, was das Team in sechs Monaten schaffen kann, keine Lehrbuchsilhouette.

Von der Testpyramide zur Testautomatisierungsstrategie

Die Lücke zwischen Ist- und Soll-Zustand auf der Pyramide ist dein Arbeitsumfang. Dieses Delta definiert die Strategie.

Angenommen, das Delta zeigt: mehr funktionale API-Tests und die Einführung von Contract Testing. Dann stehen diese beiden Testarten im Mittelpunkt der Strategie, und ihre Automatisierung wird zum Plan.

Ab hier werden die Fragen konkret. Habt ihr schon API-Tests? Sind sie schon automatisiert? Musst du überhaupt ein Framework bauen, oder kannst du ein gut gebautes übernehmen und dir wochenlange Bauarbeit sparen?

Schreib den Plan auf und prüf ihn dann mit einem Proof of Concept. Eine Phase zur Toolevaluierung zeigt dir, ob ein Tool liefert, was du brauchst, bevor du dich für alles Weitere darauf festlegst.

Außerdem bewertest du die bestehenden Testfälle neu. Wenn viele API-Tests dazukommen, brauchst du manche UI-Tests vielleicht nicht mehr. Auch diese Abwägungen steuert das Delta.

Dieselbe Funktion auf zwei Ebenen ist kein doppelter Test

Eine Funktion auf Unit-Ebene und noch einmal auf UI-Ebene zu testen ist keine Redundanz, denn die beiden Ebenen prüfen unterschiedliche Dinge.

Beim Unit-Test geht es um die Qualität des Codes. Beim UI-Test geht es darum, ob von außen betrachtet alles wie gedacht funktioniert, wenn alles integriert ist.

Nutzer bewegen sich nicht durch den Code. Sie bewegen sich durch User Journeys. Tests auf UI-Ebene folgen diesen Journeys, und das ist eine andere Art von Nutzen als das isolierte Prüfen einer Unit.

Deshalb arbeitest du über die Ebenen hinweg mit Entwicklern und anderen Testern zusammen. Du musst wissen, was es auf jeder Ebene schon gibt, und du musst wissen, dass die Überdeckung auf einer Ebene das Anliegen einer anderen nicht automatisch mit abdeckt.

GTAA, TAA, Testautomatisierungslösung und TAF: die vier ISTQB-Ebenen

Die ISTQB-Lehrpläne beschreiben vier Ebenen, die in der Praxis oft für Verwirrung sorgen. Die Leute haben ihr Selenium oder ihr Cypress und fragen sich, was der Rest überhaupt soll. Die Ebenen gehen vom Allgemeinen zum Konkreten.

Die GTAA, die generische Testautomatisierungsarchitektur, beschreibt, was jedes Framework grundsätzlich braucht, um zu funktionieren und sich in eine Lösung einzufügen. Sie ist kein konkreter Entwurf, sondern eine Liste der allgemeinen Fähigkeiten, die eine Architektur haben sollte.

Die TAA, die Testautomatisierungsarchitektur, ist ein konkreter Entwurf für einen bestimmten Kontext. Deine TAA sieht anders aus als die von jemand anderem, weil du an einem anderen Projekt arbeitest, und ein Unternehmen kann mehrere TAAs gleichzeitig haben.

Die Testautomatisierungslösung ist die Umsetzung der TAA, die TAA ist der Bauplan. Die Lösung ist breiter als das Framework. Dazu gehört auch die Einbindung in Pipelines und Managementsysteme und zunehmend der Einsatz von MCP, um KI-Agenten in den Editor zu holen, die Tests mit passenden Daten erzeugen.

Das Framework, das TAF, sitzt als kleinerer Teil in der Lösung. Es hat drei Schichten: die Testskripte, die Business-Logik-Schicht und die Codebibliotheken.

Wo KI die Testautomatisierung wirklich verändert

Die entscheidende Grenze verläuft zwischen einem Tool, das KI-Fähigkeiten erwähnt, und einem Tool, das mit Agenten echten Nutzen bringt. Ein Etikett kostet nichts, die agentische Arbeit macht den Unterschied.

Prompting hat sich vom einfachen Chat zu Agenten weiterentwickelt. Ein Agent kann Aufgaben übernehmen, die viel Zeit fressen oder wenig Freude machen, und sie für dich erzeugen. Dann bleibt mehr Zeit für die Arbeit, die dich wirklich interessiert. Diese Verschiebung läuft schon und dürfte weiter zunehmen.

MCP ist die andere praktische Veränderung. Unternehmensdaten in die KI zu bringen ging auch vorher schon, über RAG. MCP macht das aber für mehr Teams zugänglich, und dass es direkt in der Entwicklungsumgebung passiert, ist ein echter Vorteil. Du bleibst in deinem Editor, etwa in Cursor oder Windsurf, und lässt die Agenten dort generieren, ohne zusätzliche Tabs zu öffnen.

Übernimmt KI den Aufbau der Automatisierung?

Nicht vollständig, zumindest noch nicht. Was du mit einem KI-Modell erzeugst, musst du weiterhin nacharbeiten.

Daraus folgen zwei Dinge. Erstens musst du lernen, deine Agenten besser zu konfigurieren und ihnen die richtigen Daten zu geben, und sicherstellen, dass sie diese Daten auch wirklich nutzen. Zweitens bleibt der Human in the Loop wichtig.

Was sich verschieben kann, ist, wohin die menschliche Aufmerksamkeit geht. Wenn ein Agent die Testfälle erzeugt, die sonst ein Tester abgedeckt hätte, kann der Entwickler die Testautomatisierung übernehmen. Der Schwerpunkt wandert Richtung Programmierung. Wie sich das genau entwickelt, wird man vielleicht in einem halben bis ganzen Jahr klarer sehen.

Eine Haltung hilft dabei, sie stammt von einem Universitätsprofessor: Bereite dich nicht nur auf den aktuellen Trend und die aktuellen Best Practices vor, sondern versuch herauszufinden, was als Nächstes kommt.

“Wir sollten uns nicht auf den aktuellen Trend und die aktuellen Best Practices vorbereiten. Wir sollten versuchen herauszufinden, was als Nächstes kommt.”

(Péter Földházi)

So startet ein Team, das bisher nur manuell testet

Fang bei den Leuten an, nicht beim Tool. Die erste Frage ist, ob jemand im Team schon Erfahrung mit Testautomatisierung hat.

Wenn nicht, kann ein Entwickler mit Programmiererfahrung anfangen, aber die Lernkurve ist real und muss als Zeit eingeplant werden. Die Alternative ist, einen Testautomatisierungsentwickler oder einen externen Dienstleister für den Anschub dazuzuholen.

Wer diesen Schritt überspringt, scheitert meist oder zahlt viel zu viel, weil die nötige Erfahrung fehlt, die den Weg weist. Kümmer dich also zuerst um die richtige Besetzung.

Danach kommst du zu der Frage zurück, die alles andere bestimmt: Welche Herausforderungen willst du angehen, und was bringt es dir, sie zu lösen? Strategie und Architektur kommen vor dem Tool, und das Problem kommt vor allem anderen.

Häufig gestellte Fragen

Gibt es ein einziges bestes Tool für die Testautomatisierung?

Nein. Es gibt keinen allgemeinen Sieger unter den Automatisierungstools, sondern nur eine passende Lösung für den jeweiligen Kontext. Für ein Angular-Projekt könnte Cypress gut funktionieren. Ein Team, das seit Jahren Selenium nutzt, profitiert in der Regel kaum von einem Wechsel zu Cypress oder Playwright, da das vorhandene Wissen einen hohen Wert hat. Die Wahl des Tools richtet sich nach dem Testumfang und dem Ansatz, nicht umgekehrt.

Hat die Testautomatisierung das manuelle Testen überflüssig gemacht?

Nein. Die Vorhersage, dass manuelles Testen verschwinden und alles automatisiert werden würde, hat sich nicht bewahrheitet. Was sich geändert hat, ist die Verbreitung: Immer mehr Unternehmen automatisieren mittlerweile, darunter viele, die früher ausschließlich manuell getestet haben. Automatisierung ist nichts, was jedes Team der Branche schuldig ist. Sie verdient ihren Platz, wenn sie eine echte Herausforderung löst, und ihre Kosten müssen gegen den Nutzen abgewogen werden, den sie bringt.

Wie kannst du den Business Case für Testautomatisierung konkret machen?

Schau dir das Fehlerbild an, statt auf Programmierpraktiken oder vorhandene Skripte. Bei einer Bestandsaufnahme in einem Gaming-Unternehmen wurden innerhalb von acht Wochen fast 5.000 Fehlerzustände gefunden, von denen nur etwa 30 Prozent behoben wurden. Alle paar Monate wurden zwei oder drei Sprints allein für die Fehlerbehebung aufgewendet, wodurch die Velocity auf null sank. Eine frühzeitigere Erkennung könnte die Behebungsquote auf 50 Prozent steigern und die Zahl der gemeldeten Fehlerzustände auf rund 2.000 senken.

Warum ist die Testpyramide nützlich, wenn man mit Budgetverantwortlichen spricht?

Sie vermittelt Informationen auch ohne technische Fachkenntnisse. Ein Stakeholder, der das Budget kontrolliert, aber nicht weiß, was ein API-Vertrag ist, kann trotzdem ein Bild verstehen, das umfangreiche Tests auf UI-Ebene, spät entdeckte Fehlerzustände und verspätete Ausgaben zeigt. Das macht es einfach, für „Shift-Left“-Tests zu argumentieren, besonders wenn das dargestellte Ziel das ist, was das Team realistisch in sechs Monaten erreichen kann, statt eines Modells aus dem Lehrbuch.

Macht eine hohe Unit-Test-Überdeckung UI-Tests überflüssig?

Nein, denn die beiden Ebenen beantworten unterschiedliche Fragen. Unit-Tests befassen sich mit der Qualität des Codes. UI-Tests prüfen, ob nach der Integration von außen betrachtet alles wie vorgesehen funktioniert. Nutzer bewegen sich nie durch den Code, sondern durch User Journeys, und UI-Tests folgen diesen Journeys. Eine Überdeckung auf einer Ebene deckt nicht automatisch die Anforderungen einer anderen ab.

Sollte ein Team ein eigenes Testautomatisierungsframework entwickeln oder ein bestehendes übernehmen?

Das hängt von der Lücke zwischen dem aktuellen und dem Zielzustand ab, die den Arbeitsumfang definiert. Wenn diese Lücke funktionale API-Tests und Contract Testing erfordert, lauten die nächsten Fragen: Gibt es bereits API-Tests? Sind diese bereits automatisiert? Und lässt sich ein bereits gut ausgebautes Framework übernehmen, anstatt Wochen mit der Entwicklung zu verbringen? Ein Proof-of-Concept und eine Testphase zur Tool-Bewertung prüfen den Plan, bevor man sich festlegt.

Was ist der Unterschied zwischen einem Testautomatisierungsframework und einer Testautomatisierungslösung?

Das Framework ist als kleinerer Teil in der Lösung enthalten. Es besteht aus drei Schichten: den Testskripten, der Geschäftslogik-Schicht und den Code-Bibliotheken. Die Lösung ist die Umsetzung des Architekturentwurfs und ist umfassender: Sie umfasst auch die Integration in Pipelines und in Managementsysteme sowie zunehmend den Einsatz von MCP, um KI-Agenten in den Editor einzubinden.

Können KI-Agenten den Aufbau der Testautomatisierung übernehmen?

Nicht vollständig. Alles, was von einem Modell generiert wird, muss noch angepasst werden, sodass der Mensch weiterhin in der Schleife bleibt (Human in the Loop). Ein Teil der Arbeit besteht nun darin, Agenten zu konfigurieren, sie mit den richtigen Daten zu versorgen und sicherzustellen, dass diese Daten auch tatsächlich verwendet werden. Was sich jedoch ändern könnte, ist, worauf sich die Aufmerksamkeit des Menschen richtet: Wenn Agenten die Testfälle generieren, können Entwickler sich auf die Automatisierung konzentrieren und den Schwerpunkt auf das Programmieren verlagern.