Kontaktformular testen: die Pre-Launch-Checkliste

Ein kaputtes Kontaktformular ist die schlimmste Art von Bug: Es löst keine Warnungen aus, zerstört kein Layout und meldet sich nur durch Stille - die genau danach aussieht, als würde „niemand anfragen“. Manche Seiten liefen wochenlang mit einem toten Formular, während alle dachten, das Geschäft laufe nur langsam. Fünfzehn Minuten vor dem Launch verhindern das alles.

1. Der Happy Path - von der echten Seite aus

Senden Sie einen echten Test von der bereitgestellten Produktions-URL, nicht von localhost. Nur dieser eine Test prüft das, was lokale Tests nicht können: DNS, TLS und vor allem CORS - wenn Ihr Formular-Backend eine Origin-Allowlist verwendet (das sollte es), ist die Produktion der einzige Ort, an dem Sie entdecken, dass die Domain nicht darauf steht. Testen Sie sowohl www als auch die Apex-Domain, falls Sie beide bedienen.

Bestätigen Sie alle drei Enden: Der Erfolgszustand wird im Browser angezeigt, die Einsendung erscheint im Dashboard, und die Benachrichtigung (Push oder E-Mail) kommt tatsächlich auf dem Gerät an, das Sie wirklich dabei haben werden.

2. Validierung - versuchen Sie, sie zu brechen

• Leer absenden. Jedes required-Feld sollte sich beschweren, an der richtigen Stelle, in einer Sprache, die zur Seite passt (eine serbische Seite mit englischen Browser-Standardmeldungen ist ein klassischer Fehltritt - legen Sie bei Bedarf eigene Meldungen fest).
• not-an-email ins E-Mail-Feld eingeben und absenden.
• Fügen Sie eine wirklich lange Nachricht ein - 5.000 Zeichen - und bestätigen Sie, dass sie akzeptiert wird oder sauber mit einer klaren Grenze scheitert, nicht mit stiller Kürzung.
• Falls Sie ein Datei-Feld haben: richtiger Typ, falscher Typ und eine übergroße Datei. Die übergroße sollte mit einer Meldung scheitern, idealerweise bevor ein langsamer Upload abgeschlossen ist.

3. Der Fehlerpfad - der Test, den alle überspringen

Richten Sie das Formular vorübergehend auf einen unsinnigen Endpoint (oder blockieren Sie die Anfrage in den Devtools) und senden Sie ab. Was sieht die besuchende Person? Die inakzeptable Antwort ist „nichts“ - ein Button, der nichts tut, oder ein endloser Spinner. Es sollte einen Fehlerzustand mit einem Fallback geben („oder schreiben Sie uns an …“). Das ist der Zustand, den Ihre echten Nutzer bei einem Ausfall oder einem missglückten Deploy erleben, und er entscheidet über einen verlorenen oder einen geretteten Lead. Prüfen Sie die Fehlerantworten Ihres Backends, damit Ihre Behandlung dem entspricht, was es tatsächlich zurückgibt.

4. Spam-Abwehr - bestätigen, dass sie an ist, aber nicht zu sehr

• Honeypot: Füllen Sie das versteckte Feld über die Devtools aus und senden Sie ab - es sollte stillschweigend verschluckt werden und nie im Dashboard erscheinen.
• Rate-Limit: Senden Sie mehrmals schnell hintereinander ab; bestätigen Sie, dass die Drosselung greift und dass das Limit großzügig genug für eine legitime Korrektur-und-erneutes-Senden ist.
• Turnstile (falls aktiviert): in einem normalen Fenster und einem privaten Fenster testen; bestätigen Sie, dass der Token-Fehlerpfad eine für Menschen verständliche Meldung zeigt.

(Wie jede Ebene funktioniert: Spamschutz für Kontaktformulare.)

5. Mobile, Tastatur, und der unglamouröse Rest

• Vollständiges Absenden von einem echten Telefon: richtige Tastaturen (type="email" ruft die @-Tastatur auf), ein gut tippbarer Button, sichtbarer Erfolgszustand ohne Scroll-Suche.
• Nur-Tastatur-Durchgang: sinnvolle Tab-Reihenfolge, Enter sendet ab, Fokuszustände sichtbar - und Tab sollte den Honeypot überspringen (landet er dort, fügen Sie tabindex="-1" hinzu).
• Autofill: Lassen Sie den Browser das Formular ausfüllen; bestätigen Sie, dass die Felder sinnvoll zugeordnet werden.
• Die Dankesseiten-Weiterleitung, falls vorhanden, löst korrekt auf und wird nicht durch die Redirect-Validierung des Backends blockiert.

6. Hinterlassen Sie einen Kanarienvogel

Senden Sie sich nach dem Launch einmal im Monat eine echte Einsendung - Kalendererinnerung, dreißig Sekunden. Deploys, DNS-Änderungen und abgelaufene Keys passieren alle; der Kanarienvogel erkennt den stillen Ausfall, bevor zwei Wochen „schwaches Geschäft“ es tun.

Gesamtzeit: etwa fünfzehn Minuten beim Launch, danach dreißig Sekunden im Monat. Die günstigste Versicherung in der Web-Entwicklung.