Typische Fehler in der Testautomatisierung

In den bisherigen Beiträgen dieser Serie ging es um Teststrategien im Sprint-Zyklus, um Testdaten und Testumgebungen als Grundlage jeder Automatisierung sowie um den Einsatz von KI im Software-Testing. Dieser Beitrag schließt daran an, allerdings unabhängig von KI: Testautomatisierung scheitert in der Praxis selten an der Wahl des falschen Tools. Häufiger sind es wiederkehrende Fehler, die sich über den gesamten Lebenszyklus einer Testsuite ziehen, von der ersten Konfiguration über den Code selbst bis hin zur Frage, wie mit Testergebnissen umgegangen wird und wie neue Testfälle in ein Release gelangen.

Dieser Beitrag beschreibt die häufigsten dieser Fehler entlang von fünf Kategorien: Infrastruktur, Code, Ergebnisprüfung, Release-Prozess und laufender Betrieb.

Fehler in der Infrastruktur

Infrastrukturfehler betreffen alles, was eine Testsuite braucht, um überhaupt zuverlässig zu laufen: Konfiguration, Testarchitektur, Wissen im Team und Einbindung in die CI/CD-Pipeline.

Komplexe und unflexible Konfiguration

Testautomatisierungs-Frameworks werden häufig mit einer Vielzahl an Konfigurationsoptionen, Umgebungsvariablen und Abhängigkeiten aufgesetzt. Problematisch wird es, wenn Endpunkte, Zugangsdaten oder Selektoren fest für eine bestimmte Umgebung hinterlegt werden: Dann schlagen die Tests in jeder anderen Umgebung fehl, egal ob lokal, in einer neuen Staging-Instanz oder in der CI-Pipeline, obwohl die eigentliche Funktionalität korrekt ist. Konfigurationswerte sollten deshalb konsequent ausgelagert statt hartkodiert im Testcode hinterlegt werden.

Fehlende Testpyramide

Die Testsuite besteht nahezu ausschließlich aus End-to-End-Tests statt aus einer Mischung von Unit-, Integrations- und E2E-Tests. Das macht die Suite langsam, fehleranfällig für Umgebungsprobleme und erschwert die Fehlersuche, da ein einzelner Fehler in der Anwendung häufig mehrere E2E-Tests gleichzeitig zum Scheitern bringt.

Wissen liegt bei einer einzelnen Person

Nicht nur die Konfiguration, sondern die gesamte Testautomatisierung (Aufbau, Struktur, Zusammenhänge) wird häufig nur von einer einzigen Person im Team wirklich verstanden. Fällt diese Person aus oder verlässt sie das Projekt, ist das Team kaum in der Lage, die Suite weiterzuentwickeln oder überhaupt lauffähig zu halten. Das Wissen muss daher aktiv verteilt werden, etwa über Dokumentation, Pairing oder Reviews, statt nur in einem Kopf zu existieren.

Keine oder unzureichende CI/CD-Integration

Tests laufen nur lokal auf einzelnen Rechnern statt automatisiert bei jedem Commit oder Merge. Dadurch hängt die Ausführung vom Zufall bzw. von der Disziplin Einzelner ab, und Fehler werden oft erst spät im Prozess sichtbar, wenn überhaupt.

Fehler beim Coden

Auf Code-Ebene entscheidet sich, wie wartbar und stabil eine Testsuite über die Zeit bleibt, unabhängig davon, wie gut Infrastruktur und Konfiguration aufgesetzt sind.

Kein wartbarer Code

Testcode wird oft als Nebensache behandelt und nicht mit denselben Qualitätsansprüchen geschrieben wie Produktivcode: unklare Struktur, fehlende Namenskonventionen, keine Kommentare an kritischen Stellen. Jede kleine Änderung an der Anwendung führt dann zu überproportional hohem Wartungsaufwand in der Testsuite.

Keine Modularisierung

Ohne wiederverwendbare Bausteine (etwa Page-Objects, API-Clients oder Hilfsfunktionen) wird derselbe Ablauf (Login, Navigation, Datenanlage) in jedem Test erneut geschrieben. Ändert sich ein Element oder ein Ablauf in der Anwendung, muss diese Änderung an vielen Stellen im Testcode nachgezogen werden statt an einer einzigen. Das führt zu unnötigen Fehlern und zusätzlichem Wartungsaufwand.

Sprachmix („Denglish“)

Uneinheitliche Sprache in Variablennamen, Methodennamen, Kommentaren und Testberichten erschwert das Lesen und Verstehen von Testcode zusätzlich, besonders für neue Teammitglieder oder in der Zusammenarbeit mit internationalen Kolleg*innen. Eine einheitliche Sprachkonvention über das gesamte Projekt reduziert Reibungsverluste.

Hartkodierte Wartezeiten

Feste Wartezeiten (z. B. sleep oder Thread.sleep) statt expliziter, zustandsbasierter Waits (die nicht starr eine festgelegte Zeit abwarten, sondern nur so lange, bis ein bestimmter Zustand eintritt, etwa bis ein Element sichtbar oder klickbar ist) sind eine der Hauptursachen für unnötig lange Laufzeiten und führen zu Flakiness: Ist die Wartezeit zu kurz, schlägt der Test fälschlich fehl; ist sie zu lang, verlängert sich die Gesamtlaufzeit der Suite unnötig.

Fehlende Testdaten-Isolation

Tests greifen auf geteilte, sich verändernde Daten zu statt auf reproduzierbare, pro Lauf isoliert erzeugte Testdaten. Laufen mehrere Tests parallel oder in unterschiedlicher Reihenfolge, beeinflussen sie sich gegenseitig. Das ist ein klassischer Grund für nicht reproduzierbare Fehlschläge.

Fehler bei der Ergebnisprüfung

Assertions sind die eigentlichen Prüfpunkte in einem Test: die Stellen im Testcode, an denen tatsächlich kontrolliert wird, ob ein Wert, ein Zustand oder ein angezeigter Inhalt dem erwarteten Ergebnis entspricht. Fehlen sie oder sind sie falsch gesetzt, verliert ein Test seinen eigentlichen Zweck, selbst wenn er formal durchläuft.

Falsche Assertion

Ein Test prüft beispielsweise nur, ob ein Element sichtbar ist, statt den tatsächlichen Inhalt oder Zustand zu verifizieren. Ein solcher Test wird grün, selbst wenn der angezeigte Wert fachlich falsch ist. Er testet im Kern etwas anderes, als er vorgibt zu testen.

Fehlende Assertion

Ein Testschritt wird ausgeführt, das erwartete Ergebnis aber nicht überprüft. Der Test läuft durch, ohne dass tatsächlich verifiziert wurde, ob sich die Anwendung korrekt verhalten hat. Im schlimmsten Fall bleibt ein Fehler unentdeckt, obwohl formal ein Test dafür existiert.

Zu viele Assertions in einem Test

Ein einzelner Test prüft mehrere, fachlich unabhängige Aspekte gleichzeitig. Schlägt er fehl, ist zunächst unklar, welcher der geprüften Aspekte tatsächlich betroffen ist. Die Fehlersuche beginnt bei null, statt direkt auf das Problem hinzuweisen.

Auto-Retry-Mechanismen, die Instabilität verschleiern

Ein fehlgeschlagener Test wird automatisch so oft wiederholt, bis er zufällig grün wird, statt die Ursache für die Instabilität zu klären. Die Testsuite erscheint dadurch stabiler, als sie ist, und ein zugrunde liegendes Problem (etwa eine Race Condition) bleibt bestehen.

Fehler beim Releasen

Beim Releasen geht es darum, wie Änderungen an der Testautomatisierung selbst in ein Projekt einfließen und ob sie denselben Qualitätsansprüchen unterliegen wie der Produktivcode.

Kein Review

Testautomatisierungs-Code wird direkt committet, ohne dass jemand anderes ihn gegenliest. Dadurch bleiben dieselben Probleme wie beim Produktivcode unentdeckt: schlechte Lesbarkeit, Duplikate, fehlerhafte Logik oder unzureichende Assertions.

Kein Merge – gleich in Master/Main

Änderungen an der Testautomatisierung werden direkt im Hauptbranch vorgenommen, ohne Feature-Branch und Pull- bzw. Merge-Request. Damit entfällt nicht nur das Review, sondern auch die Möglichkeit, Änderungen vor der Integration automatisiert zu prüfen oder bei Bedarf sauber zurückzurollen.

Fehlgeschlagene Tests werden übersprungen oder deaktiviert

Statt die Ursache eines Fehlschlags zu klären, wird der betroffene Test markiert und von der Ausführung ausgeschlossen (z. B. @Skip, @Ignore). Damit sinkt die tatsächliche Testabdeckung schleichend, ohne dass dies im Reporting sichtbar wird.

Testautomatisierungs-Code nicht gemeinsam mit dem Produktivcode versioniert

Testcode und Produktivcode werden getrennt voneinander verwaltet oder getaggt. Bei einem Rollback oder beim Nachvollziehen einer bestimmten Version ist dann nicht klar, welcher Stand der Testautomatisierung tatsächlich zu welchem Stand der Anwendung passt.

Fehler im laufenden Betrieb und bei der Wartung

Auch nach dem erfolgreichen Aufbau bleibt eine Testsuite eine laufende Aufgabe: Ohne Pflege verliert sie mit der Zeit an Aussagekraft und Vertrauen im Team.

Flaky Tests werden ignoriert

Tests, die ohne erkennbaren Grund mal fehlschlagen und mal nicht, werden hingenommen statt behoben. Mit der Zeit verliert das Team das Vertrauen in die Suite und beginnt, auch echte Fehlschläge zu ignorieren. Der eigentliche Zweck der Automatisierung geht damit verloren.

Keine klare Verantwortlichkeit 

Es ist nicht eindeutig geregelt, wer für die Testsuite zuständig ist, wenn sie rot wird, veraltet oder wartungsbedürftig ist. Ohne benannte Verantwortlichkeit bleiben solche Probleme liegen, bis die Suite faktisch nicht mehr genutzt wird.

Kein Monitoring von Laufzeit und Flaky-Rate 

Wie lange die Suite läuft und wie oft Tests ohne echten Fehlerbezug fehlschlagen, wird nicht systematisch erfasst. Ein schleichender Verfall (etwa durch zunehmende Laufzeit oder steigende Flaky-Rate) bleibt dadurch lange unbemerkt, bis die Suite im Alltag kaum mehr brauchbar ist.

Fazit

Die meisten dieser Fehler entstehen nicht durch eine einzelne technische Fehlentscheidung, sondern dadurch, dass Testautomatisierung als einmaliges Projekt behandelt wird statt als kontinuierliche Aufgabe. Infrastruktur, Code, Ergebnisprüfung, Release-Prozess und laufender Betrieb hängen zusammen: Eine komplexe Konfiguration erschwert auch das Review, eine fehlende Assertion bleibt ohne Monitoring lange unbemerkt, und ein übersprungener Test verschiebt ein Problem nur in die Zukunft, statt es zu lösen.

Keiner dieser Fehler ist für sich genommen ungewöhnlich oder überraschend. Entscheidend ist, ob ein Team sie als Einzelfälle behandelt oder als wiederkehrendes Muster erkennt und systematisch dagegen vorgeht, etwa durch Code-Reviews für Testcode, durch Monitoring von Laufzeit und Flaky-Rate oder durch klare Verantwortlichkeiten für die Pflege der Suite.

Sie möchten wissen, wo in Ihrer eigenen Testautomatisierung die größten Risiken liegen: bei der Konfiguration, im Code, bei der Ergebnisprüfung oder im laufenden Betrieb? In einem unverbindlichen Austausch schauen wir uns das gemeinsam an.

Kontaktieren Sie uns unter: office@gruener-it.at