Jede Teststufe spielt in der Softwareentwicklung eine bestimmte Rolle und beantwortet eine eigene Frage:
Unit-Tests - „Hat sich eine Funktion geändert, die unverändert bleiben sollte?“ Sie testen die kleinsten isolierten Codeabschnitte (einzelne Funktionen oder Methoden) unabhängig vom Rest des Systems. (Eine ausführliche Analyse der Unit-Tests finden Sie in einem separaten Blogbeitrag.)
Integrationstests - „Arbeiten die Komponenten nach einer Änderung noch korrekt zusammen?“ Sie testen echte Verbindungen zwischen Modulen (z. B. Datenbank + Service-Schicht + API) statt nur isolierter Funktionen. Sie decken Szenarien auf, in denen einzelne Teile für sich bestehen, in Kombination aber scheitern.
E2E-Tests (End-to-End) - „Funktioniert das System so, wie ein echter Benutzer es erleben würde?“ Sie simulieren vollständige Benutzerabläufe (Login → Aktion → Ergebnis) über die tatsächliche UI oder API. Sie fangen Regressionen ab, die weder Unit- noch Integrationstests erkennen können, weil solche Probleme erst in einem echten Ablauf zutage treten.
(Es gibt natürlich weitere Testarten - etwa *Smoke-Tests**, Lasttests oder Sicherheitstests -, die den Rahmen dieses Artikels sprengen.)*
Allen automatisierten Teststufen ist ein gemeinsames Ziel eigen: zu prüfen, dass Funktionalität außerhalb des Umfangs des gerade bearbeiteten Tasks nicht kaputtgegangen ist. Ein Task kann gemäß Spezifikation perfekt erledigt sein und trotzdem als unbeabsichtigten Nebeneffekt etwas anderes zerstören. Ohne eine Testschicht, die über die konkrete Änderung hinausreicht, würde es niemand bemerken, bis ein Benutzer das Problem in der Produktion meldet.
Die unverzichtbare Rolle manueller Tests
Trotz fortgeschrittener Automatisierung und KI-Integration behalten manuelle Tests ihre unverzichtbare und primäre Rolle. Ein menschlicher Tester bringt echtes Urteilsvermögen, Intuition und die Fähigkeit mit, feine Nuancen oder unerwartetes UI-Verhalten zu erkennen, die automatisierten Skripten leicht entgehen. Die manuelle Verifikation war, ist und bleibt das, was dem Entwicklungsteam 100 % Sicherheit gibt, dass die Anwendung bereit für echte Benutzer ist.
KI-gestützte Entwicklung und der Ausgleich der „Blindheit“
Im Zeitalter der KI-gestützten Entwicklung ist eine automatisierte Testschicht noch wichtiger. Ein KI-Agent kann nicht das gesamte System auf einmal erfassen, wodurch Nebeneffekte wahrscheinlicher sind als bei einem menschlichen Entwickler, der den vollen Kontext und die Historie früherer Entscheidungen im Kopf hat. Tests dienen als Mechanismus, diese Systemblindheit systematisch auszugleichen, bevor der Code die abschließende menschliche Freigabe erreicht.
Praktische Auswirkungen: die Herausforderungen von E2E-Tests mit KI
Das Erstellen von E2E-Tests ist für die KI besonders komplex. Es geht nicht nur darum, das Testskript selbst zu schreiben, sondern vor allem darum, geeignete Testdaten vorzubereiten, damit die Software sie verwenden kann (oft nur für einen kleinen Teil des Tests). Die Vorbereitung dieser Daten ist sehr anspruchsvoll.
Nehmen wir eine scheinbar simple Aktion: auf eine Dropdown-Liste klicken und einen Parameter auswählen (z. B. den Dokumenttyp Rechnung). Wenn der Test fehlschlägt oder nicht abgeschlossen wird, ist es entscheidend, die genaue Ursache zu diagnostizieren. Es können verschiedene Situationen eingetreten sein:
- Die KI hat sich verirrt und konnte das Dropdown-Element in der UI nicht finden (obwohl es vorhanden ist).
- Der Test ist auf dem Weg dorthin auf einen früheren Fehler gestoßen und konnte sich nicht davon erholen.
- Das Dropdown existiert, enthält aber nicht die erwarteten Daten zur Auswahl.
- Die KI hat auf JavaScript zurückgegriffen (ein unsichtbarer Workaround) und den Wert erfolgreich programmatisch gesetzt, während er für einen echten Benutzer unsichtbar bleibt.
Rund um ein einziges Dropdown können zahlreiche Probleme auftreten. Entscheidend ist, ob die KI (oder das Bewertungssystem) einen echten Fehler von einem Folgefehler unterscheiden kann, der von etwas anderem verursacht wurde. Dass Daten erfolgreich gespeichert werden, garantiert allein noch nicht, dass alles richtig funktioniert.
Verhaltensorientierter Ansatz und Testabdeckung
Deshalb sollten sich Tests immer auf den verhaltensbezogenen Aspekt des Systems konzentrieren und testen, was wir tatsächlich erwarten:
Happy Path (~90 % der Fälle): Der Schwerpunkt liegt auf dem, was Benutzer in der überwiegenden Mehrheit der Fälle tun werden.
Kritische Grenzfälle: Grenzbedingungen, die nicht häufig auftreten, aber für die Integrität des Systems entscheidend sind.
Andere, weniger wahrscheinliche Kombinationen werden nicht vorab getestet. Treten sie in der Produktion auf, werden sie laufend behoben oder durch Software-Beschränkungen und Validierungen verhindert (z. B. durch Deaktivieren der Navigation, bis die Eingaben gültig sind).
E2E-Tests in AITM
In AITM sind E2E-Tests eine ausdrückliche und verpflichtende Pipeline-Phase für Tasks, die die UI betreffen (bestimmt durch Task-Typ/Intent). Sie sind kein optionales Add-on, das man bei knappen Terminen überspringt - eine Pipeline kann ohne sie nicht als abgeschlossen markiert werden.
Fehlt ein E2E-Test oder ist die Umgebung nicht verfügbar, schlägt der Build standardmäßig fehl (mit seltenen Ausnahmen, in denen ein fehlgeschlagener E2E-Test passieren darf). Außerdem erfasst jede E2E-Ausführung Screenshots, die in den Task-Ergebnissen sichtbar sind.
Wie E2E derzeit funktioniert:
- Vor der Ausführung der Tests ist garantiert, dass der Build erfolgreich ist und in einem eigenen isolierten Worktree läuft.
- Der Datenbankzustand wird mit spezifischen Testdaten neben den Standarddatensätzen vorbereitet.
- Die Tests konzentrieren sich strikt auf den Happy Path (sie decken nicht alle möglichen Szenarien ab).
Künftige Roadmap für E2E:
- Flow Maps - Das System erstellt eine Pfadkarte zu bestimmten Elementen, die direkt mit der Geschäftslogik verknüpft sind (bereits in AITM integriert).
- Autonome Navigation - Tests lesen die Live-Pfadkarte und wissen genau, wo sie klicken, tippen und prüfen müssen (wird derzeit getestet).
- Zustandsvergleich (Visual Diffing) - Jeder Schritt wird mit Screenshots vor und nach Codeänderungen aufgezeichnet, um zu bestätigen, dass erwartete Elemente und Daten den Erwartungen in DB oder UI entsprechen.
- Verifikation der Geschäftslogik - Automatisierte Prüfung erwarteter Ausgabedaten (z. B. verifizierte Rechnungssummen - derzeit in Entwicklung).
- Nächtliche Integrationsläufe - End-to-End-Integrationstests werden automatisch aus Schrittzuständen und Softwareanforderungen generiert und laufen über Nacht. Fehlschläge erzeugen Tasks oder fordern eine menschliche Verifikation an (da die KI Fehler machen kann und eine menschliche Freigabe braucht).
- Erweiterte Szenarien - Künftige Releases werden das Einspeisen ungültiger Parameter, Nebenläufigkeitstests mit mehreren Instanzen und Simulationen von Grenzfällen enthalten.
Zusammenfassung der E2E-Grundprinzipien
Das Wesen wirksamer E2E-Tests beruht auf der Verwaltung von Karten und Beziehungen zwischen Dateneinheiten. Bei 90 % der Software läuft es auf den üblichen Lebenszyklus hinaus:
#AITM #Data Input Validation #E2E #Integration test #AI TESTING