Bei der Testautomatisierungsstrategie geht es darum, das Problem zu definieren, das du lösen willst, bevor du ein Tool auswählst. Sie beginnt damit, den Ist- und den Soll-Zustand über alle Teststufen hinweg abzubilden, in der Regel in Form einer Testpyramide, die Unit-, API- und UI-Tests umfasst. Diese Lücke definiert den Umfang der Arbeit. Werkzeuge, Framework-Design und Automatisierungsarchitektur folgen erst, wenn das Problem klar ist.
Das Wichtigste in Kürze
- Die Auswahl der Werkzeuge ist erst dann sinnvoll, wenn das Team definiert hat, welches Problem mit der Testautomatisierung gelöst werden soll und welchen Nutzen sie bringen soll.
- Eine Testautomatisierungs-Pyramide, die den Ist-Zustand dem Soll-Zustand gegenüberstellt, gibt nicht-technischen Stakeholdern ein konkretes Bild davon, wohin Aufwand und Geld verlagert werden sollten.
- Das Testen derselben Funktionalität auf mehreren Pyramidenstufen ist nicht überflüssig: Unit-Tests bewerten die Code-Qualität, während UI-Tests überprüfen, ob die integrierten User Journeys wie vorgesehen funktionieren.
- Das Testautomatisierungsframework (Skripte, Geschäftslogikschicht, Codebibliotheken) ist nur ein Teil der Testautomatisierungslösung; die Pipelineintegration und externe Systemverbindungen gehören ebenso dazu.
- Ohne mindestens eine Person im Team, die bereits Erfahrung mit der Testautomatisierung hat, wird die Einführung entweder fehlgeschlagen sein oder viel mehr kosten als geplant.
Warum Testautomatisierung ein Problem braucht, bevor sie ein Werkzeug braucht
Die Testautomatisierung beginnt mit einer Frage, die oft übergangen wird: Welches Problem wird eigentlich gelöst? Wenn du ein Tool kaufst, weil es neu aussieht oder weil der Verkäufer überzeugend argumentiert hat, haben die Teams keine Ahnung, wie sie die Software nutzen können und keinen Plan, was sie eigentlich erreichen soll.
Péter Földházi, der seit mehr als zehn Jahren in der Testautomatisierung tätig ist und die ISTQB-Lehrpläne zur Testautomatisierungsentwicklung und -strategie mitverfasst hat, arbeitet tool-agnostisch. Das Werkzeug kommt nach der Diagnose, nicht davor.
Das erste, was du festlegen musst, sind Umfang und Ansatz. Wo ist die Testautomatisierung in das breitere Ökosystem integriert, welche Art von Testen deckt sie ab und in welchen Phasen wird sie eingesetzt? Sobald diese Fragen geklärt sind, ergibt sich die Entscheidung für ein Werkzeug fast von selbst.
Es gibt keinen allgemeinen Gewinner unter den Tools. Für ein Angular-Projekt könnte Cypress geeignet sein. Für ein Team, das seit Jahren mit Selenium arbeitet, ist ein Wechsel zu Cypress oder Playwright selten sinnvoll, denn das vorhandene Wissen ist wertvoll. Passe das Tool an den Kontext an, nicht an den Trend.
Manuelles Testen ist nicht gestorben, und das sagt dir etwas
Vor mehr als einem Jahrzehnt hieß es noch, dass das manuelle Testen am Ende sei und alles automatisiert werden würde. Diese Vorhersage hat sich nicht bewahrheitet.
Immer mehr Unternehmen setzen heute auf Testautomatisierung, darunter auch viele, die früher nur manuell getestet haben. Das ist ein echter Fortschritt. Aber die Automatisierung ist kein Standard, den jeder der Branche schuldet. Sie ist eine Lösung, die nur dann ihren Platz verdient, wenn sie eine echte Herausforderung löst.
Wenn sie ohne ein klares Ziel oder mit zu vielen Mitarbeitern durchgeführt wird, kann die Automatisierung mehr kosten als sie einbringt. Die Frage, die du dir immer wieder stellen musst, ist, welchen Wert die Automatisierung im Vergleich zu den Kosten bringt.
Welche Ziele verfolgt die Testautomatisierung eigentlich?
Die Testautomatisierung dient den Zielen, die du benennen kannst, und der klarste Weg, sie zu benennen, ist, sich anzusehen, woher Fehlerzustände kommen.
Betrachte eine reale Bewertung eines Spieleherstellers. Ausgangspunkt waren nicht die Codierungspraktiken oder die vorhandene Automatisierung, sondern der Fehlerzustand insgesamt. In einem Zeitraum von acht Wochen wurden fast 5.000 Fehlerzustände befundet, von denen nur etwa 30 Prozent behoben werden konnten.
Die Konsequenz war in der Lieferung sichtbar. Alle paar Monate mussten sie zwei oder drei Sprints allein für die Behebung von Fehlerzuständen aufwenden, wodurch die Geschwindigkeit in diesen Zeitfenstern auf null sank.
Das ist die Art von Problem, das die Automatisierung angehen kann. Mit besseren QS-Praktiken und einer Automatisierung, die Probleme früher im Lebenszyklus erkennt, könnte die Lösungsrate auf 50 Prozent steigen und die Anzahl der gemeldeten Fehlerzustände von 5.000 auf 2.000 sinken, weil Probleme früher auftauchen. Der Wert ist konkret, nicht abstrakt.
Die Testpyramide macht den aktuellen Stand für alle sichtbar
Bevor du eine Strategie entwickelst, solltest du eine Bewertung durchführen und den aktuellen Stand in der Testautomatisierungspyramide abbilden. Daraus geht hervor, welche Arten des Testens es gibt und wie viel Testautomatisierung auf jeder Ebene stattfindet.
Die Pyramide funktioniert, weil man sie nicht mit technischen Kenntnissen lesen muss. Ein C-Suite Stakeholder, der das Budget kontrolliert, aber nicht weiß, was ein API-Vertrag ist, kann trotzdem das Bild sehen: starker Fokus auf die UI-Ebene, Fehlerzustände werden immer noch spät befundet, Geld wird spät für das Testen ausgegeben.
Vor diesem Hintergrund wird das Argument für das Shift-Left-Testen leicht verständlich. Du kannst aufzeigen, wo das Testen früher stattfinden könnte, und du kannst skizzieren, wo das Team realistischerweise in sechs Monaten sein könnte. Diese visuelle Darstellung macht aus einem abstrakten Argument eine Entscheidung.
Die ideale Pyramidenform ist normalerweise nicht das eigentliche Ziel. Das praktische Ziel ist das, was das Team innerhalb von sechs Monaten erreichen kann, nicht eine Silhouette aus dem Lehrbuch.
Wie wird aus der Pyramide eine Strategie?
Die Lücke zwischen dem aktuellen Zustand und dem zukünftigen Zustand auf der Pyramide ist dein Arbeitsbereich. Dieses Delta definiert die Strategie.
Angenommen, das Delta weist auf mehr funktionale API-Tests und die Einführung von Vertragstests hin. Diese beiden Arten von Tests stehen im Mittelpunkt der Strategie, und ihre Automatisierung wird zum Plan.
Von da an werden die Fragen konkret. Gibt es bei euch bereits API-Tests? Sind sie bereits automatisiert? Musst du überhaupt ein Framework entwickeln oder kannst du ein bereits gut entwickeltes übernehmen, damit du nicht wochenlang mit der Entwicklung beschäftigt bist?
Schreibe den Plan auf und teste ihn dann mit einem Proof of Concept. Eine Tool-Evaluierungsphase zeigt dir, ob ein Tool das liefert, was du brauchst, bevor du dich für alles Weitere verpflichtest.
Außerdem bewertest du die bestehenden Testfälle neu. Wenn du viele API-Tests hinzufügst, brauchst du vielleicht einige der UI-Tests nicht mehr. Das Delta bestimmt auch diese Abwägungen.
Die gleiche Funktion auf zwei Ebenen ist kein doppeltes Testen
Das Testen einer Funktion auf der Unit-Ebene und noch einmal auf der UI-Ebene ist keine Redundanz, denn die beiden Ebenen testen auf unterschiedliche Dinge.
Beim Testen der Units geht es um die Qualität des Codes. Beim Testen der Benutzeroberfläche geht es darum, ob alles wie vorgesehen funktioniert, wenn alles integriert ist.
Die Nutzer bewegen sich nicht durch den Code. Sie bewegen sich durch User Journeys. Tests auf UI-Ebene folgen dieser Reise, was eine andere Art von Testen darstellt als das isolierte Prüfen einer Unit.
Deshalb arbeitest du mit Entwicklern und anderen Testern über die verschiedenen Ebenen hinweg zusammen. Du musst wissen, was auf jeder Ebene bereits vorhanden ist, und du musst wissen, dass die Überdeckung auf einer Ebene nicht automatisch auch die Belange einer anderen Ebene abdeckt.
Die vier ISTQB-Ebenen, einfach erklärt
In den ISTQB-Lehrplänen werden vier Ebenen beschrieben, die Praktiker/innen oft verwirren. Die Leute haben ihr Selenium oder ihr Cypress und fragen sich, was der Rest überhaupt bedeutet. Die Schichten gehen vom Allgemeinen zum Konkreten.
Die GTAA, die generische Testautomatisierungsarchitektur, beschreibt, was jedes Framework im Allgemeinen braucht, um zu funktionieren und sich in eine Lösung zu integrieren. Es handelt sich nicht um einen konkreten Entwurf. Sie listet die generischen Fähigkeiten auf, die eine Architektur haben sollte.
Die TAA, die Testautomatisierungsarchitektur, ist ein konkreter Entwurf für einen bestimmten Kontext. Deine TAA unterscheidet sich von der eines anderen, weil du an einem anderen Projekt arbeitest und ein einzelnes Unternehmen mehrere TAAs gleichzeitig haben kann.
| Layer | Was es ist |
|---|---|
| GTAA | Allgemeine Fähigkeiten, die ein Framework braucht, kein konkreter Entwurf |
| TAA | Ein konkreter Architekturentwurf für ein bestimmtes Projekt |
| Testautomatisierungslösung | Die Implementierung der TAA, einschließlich der Pipeline- und Werkzeugintegration |
| TAF (Framework) | Ein Teil der Lösung: Testskripte, Geschäftslogikschicht, Codebibliotheken |
Die Testautomatisierungslösung ist die Umsetzung der TAA, wobei die TAA als Blaupause dient. Die Lösung ist breiter angelegt als das Framework. Sie umfasst auch die Integration in Pipelines und in Managementsysteme sowie zunehmend den Einsatz von MCP, um KI-Agenten in einen Editor zur Erstellung von Tests mit relevanten Daten einzubinden.
Das Framework, die TAF, ist ein kleinerer Teil der Lösung. Es besteht aus drei Schichten: den Testskripten, der Geschäftslogikschicht und den Codebibliotheken.
Wo KI die Testautomatisierung wirklich verändert
Die Grenze, auf die es ankommt, liegt zwischen einem Werkzeug, das KI-Fähigkeiten erwähnt, und einem Werkzeug, das einen echten agentenbasierten Wert liefert. Die Bezeichnung ist billig; die agenturische Arbeit ist das Unterscheidungsmerkmal.
Das Prompting hat sich vom einfachen Chat hin zu Agenten entwickelt. Ein Agent kann zeitaufwändige oder undankbare Aufgaben übernehmen und sie für dich erledigen, damit du dich auf die Arbeit konzentrieren kannst, die dir mehr Spaß macht. Dieser Wandel ist bereits im Gange und wird sich noch verstärken.
MCP ist die andere praktische Veränderung. Die Möglichkeit, Unternehmensdaten in die KI einzubringen, gab es schon vorher, durch RAG, aber MCP macht sie mehr Teams zugänglich, und es ist wichtig, sie in der Entwicklungsumgebung zu haben. Du kannst in deinem Editor bleiben, in einem Tool wie Cursor oder Windsurf, und trotzdem von den Agenten generiert werden, ohne zusätzliche Tabs zu öffnen.
Wird KI die Erstellung der Automatisierung übernehmen?
Nicht vollständig, zumindest noch nicht. Wenn du etwas mit einem KI-Modell generierst, musst du immer noch Änderungen daran vornehmen.
Das hat zwei Konsequenzen, die man im Auge behalten sollte. Erstens musst du lernen, deine Agenten besser zu konfigurieren und sie mit den richtigen Daten zu füttern, während du gleichzeitig sicherstellst, dass die relevanten Daten auch tatsächlich genutzt werden. Zweitens bleibt der Mensch in der Schleife wichtig.
Was sich ändern kann, ist, wo die menschliche Aufmerksamkeit landet. Wenn ein Agent die Testfälle erstellt, die ein Tester abdecken würde, kann der Entwickler die Testautomatisierung übernehmen. Der Schwerpunkt verlagert sich auf die Codierung. Wie sich das auswirkt, wird sich vielleicht erst in einem halben bis ganzen Jahr zeigen.
Dabei hilft eine Denkweise, die von einem Universitätsprofessor stammt: Bereite dich nicht nur auf den aktuellen Trend und die aktuellen Best Practices vor, sondern versuche herauszufinden, was das nächste Ding sein wird.
Wir sollten uns nicht darauf vorbereiten, was der aktuelle Trend ist und was die besten Praktiken sind. Wir sollten versuchen, herauszufinden, was das nächste Ding sein wird.
- Péter Földházi
Wie sollte ein Team, das nur manuell arbeitet, mit der Automatisierung beginnen?
Beginne mit der Personalausstattung, nicht mit den Werkzeugen. Die erste Frage ist, ob jemand im Team bereits über einschlägige Erfahrungen in der Testautomatisierung verfügt.
Wenn das nicht der Fall ist, kann ein Entwickler mit Programmierkenntnissen den Anfang machen, aber die Lernkurve ist real und muss als Zeit eingeplant werden. Die Alternative ist, einen Testautomatisierungsentwickler oder einen externen Dienstleister hinzuzuziehen, um die Arbeit in Gang zu bringen.
Wenn du diesen Schritt auslässt, wird das Projekt fehlgeschlagen oder zu teuer, weil du nicht über das nötige Fachwissen verfügst. Kümmere dich zuerst um die richtige Personalausstattung.
Dann kehrst du zu der Frage zurück, die alles andere bestimmt: Welche Herausforderungen willst du angehen und welchen Nutzen bringt es, sie zu bewältigen? Strategie und Architektur kommen vor dem Werkzeug, und das Problem kommt vor allem anderen.
