Wartungs-Tetris: Warum eure QA Tests repariert, die gar nicht kaputt sind

Eure QA-Engineers reparieren Tests, die gar nicht kaputt sind. Der Grund ist meist nicht die Software, sondern ein Button, der sich um ein paar Pixel verschoben hat. Ein neues Label, ein umbenannter Selektor oder ein leicht anderes Layout reichen, und die Pipeline leuchtet rot. Das fühlt sich nach Qualitätssicherung an, ist aber vor allem eins: Wartungs-Tetris.

Und es kostet euer Team jede Woche Stunden, in denen niemand echten Wert schafft.

Wenn drei Pixel die Pipeline stoppen

Stellt euch einen typischen Montagmorgen vor. Über Nacht ist ein Test-Run durchgelaufen, ein Dutzend UI-Tests sind fehlgeschlagen. Panik kommt keine auf, das ist Routine. Jemand aus dem QA-Team klickt sich durch die Fehlermeldungen und stellt fest, dass die Anwendung einwandfrei funktioniert. Gestern hat ein Entwickler einen Button-Text von „Speichern" auf „Jetzt speichern" geändert, oder ein Framework-Update hat eine CSS-Klasse umbenannt. Der Test sucht aber noch nach dem alten Element und findet es nicht.

✗ ElementNotFound
  Selector changed: .btn-primary

Der Fehler liegt nicht in der Software, sondern im Test. Genauer gesagt in der Annahme, dass sich die Oberfläche nie ändert. Bei moderner Software, die sich ständig weiterentwickelt, ist diese Annahme schlicht falsch.

Warum klassische UI-Tests so zerbrechlich sind

Klassische UI-Automatisierung hängt an festen Selektoren: CSS-Klassen, IDs, XPath-Ausdrücken oder exakten Textbausteinen. Der Test klickt auf #submit-btn und prüft, ob danach .btn-primary erscheint. Solange sich an diesen technischen Ankern nichts ändert, läuft alles. Das Problem ist nur, dass sich genau diese Anker ständig ändern. Ein Refactoring, ein Design-Update oder ein neues Komponenten-Framework genügt, und die sorgfältig gepflegten Selektoren zeigen ins Leere.

Sobald sich die Oberfläche ändert, schlägt der Test fehl und jemand zieht den Selektor von Hand nach. Bei Hunderten von Testfällen und einem Team, das mehrmals pro Woche deployt, wird daraus ein Dauerzustand. Die Tests werden nicht stabiler, je mehr davon existieren, sondern brüchiger.

Besonders tückisch ist, dass diese Fehlalarme das Vertrauen ins Test-Set untergraben. Wenn die Pipeline ohnehin ständig rot ist, schaut irgendwann niemand mehr genau hin. Und dann rutscht der eine echte Bug mit durch, der zwischen zwanzig falschen versteckt war.

Wartungs-Tetris: der versteckte Kostenblock

Rechnet man zusammen, was diese Reparaturen kosten, wird die Dimension sichtbar. Jede Stunde für das Nachziehen von Selektoren, das Sichten von Fehlalarmen und das Reparieren „kaputter" Tests ist eine Stunde, in der kein Feature entsteht, kein echter Fehler gefunden und keine Qualität verbessert wird.

Der Schaden ist doppelt. Zum einen die direkte Zeit: Stunden pro Woche, die in Wartung statt in Weiterentwicklung fließen. Zum anderen der Frust. Qualifizierte QA-Engineers wollen Testszenarien entwerfen, Randfälle aufspüren und Qualität gestalten, statt Woche für Woche dieselben Selektoren nachzupflegen. Wartungs-Tetris ist damit nicht nur ein Kostenproblem, sondern auch ein Bindungsproblem.

Selbstheilende Tests: den Kreislauf durchbrechen

Der Ausweg besteht nicht darin, noch mehr Zeit in die Pflege starrer Selektoren zu stecken, sondern die Abhängigkeit von ihnen aufzulösen. Dort setzt selbstheilende Testautomatisierung an, wie wir sie bei Wecon mit relaiable entwickelt haben.

Statt an einer einzigen, fragilen CSS-Klasse zu hängen, erkennt die KI ein Element an mehreren Merkmalen: an Position, Beschriftung, Kontext und seiner Rolle im Ablauf. Verschiebt sich der Button um ein paar Pixel oder ändert sich sein Label, erkennt das System das Element trotzdem wieder und passt den Test automatisch an. Der Test heilt sich selbst, statt rot zu werden. Ein echter Defekt fällt weiterhin auf, eine kosmetische Änderung nicht mehr.

Wenn Tests sich selbst an kosmetische Änderungen anpassen, verschiebt sich die Arbeit der QA vom Reparieren zurück zum Gestalten. Weniger Fehlalarme bedeuten mehr Vertrauen in die Pipeline. Ein grünes Ergebnis heißt dann wieder, dass wirklich alles in Ordnung ist. Und die Stunden, die vorher im Wartungs-Tetris versickert sind, stehen wieder für echte Testabdeckung zur Verfügung.

Eine ehrliche Frage zum Schluss: Wie viele Stunden gehen bei euch pro Woche für das Fixen kaputter Tests drauf? Wenn die Antwort unangenehm hoch ausfällt, lohnt sich ein Gespräch darüber, wie viel davon wirklich nötig wäre.