Trust & Guardrails

Self-Healing darf einen echten Bug nicht unsichtbar machen.

Der Wert von Healing liegt nicht darin, jeden roten Test grün zu machen. Er liegt darin, klar zwischen technischer Locator-Drift, unsicheren Treffern und echten Produktfehlern zu unterscheiden.

Fail closedHealing HistoryReviewbarer Fix
✓
HealKlarer Locator-Drift mit belastbarem Ziel.
?
ReviewMehrere plausible Kandidaten oder zusätzlicher Kontext nötig.
!
FailAssertion, Business-Logik oder kein sicherer Ersatz.
Guardrails

Vier Prinzipien für vertrauenswürdiges Self-Healing.

Automatisierung bleibt nur dann wertvoll, wenn Healing transparent, begrenzt und überprüfbar ist.

01

Locator-Probleme von Produktfehlern trennen

Healing adressiert technische Element-Zuordnung – nicht fachliche Assertions oder echte Anwendungsfehler.

02

Unsicherheit sichtbar lassen

Wenn kein belastbarer Kandidat existiert, ist ein roter Test besser als ein falscher grüner Test.

03

Healing nachvollziehbar machen

Original-Locator, Ersatz und Kontext sollten für Team und Review sichtbar bleiben.

04

Dauerhafte Fixes kontrollieren

Automatic Code Update soll in normale Git- und Review-Prozesse passen, statt Änderungen zu verstecken.

Healing Boundary

Was Healing lösen sollte – und was nicht.

Eine klare Grenze hilft Teams, TestZombie als Wartungsautomatisierung statt als Fehler-Unterdrückung einzusetzen.

Gute Healing-Kandidaten
  • ID, CSS, XPath, Rolle oder Accessibility-Identifier geändert
  • Element befindet sich nach UI-Refactoring an einer neuen Position
  • Technischer Locator ist veraltet, der fachliche User Flow bleibt gleich
Bewusst fehlschlagen
  • Assertion oder erwartetes Business-Ergebnis ist falsch
  • Ziel-Element existiert fachlich nicht mehr
  • Mehrere Kandidaten sind zu ähnlich und nicht sicher zuzuordnen
FAQ

FAQ zu sicherem Self-Healing

Sollte Self-Healing jeden Testfehler reparieren?

Nein. Self-Healing ist besonders für technische Locator- und UI-Drift geeignet. Fachliche Assertions und echte Produktfehler sollten sichtbar bleiben.

Was passiert bei mehreren möglichen Ziel-Elementen?

Wenn die Zuordnung nicht ausreichend sicher ist, sollte der Test fehlschlagen oder in einen Review-Fall gehen, statt willkürlich weiterzulaufen.

Warum ist Automatic Code Update Teil der Trust-Story?

Weil erfolgreiche Healings dadurch nicht dauerhaft unsichtbar im Runtime-Layer bleiben. Der Fix kann sichtbar, reviewbar und wartbar in den Testcode überführt werden.