Vor der Veröffentlichung
Eine praktische Launch-Checkliste für Vibe Coding
Eine überzeugende Vorschau ist ein Anfang. Für eine Veröffentlichung brauchst du Nachweise, dass die Hauptaufgabe funktioniert, Fehler verständlich sind und die öffentliche Beschreibung stimmt. Diese Checkliste greift auf unsere Arbeit an der LaunchVibe-Website zurück. Sie bedeutet nicht, dass wir jede native App im Katalog getestet haben.
Halte fest, was diese Version leistet
Wähle einen Ablauf, den neue Besucher ohne deine Hilfe abschließen können sollen. Benenne den Ausgangspunkt, die Aktion und das sichtbare Ergebnis. Liste die Funktionen auf, die du zunächst weglässt. Wenn eine Schaltfläche einen anderen Store oder eine andere Website öffnet, benenne dieses Ziel, statt den Eindruck zu erwecken, die Aktion finde in deiner App statt.
Vergleiche die öffentlichen Texte mit der tatsächlichen Version. Verwende echte Screenshots, kennzeichne Illustrationen und entferne Aussagen ohne Beleg. Ein kleines, funktionierendes Werkzeug mit klaren Grenzen lässt sich leichter beurteilen als eine lange Funktionsliste mit unfertigen Bedienelementen.
Teste den Ablauf und seine Fehlerfälle
Durchlaufe den gesamten Ablauf in einem Browser ohne bisherige Daten und anschließend mit vorhandenen Daten. Prüfe leere Eingaben, langen Text, langsame Anfragen, eine fehlgeschlagene Anfrage und wiederholtes Klicken. Stelle sicher, dass ein erneuter Versuch weder einen doppelten Datensatz erzeugt noch den Entwurf der Person verliert.
Bei LaunchVibe ist die Merkliste eine lokale Browsereinstellung, während eine Community-Stimme ein Datensatz auf dem Server ist. Diese Aktionen erfordern unterschiedliche Prüfungen. Die Stimmenzahl sollte sich erst nach einer erfolgreichen Serverantwort ändern; beim lokalen Speichern sollte ein Speicherfehler erklärt werden. Lege vor dem Testen fest, welches System für welches Ergebnis verantwortlich ist.
- Halte den geprüften Browser, die Größe des sichtbaren Bereichs und die Build-Version fest.
- Lasse fehlgeschlagene Prüfungen sichtbar, bis sie behoben oder ausdrücklich vom Umfang der Veröffentlichung ausgenommen wurden.
- Verwende Testdaten und simulierte Dienste, wenn eine Prüfung sonst echte Menschen oder Produktionskennzahlen beeinflussen würde.
Prüfe Daten und Berechtigungen getrennt
Skizziere kurz, was auf dem Gerät bleibt, was deinen Server erreicht und was an einen anderen Anbieter geht. Servergeheimnisse gehören niemals in Browsercode. Teste, ob ein Besucher die Datensätze eines anderen ändern kann und ob abgelaufene Sitzungen einen verständlichen Fehler auslösen.
Auch Gastzugriff braucht Regeln. Eine Gastkennung im Browser beweist nicht, dass es sich um einen eindeutig identifizierten Menschen handelt. Berücksichtige bei Kommentaren die Darstellung als reinen Text, Löschung, Meldungen und Moderation, bevor du öffentliche Beiträge zulässt. Teste bei destruktiven Aktionen die Bestätigung und den tatsächlichen Wiederherstellungsweg, statt anzunehmen, dass die Beschriftung „Rückgängig“ genügt.
Nutze die App mit der Tastatur und auf einem kleinen Bildschirm
Durchlaufe den Hauptablauf ohne Maus. Prüfe einen sichtbaren Fokus, aussagekräftige Feldbeschriftungen und Fehlermeldungen, die nicht allein durch Farbe vermittelt werden. Öffne und schließe einen Dialog; der Fokus sollte an eine sinnvolle Stelle zurückkehren. Probiere neben einer schmalen Ansicht auch lange übersetzte Beschriftungen und die Zoomfunktion aus.
Die Easy Checks des W3C bieten einen nützlichen Einstieg. Einige bestandene manuelle Prüfungen sind keine vollständige Bewertung der Barrierefreiheit. Halte fest, was du geprüft hast, und benenne weiterhin ausdrücklich, welche Hilfstechnologien oder Browserkombinationen nicht getestet wurden.
Quelle: W3C WAI: Easy Checks
Passe den Datenschutz an die laufende App an
Erkläre, welche Informationen du tatsächlich verarbeitest und warum. Wenn du optionale Analytics anbietest, teste Ablehnung, Zustimmung und Widerruf als getrennte Zustände. Prüfe, ob Anfragen an Anbieter erfolgen, bevor Besucher die Entscheidung getroffen haben, die du zu respektieren versprochen hast.
Halte Suchbegriffe, Kommentartexte und andere persönliche Eingaben aus Analytics-Ereignissen heraus. Prüfe Links zu externen Stores und erkläre, dass dort deren Richtlinien gelten. Eine kopierte Datenschutzerklärung kann keine Implementierung beschreiben, die du nicht untersucht hast. Aktualisiere sie, wenn sich die Datenflüsse ändern.
Veröffentliche eine bekannte Version mit einem Weg zurück
Erstelle den Build anhand der eingecheckten Lockdatei, überprüfe das Zielkonto und kontrolliere die veröffentlichten Routen, Links, HTTPS und das Verhalten bei nicht vorhandenen Seiten. Halte die vorherige funktionierende Version eindeutig fest. Bei Cloudflare Workers sind Codeversionen und Deployments getrennt; Datenbankinhalte werden durch das Zurücksetzen einer Codeversion nicht zurückgesetzt.
Wenn eine Veröffentlichung Daten verändert, plane diese Änderung separat. Wiederhole nach der Veröffentlichung eine kleine Prüfung ohne Schreibzugriffe auf der echten Domain. Beschreibe einen lokalen Test nicht als Nachweis für die Produktionsumgebung und eine Anfrage an einen Anbieter nicht als Beweis dafür, dass er sie verarbeitet hat.
Build / Commit: Geprüfter Hauptablauf: Umgebung und Browser: Bestandene Prüfungen und Nachweise: Bekannte Grenzen / nicht durchgeführte Prüfungen: Datenänderungen, falls vorhanden: Vorherige funktionierende Version: Wer kann zurücksetzen und wie:
Triff die Entscheidung zur Veröffentlichung ausdrücklich
Behebe Fehler, die den versprochenen Ablauf verhindern. Entscheide bei verbleibenden Einschränkungen, ob du die Funktion verschiebst, sie klar kennzeichnest oder die Veröffentlichung verzögerst. Dies ist eine Checkliste für Webveröffentlichungen. Prüfungen nativer Apps und produktspezifische Pflichten brauchen eigene Kontrollen.