Kurz gesagt
Eine Pre-Launch-QA prüft vier Bereiche: Inhalt und Links, Funktionen wie Formulare, technische Grundlagen wie Weiterleitungen und Tracking, sowie die Darstellung auf mehreren Geräten. Jeder Bereich braucht eine eigene, abhakbare Liste statt einer allgemeinen Sichtprüfung.
Warum eine strukturierte Liste besser ist als „einmal durchklicken“
Beim freien Durchklicken werden immer dieselben Bereiche geprüft (Startseite, Navigation) und andere übersehen (404-Seite, Formularvalidierung). Eine feste Liste stellt Vollständigkeit sicher.
Inhalt und Text prüfen
Checkliste für den Inhaltsbereich:
- Rechtschreibung und Zahlen (Preise, Telefonnummern, Adressen)
- Platzhaltertexte („Lorem Ipsum“) vollständig entfernt
- Bilder haben Alt-Texte
- Rechtliche Seiten (Impressum, Datenschutz) aktuell und verlinkt
Links und Navigation prüfen
Checkliste für Links:
- Alle internen Links führen zum richtigen Ziel
- Externe Links öffnen wie vorgesehen (neuer Tab oder nicht)
- 404-Seite existiert und verlinkt zurück zur Startseite
- Footer- und Header-Links funktionieren auf jeder Unterseite
Funktionen und Formulare prüfen
Checkliste für Funktionen:
- Kontaktformular sendet und liefert eine Bestätigung
- Newsletter-Anmeldung funktioniert inkl. Double-Opt-in falls vorhanden
- Suchfunktion liefert erwartete Ergebnisse
- Login/Checkout-Prozess vollständig durchgetestet
Technische Grundlagen prüfen
Checkliste für Technik:
- SSL-Zertifikat aktiv, keine Mixed-Content-Warnungen
- Weiterleitungen von alten URLs eingerichtet (301, nicht 302)
- Tracking- und Analytics-Code korrekt eingebunden
- Sitemap und robots.txt korrekt konfiguriert
- Staging-Umgebung ist nicht mehr für Suchmaschinen indexierbar
Performance und Ladezeit prüfen
Vor dem Launch lohnt sich ein Blick auf Ladezeit unter realen Bedingungen, nicht nur im schnellen Büro-WLAN. Teste explizit auf einer mobilen Verbindung.
Mobilgeräte und Browser prüfen
Checkliste für Endgeräte:
- Darstellung auf kleinem Smartphone-Bildschirm (z. B. 375px Breite)
- Darstellung auf Tablet-Größe
- Mindestens ein weiterer Browser neben dem Standardbrowser getestet
- Touch-Bedienung von Menüs und Formularen funktioniert
Barrierefreiheit als Teil der QA
Vier schnelle Prüfungen decken die häufigsten Probleme ab: ausreichender Farbkontrast, Tastaturbedienbarkeit, sinnvolle Überschriftenstruktur und Alt-Texte für Bilder.
Wer sollte die Pre-Launch-QA durchführen?
Am zuverlässigsten arbeitet eine Person außerhalb des Projektteams, weil sie unbefangen prüft. Fachliche Inhalte prüft zusätzlich der Auftraggeber selbst.
Feedback aus der QA strukturiert erfassen
Statt Ergebnisse in eine E-Mail zu schreiben, jede gefundene Abweichung als eigene Notiz direkt am betroffenen Element festhalten – das verhindert, dass Punkte beim Abarbeiten verloren gehen.
Nach dem Launch weiterprüfen
Die ersten 24 Stunden nach dem Launch verdienen eine zweite, kurze Prüfrunde: Tracking-Daten laufen ein, Formulare wurden echt genutzt, Suchmaschinen crawlen die neue Struktur.
Wer ist wofür verantwortlich?
Eine Pre-Launch-QA scheitert selten an fehlendem Wissen, sondern an unklarer Zuständigkeit. Lege pro Bereich eine verantwortliche Person fest: Entwicklung für Technik und Performance, Design für visuelle Konsistenz, Fachabteilung oder Kunde für inhaltliche Richtigkeit, und eine Projektleitung, die die Liste konsolidiert und den Launch final freigibt. Ohne diese Zuordnung prüfen mehrere Personen dieselben offensichtlichen Punkte doppelt, während weniger offensichtliche Bereiche wie Formularvalidierung oder Weiterleitungen ganz durchfallen. Halte die Zuständigkeiten in der Checkliste selbst fest, nicht in einem separaten Dokument, damit bei jedem Punkt klar ist, wer ihn abhaken darf.
Häufige Fehler bei der Pre-Launch-QA
Diese Muster führen regelmäßig zu Fehlern, die erst nach dem Launch auffallen:
- QA findet nur auf dem Desktop-Browser des Prüfenden statt
- Die Liste wird aus dem Gedächtnis abgearbeitet statt schriftlich abgehakt
- Formulare werden angeschaut, aber nie tatsächlich abgeschickt
- Die Prüfung findet Tage vor dem Launch statt, danach ändert sich noch Inhalt
- Niemand prüft die Staging-Umgebung nach Freigabe auf versehentliche Indexierung
Häufige Fragen
Wie lange dauert eine gründliche Pre-Launch-QA?
Für eine mittelgroße Website meist ein halber bis ein ganzer Arbeitstag, abhängig von der Anzahl der Unterseiten.
Reicht ein Test in Chrome aus?
Nein, mindestens ein zweiter Browser und ein Mobilgerät sollten geprüft werden, da sich Darstellungsfehler oft nur dort zeigen.
Wann sollte die QA stattfinden?
Auf der Staging-Umgebung, kurz vor dem geplanten Launch-Termin, mit Zeitpuffer für Korrekturen.
Wer trägt die Verantwortung, wenn nach dem Launch ein Fehler auftaucht?
Das sollte vorab vertraglich geklärt sein, meist abhängig davon, ob der Fehler in der QA sichtbar gewesen wäre.
Braucht jede Website eine Barrierefreiheitsprüfung?
Eine Basisprüfung schadet nie und deckt oft die größten Probleme mit geringem Aufwand ab.
Wie dokumentiert man QA-Ergebnisse am besten?
Als einzelne Notizen direkt am betroffenen Element mit Status, statt als eine lange Liste in einem Dokument.
Sollte man Formulare mit echten Daten testen?
Ja, mit Testdaten, die anschließend aus dem System entfernt werden, um echte Kundendaten nicht zu verfälschen.