Eine Lovable-Änderung hat eine andere Funktion beschädigt. Was nun?

Bestätigen Sie die Regression unter gleichen Ausgangsbedingungen

Eine Regression liegt vor, wenn ein zuvor funktionierendes Verhalten nicht mehr wie erwartet funktioniert. Vergleichen Sie die aktuelle Version mit der zuletzt funktionierenden Version. Verwenden Sie möglichst dieselbe Rolle, dieselben Testdaten und dieselbe Konfiguration.

Wenn sich das frühere Ergebnis nicht reproduzieren lässt, halten Sie die Unterscheidung fest: Sie haben einen Fehler gefunden, aber noch nicht geklärt, wann er entstanden ist. Prüfen Sie Berechtigungen, Konfiguration und Ausgangsdaten, bevor Sie eine bestimmte Codeänderung als Ursache benennen.

Halten Sie die fehlerhafte Version von Ihren Kunden fern

Ist die Änderung noch nicht veröffentlicht, stellen Sie die Veröffentlichung während der Untersuchung zurück. Ist sie bereits produktiv und stellt ein ernstes Risiko dar, prüfen Sie die Rückkehr zu einer funktionierenden Version und die Einschränkung der betroffenen Aktion.

Ein Zurücksetzen des Codes macht Datenbankänderungen nicht zwangsläufig rückgängig und stellt gelöschte Datensätze nicht automatisch wieder her. Prüfen Sie vorher die Kompatibilität und vorhandene Backups. Reproduzieren Sie den Fehler mit entbehrlichen Testdaten.

Nutzen Sie die Codeänderung, um die Suche einzugrenzen

Prüfen Sie in GitHub die Unterschiede zwischen beiden Versionen. Beginnen Sie mit dem Code der betroffenen Aktion: Berechtigungsprüfungen, gemeinsam genutzte Komponenten, Anfrageverarbeitung und Zugriffsrichtlinien für Daten.

Suchen Sie beim Beispiel mit Leserechten nach einer entfernten Rollenprüfung in einer gemeinsamen Löschfunktion oder nach einer geänderten Zugriffsrichtlinie. Das sind zu prüfende Hypothesen, keine feststehenden Ursachen. Die Schaltfläche kann unverändert sein, während der Server eine früher abgelehnte Anfrage akzeptiert.

• Betrifft der Fehler nur eine Rolle oder einen Arbeitsbereich?
• Tritt er über die Oberfläche, durch eine direkte Anfrage oder über beide Wege auf?
• Ändern sich die Daten tatsächlich, oder meldet nur die Oberfläche Erfolg?
• Welche angrenzenden Abläufe verwenden den geänderten Code?

Geben Sie Lovable einen reproduzierbaren Fehlerbericht

„Es funktioniert immer noch nicht“ lässt zu viele Möglichkeiten offen. Beschreiben Sie den Ausgangszustand, die genaue Aktion und das erwartete Ergebnis. Benennen Sie anschließend das korrekte Verhalten, das bei der Korrektur erhalten bleiben muss.

Fügen Sie die getesteten Versionen und relevante Fehlernachweise hinzu. Lassen Sie Passwörter, Tokens und personenbezogene Kundendaten weg. Der Bericht sollte den Fehler reproduzierbar machen, ohne Zugriff auf das Konto eines echten Kunden zu benötigen.

Prüfen Sie die Korrektur und bewahren Sie die Regel

Führen Sie nach der Korrektur das ursprüngliche Szenario erneut aus. Prüfen Sie anschließend eine erlaubte Aktion und die angrenzende Zugriffsgrenze. In diesem Beispiel: Das Konto mit Leserechten wird blockiert, der Eigentümer kann löschen und ein Mitglied eines anderen Unternehmens kann das Dokument weder lesen noch löschen.

Bewahren Sie diese Erwartungen in der Regressionstestsuite auf und ordnen Sie sie der geschützten Geschäftsregel zu. Wenn sich das Berechtigungsmodell absichtlich ändert, passen Sie das erwartete Verhalten ausdrücklich an, statt jedes neue Ergebnis als korrekt zu übernehmen.