6 Testarten
Funktion, Browser/Geräte, Inhalt, Performance, Barrierefreiheit, Sicherheit.
4 × 3 Matrix
Die pragmatische Browser- und Geräte-Abdeckung für DACH-Projekte.
7 Angaben
Was ein Bug-Report braucht, damit niemand nachfragen muss.
Das Testen ist der Motor im Review
Tests prüfen gegen Kriterien. Das Review darum herum ergänzt Rollen, Kundenrunde und die Freigabe-Entscheidung.
Website-Testen beantwortet eine Frage mit Belegen: Erfüllt diese Seite die definierte Qualitätslatte – funktional, optisch, auf echten Geräten, bei echter Netzgeschwindigkeit, für alle Nutzer? Das Ergebnis ist eine priorisierte Mängelliste und nach Beheben und Gegenprüfen eine belastbare Launch-Entscheidung.
Das Testen ist ein Teil des größeren Website-Review-Prozesses: Der ergänzt, wer was prüft, die Kundenrunde und die dokumentierte Freigabe. Wenn dieser Prozess bei dir noch nicht steht, starte mit unserem Website-Review-Leitfaden – diese Seite geht in die Tiefe des Test-Motors darin.
Testen nach Gefühl
„Wir haben durchgeklickt, sah gut aus"
- Getestet wird im Browser, den der Tester zufällig nutzt
- Nur der Gutfall – niemand tippt absichtlich eine falsche E-Mail
- Bugs gemeldet als „Kontaktformular geht nicht"
- Nach dem Fix prüft niemand nach
Testen nach Plan
Matrix, Fehlerpfade, gegengeprüfte Fixes
- Eine definierte Browser-/Geräte-Matrix pro Projekt
- Fehler-Zustände und Grenzfälle absichtlich getestet
- Bug-Reports mit Element, Umgebung und Schritten
- Jeder Fix gegengeprüft und auf Regressionen gecheckt
Was „getestet" wirklich abdeckt
Lässt du eine Art aus, bricht es genau dort. Die sechs zusammen sind die Definition von „fertig".
Funktionstest
Tut alles, was es soll? Formulare, Navigation, Suche, Integrationen – jedes Bedienelement, jeder Zustand: Erfolg, Fehler, leer.
Browser- & Gerätetest
Dieselbe Seite in Chrome, Safari, Firefox und Edge – und auf echten Handys. Rendering-Engines widersprechen sich genau da, wo dein Layout am cleversten ist.
Inhalts- & Sichttest
Finale Texte, korrekte Daten, konsistente Abstände, scharfe Bilder. Unspektakulär – aber Inhaltsfehler findet der Kunde zuerst.
Performance
Ladezeit im 4G-Netz, Bildgewichte, Core Web Vitals. Eine Seite, die im Büro grün ist, kann im Zug kriechen.
Barrierefreiheit
Kontraste, Tastatur-Bedienung, Alt-Texte, Fokus-Zustände. Für viele Pflicht, für alle richtig – und findet nebenbei echte Bedienfehler.
Sicherheits- & Datenschutz-Basics
HTTPS überall, Formulare serverseitig validiert, Consent vor Tracking, keine Zugangsdaten im Quelltext. Die Grundlinie, die jedes Projekt schuldet.
Browser und Geräte: das pragmatische Minimum
Alles testen kannst du nicht. Aber das, was deine Besucher wirklich nutzen – plus einen ehrlichen Schritt darüber hinaus.
Zuerst in die Analytics schauen: Die echte Verteilung schlägt jede generische Liste. Ohne Daten deckt diese Matrix den Großteil des DACH-Traffics ab – vier Desktop-Browser, drei physische Geräte, beide Ausrichtungen. Die wichtigste Mobil-Konfiguration immer auf einem echten Gerät testen: Emulation trifft das Layout und verfehlt das Touch-Verhalten.
Desktop-Durchgang
- Chrome (aktuell) – die Mehrheits-Basis
- Safari (aktuell) – der Layout-Engine-Ausreißer
- Firefox (aktuell) – Formulare und Schrift-Rendering
- Edge (aktuell) – Firmen-Umgebungen
- Ein Durchgang bei 1366×768 – nicht jeder hat deinen Monitor
- Zoom bei 125 % und 200 % – Barrierefreiheit und Laptops
Geräte-Durchgang
- Aktuelles iPhone mit Safari – echtes Gerät
- Mittelklasse-Android mit Chrome – echtes Gerät
- Ein Tablet, beide Ausrichtungen
- Touch-Ziele 44 px+, nichts in der Daumen-Falle
- Software-Tastatur verdeckt keine aktiven Felder
- Querformat nicht kaputt
Testen vor dem Launch in 6 Schritten
Die Reihenfolge ist Absicht: Umgebung vor Funktion, Funktion vor Feinschliff – und nach jedem Fix die Gegenprüfung.
- 1
Matrix planen
Festlegen, was wo getestet wird: welche Seiten, welche Browser, welche Geräte, welche Testarten. Eine Matrix aus 4 Browsern × 3 Geräten × Kernseiten schlägt jedes „wir haben durchgeklickt".
- 2
Auf der echten Umgebung testen
Staging muss der Produktion entsprechen: gleiche Server-Konfiguration, echte Inhalte, echte Integrationen im Testmodus. Bugs, die nur auf Produktion existieren, sind Bugs, die du ausgeliefert hast.
- 3
Funktions-Durchgang
Jedes Formular, jeder Link, jedes interaktive Element – inklusive der Fehlerpfade: falsche Eingabe, Doppelklick auf Absenden, Zurück-Button, abgelaufene Sitzung.
- 4
Geräte-Durchgang
Echte Geräte für die Top-Konfigurationen, Emulation für den Rest. Beide Ausrichtungen prüfen, Touch-Ziele, und ob die Tastatur Eingabefelder verdeckt.
- 5
Performance- & Barrierefreiheits-Durchgang
Lighthouse oder PageSpeed als Basis, dann manuell: mit Tab durch die Seite, auf 200 % zoomen, auf 4G drosseln. Zahlen plus Erlebnis.
- 6
Beheben, gegenprüfen, Regression checken
Jeden Fix prüft die Person nach, die den Bug gemeldet hat – und die Umgebung bekommt einen kurzen Regressions-Blick. Fixes machen gern das Nachbarelement kaputt.
Der Schritt, den alle auslassen
Der Bug-Report, der keine Rückfrage braucht
Die halbe QS-Zeit verschwindet ins Nachfragen. Die Lösung: ein Format, das den Kontext im Moment des Fundes einsammelt.
Ein brauchbarer Bug-Report beantwortet sieben Fragen: wo (URL), was genau (das Element), in welcher Umgebung (Gerät, Browser, Betriebssystem), wie nachstellbar (Schritte), was erwartet wurde, was stattdessen passiert ist – und wie es aussieht (Screenshot, oder besser: eine Markierung direkt auf der Live-Seite).
Dass die meisten Reports die Hälfte davon vermissen lassen, ist keine Faulheit – die Umgebungs-Infos von Hand zu sammeln ist mühsam. Werkzeuge, die Feedback direkt am Element verankern, erfassen URL, Gerät, Browser und Betriebssystem automatisch. So kommt sogar der Bug-Report des Kunden vollständig an, ohne dass der Kunde wissen muss, was eine Betriebssystem-Version ist.
Bug-Reports, die sich selbst dokumentieren
Mit bepeq trägt jede gepinnte Anmerkung automatisch Seite, Element, Gerät, Browser und Betriebssystem. Bei vagen Meldungen fragt der Pilot nach, solange die Person noch auf der Seite ist – und nachgetestet wird genau dort, wo der Bug markiert wurde.
bepeq kostenlos testenKunde
„Der Bereich oben gefällt mir nicht so."
✦ bepeq Pilot fragt nach
Was genau stört: Farben, Bild oder Text?
Hero-Bild heller, Headline kontrastreicher.
umsetzbarPassende Leitfäden und Vorlagen
Website-Review
Der breitere Prozess ums Testen: Rollen, Kundenrunde, dokumentierte Freigabe.
Website-Relaunch-Checkliste
40 Punkte in 5 Phasen – speziell für Relaunch-Projekte.
Abnahmetest
Der Test nach der QS: der Kunde prüft gegen die Vereinbarung und nimmt ab.
Bug-Report-Vorlage
Die 7 Felder aus diesem Guide als kopierbare Vorlage.
Häufige Fragen zum Website-Testen
Wie testet man eine Website vor dem Livegang?
Systematisch in sechs Testarten: Funktion (Formulare, Links, Integrationen samt Fehlerpfaden), Browser und Geräte (definierte Matrix, echte Handys), Inhalte, Performance (4G, Core Web Vitals), Barrierefreiheit (Kontraste, Tastatur) und Sicherheits-/Datenschutz-Basics. Ergebnis ist eine priorisierte Mängelliste – nach Beheben und Gegenprüfen ist der Livegang belastbar.
Was ist der Unterschied zwischen Website testen und Website-Review?
Das Testen prüft gegen technische Kriterien und passiert überwiegend im Team. Das Review ist der breitere Prozess darum herum: Es ergänzt Rollen, die Kundenrunde und die formale Freigabe-Entscheidung. Das Testen ist der Motor im Review – unser Website-Review-Leitfaden zeigt, wie beides zusammenspielt.
Auf welchen Browsern und Geräten sollte man testen?
Ein pragmatisches Minimum für Projekte im deutschsprachigen Raum: Chrome, Safari, Firefox und Edge am Desktop; ein aktuelles iPhone (Safari), ein Mittelklasse-Android (Chrome), ein Tablet. Die echte Verteilung zeigt deine Analytics – und die wichtigste Mobil-Konfiguration gehört immer auf ein physisches Gerät, nicht nur in die Emulation.
Was gehört in einen guten Bug-Report?
Sieben Angaben: die Seite (URL), das exakte Element, Gerät, Browser und Betriebssystem, die Schritte zum Nachstellen, das erwartete und das tatsächliche Verhalten – plus Screenshot oder besser eine Markierung direkt auf der Live-Seite. Fehlt die Umgebungs-Info, kostet jeder Bug eine Rückfrage-Runde; bei 30 Bugs ist das eine verlorene Woche.
Manuell oder automatisiert testen?
Für typische Marketing- und Unternehmens-Websites gewinnt manuelles, checklisten-geführtes Testen beim Kosten-Nutzen-Verhältnis – die Seite ändert sich nach dem Launch selten. Automatisierung lohnt sich für Web-Apps, Shops und Projekte mit laufenden Deployments. Starte manuell und strukturiert; automatisiere die Checks, die du am häufigsten wiederholst, sobald das Projekt es rechtfertigt.