RenderLog Leitfäden
Diese Leitfäden helfen zu entscheiden, was erfasst, was regelmäßig geprüft und wann Referenzen, Benachrichtigungen oder längere Historie ergänzt werden sollten. Jeder Artikel beginnt mit einer echten Seitenaufgabe, nicht mit einer allgemeinen Testliste.
Hier starten
Wähle den Einstieg, der am besten zu der Seite passt, die du schützen oder rendern willst.
API-Ausgabe
Wähle das, wenn ein Produkt, Backend-Job oder Kundenauftrag Screenshots, PDFs, HTML, Markdown oder gespeicherte Dateien braucht.
Wiederkehrende Prüfungen
Nutze das, wenn dieselbe URL, Ansicht und Seitensituation wiederholt mit Historie und Review geprüft werden soll.
Preisseiten
Starte hier, wenn Preiskarten, Rabatte, Checkout-Links oder lokalisierte Preise nach Produktänderungen abweichen können.
SEO-Probleme und UI-Regressionen sehen fur Uptime-Checks oft gesund aus. Offentliche Seiten brauchen Tests, die die gerenderte Seite wie Reviewer und Crawler sehen.
Nützlich wenn: Prufen, dass indexierbare Seiten 200 zuruckgeben und nicht durch Robots-Tags blockiert sind.
Beginnen Sie mit Zuständen, die Menschen ohnehin im Browser prüfen: Preis, Anmeldeformular, Dokumentationsseite oder ein Komponentenstatus, der nach einer Veröffentlichung stabil bleiben muss.
Nützlich wenn: Preisseite: Preis und Call-to-Action sehen weiterhin korrekt aus.
Preisseiten ändern sich oft und brechen leise. RenderLog beobachtet die ganze Seite, vergleicht sie mit einem freigegebenen Stand und hält den Kontext für die nächste Preisentscheidung fest.
Nützlich wenn: Falscher Call-to-Action nach einem Kampagnen-Update.
Nutze sofortige Warnungen für kaputte Seiten und tägliche Digests für stabile Prüfhistorie, die das Team nicht nach jedem Lauf unterbrechen soll.
Nützlich wenn: Sofortige Alerts für dringende Fehler und blockierte Zustände.
Die Basishistorie deckt aktuelle Arbeit ab. Einjährige Aufbewahrung ist für Teams gedacht, die ältere Ergebnisdateien, Referenzen und Prüfkontext leicht finden müssen.
Nützlich wenn: Jüngste Historie für aktuelle QA und Launch-Review.
Fehlerregeln halten schlechte Aufnahmen aus der Prüfung heraus, damit Teams echte visuelle Änderungen prüfen.
Nützlich wenn: Login-Wall statt der erwarteten Seite.
Starte mit GET für schnelle Ausgaben. Wechsle zu POST, wenn Secrets, längere Eingaben, Speicherziele oder wiederholbare Schritte dazukommen.
Nützlich wenn: GET: schneller Aufruf mit URL und wenigen Query-Parametern.
Ein Screenshot wird erst dann zu nützlichem Prüfmaterial, wenn klar ist, was freigegeben ist, was sich geändert hat und wer als Nächstes reagieren soll.
Nützlich wenn: Die Seite nach einem bewussten Release oder Designwechsel freigeben.
Plane eine Seite, wenn jemand das Ergebnis verantwortet und dasselbe Capture-Setup erneut laufen muss.
Nützlich wenn: Prüfungen nach Deployments für Preis- oder Sign-up-Seiten.
Starte manuell, wenn eine Seite schnell geprüft werden muss. Speichere dasselbe Setup erst dann als Automatisierung, wenn die Prüfung wiederkehrt.
Nützlich wenn: Ein gemeldetes Layoutproblem prüfen, ohne auf einen Zeitplan zu warten.
Mach aus der nächsten wichtigen Seite ein gespeichertes Ergebnis, eine freigegebene Referenz oder eine wiederkehrende Prüfung statt eines einmaligen Problems.
