← Alle Beiträge

Was QA für eine Website bedeutet und wie ich vor dem Launch teste

Qualitätssicherung für Websites: was vor dem Launch zu prüfen ist, von Formularen und Core Web Vitals bis Barrierefreiheit, und wie Playwright und Lighthouse es automatisieren.

Auf dieser Seite

Die meisten Fehler auf einer Website findet nicht, wer sie gebaut hat. Sie findet eine Kundin auf dem Handy, drei Wochen nach dem Launch, wenn das Kontaktformular unbemerkt keine E-Mails mehr verschickt. Qualitätssicherung (QA) verlegt diese Funde vor den Launch, wo sie günstig zu beheben sind.

Hier steht, was QA für eine Website bedeutet, was ich vor dem Livegang prüfe und welche Teile sich zu automatisieren lohnen.

Was QA ist und was nicht

QA ist die Summe der Prüfungen, die eine Frage beantworten: Tut die Website, was sie verspricht, für alle Besucher, auf jedem Gerät? Das ist mehr als „sieht auf meinem Laptop gut aus“:

  • Funktion: Formulare senden, Links funktionieren, die Navigation erreicht jede Seite.
  • Kompatibilität: Das Layout hält auf kleinen Handys, großen Bildschirmen und in den Browsern, die Ihre Besucher tatsächlich nutzen.
  • Performance: Seiten laden schnell auf einem Mittelklasse-Handy und im Mobilfunknetz.
  • Barrierefreiheit: Die Website funktioniert mit Tastatur und Screenreader.
  • SEO-Grundlagen: Titel, Beschreibungen und strukturierte Daten sind vorhanden und korrekt.

QA ist kein einzelner Testlauf am Ende. Prüfungen, die erst am Tag vor dem Launch stattfinden, fallen weg, sobald es knapp wird, und genau dann wären sie am wichtigsten.

Warum das für eine Unternehmenswebsite zählt

Ein Fehler auf der Website eines kleinen Unternehmens ist selten dramatisch. Nichts stürzt ab. Ein Formular schlägt fehl, eine Anfrage kommt nie an, eine Seite braucht auf dem Handy sechs Sekunden und der Besucher geht zurück zu den Suchergebnissen. Diese Verluste sehen Sie in keinem Fehlerprotokoll, nur an weniger Anfragen.

Der teuerste Fehler ist der, den niemand meldet.

Was ich vor einem Launch prüfe

Formulare, Links und Navigation

Jedes Formular wird echt abgeschickt, mit gültigen und ungültigen Eingaben, und ich prüfe, dass die Nachricht dort ankommt, wo sie soll. Jeder Link in Navigation, Footer und Inhalt wird aufgerufen. Weiterleitungen von alten URLs teste ich einzeln.

Geräte und Browser

Ich prüfe die wichtigsten Seitentypen in Handy-, Tablet- und Desktop-Breite, in Chrome, Safari und Firefox. Safari auf iOS bekommt besondere Aufmerksamkeit: Von dort kommen die meisten Layout-Überraschungen.

Performance

Ich messe die Core Web Vitals (LCP, INP und CLS) auf den schwersten Seiten, mit gedrosselter Mobilverbindung. Große Bilder, blockierende Skripte und Tags von Drittanbietern sind die üblichen Verdächtigen.

Barrierefreiheit

Tastaturnavigation durch die ganze Seite, sichtbare Fokuszustände, beschriftete Formularfelder, ausreichender Kontrast, Alternativtexte für Bilder und genau ein h1 pro Seite. Automatische Tools finden etwa ein Drittel der Probleme; den Rest findet nur ein Mensch mit Tastatur.

SEO-Grundlagen

Eindeutige Titel und Meta-Beschreibungen, eine Canonical-URL auf jeder Seite, hreflang bei mehrsprachigen Websites, eine Sitemap und eine robots.txt, die nicht versehentlich die ganze Website sperrt.

Die wiederkehrenden Teile automatisieren

Manuelle Prüfungen finden die überraschenden Probleme. Automatische Prüfungen sorgen dafür, dass behobene Probleme behoben bleiben. Diese drei richte ich in den meisten Projekten ein.

End-to-End-Tests mit Playwright

Playwright steuert einen echten Browser durch die Website. Ich lasse die Tests gegen den Produktions-Build laufen, in Desktop- und Mobil-Ansicht:

playwright.config.ts
import { defineConfig, devices } from "@playwright/test";

export default defineConfig({
  testDir: "./tests",
  use: { baseURL: "http://localhost:4321" },
  projects: [
    { name: "desktop", use: { ...devices["Desktop Chrome"] } },
    { name: "mobile", use: { ...devices["Pixel 7"] } },
  ],
  // Builds are tested as they ship: against `astro preview`, not the dev server.
  webServer: {
    command: "npm run build && npm run preview",
    url: "http://localhost:4321",
    reuseExistingServer: !process.env.CI,
  },
});

Die Tests selbst bleiben klein. Sie prüfen, dass jede wichtige Seite lädt, genau ein h1 hat und keine Fehler in der Konsole ausgibt:

tests/pages.spec.ts
import { test, expect } from "@playwright/test";

const pages = ["/", "/about/", "/services/", "/projects/", "/de/"];

for (const path of pages) {
  test(`${path} has a title, one h1 and no console errors`, async ({ page }) => {
    const errors: string[] = [];
    page.on("console", (msg) => msg.type() === "error" && errors.push(msg.text()));

    const response = await page.goto(path);
    expect(response?.status()).toBe(200);
    await expect(page).toHaveTitle(/.+/);
    await expect(page.locator("h1")).toHaveCount(1);
    expect(errors).toEqual([]);
  });
}

test("the main navigation reaches every page", async ({ page }) => {
  await page.goto("/");
  await page.getByRole("link", { name: "Projects" }).first().click();
  await expect(page).toHaveURL(/\/projects\/$/);
});

Lighthouse-Budgets

Lighthouse CI prüft die gebaute Website mit Lighthouse und schlägt fehl, wenn ein Wert unter eine Schwelle fällt. So rutscht kein schweres Bild und kein neues Skript unbemerkt durch:

lighthouserc.json
{
  "ci": {
    "collect": {
      "staticDistDir": "./dist",
      "numberOfRuns": 3
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.9 }],
        "categories:accessibility": ["error", { "minScore": 0.95 }],
        "categories:seo": ["error", { "minScore": 0.95 }]
      }
    }
  }
}

Defekte Links

Ein Link-Checker durchsucht die gebauten Seiten und meldet jeden Link, der einen Fehler liefert:

bash
# Build first, then crawl every page in dist/ and report broken links.
npm run build
npx linkinator ./dist --recurse --verbosity error

Bei jeder Änderung ausführen

Das alles läuft bei jedem Pull Request, sodass nichts ungeprüft auf die Live-Website kommt:

.github/workflows/qa.yml
name: QA

on: [pull_request]

jobs:
  qa:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run build
      - run: npx linkinator ./dist --recurse --verbosity error
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test
      - run: npx @lhci/cli autorun

Eine Checkliste für den Launch

Die Kurzfassung, die ich vor jedem Launch durchgehe:

  1. Jedes Formular abschicken und prüfen, dass die Nachricht ankommt.
  2. Navigation und Footer auf dem Handy durchklicken.
  3. Die wichtigsten Seitentypen in Safari auf iOS testen.
  4. Core Web Vitals auf der schwersten Seite prüfen.
  5. Die Seite nur mit der Tastatur durchgehen.
  6. Titel, Beschreibungen, Canonical-URLs und Sitemap prüfen.
  7. Weiterleitungen von den meistbesuchten URLs der alten Website testen.
  8. Prüfen, dass Analytics und Cookie-Einwilligung wie gewünscht funktionieren.

QA endet nicht mit dem Launch

Inhalte ändern sich, Plugins werden aktualisiert, und im Header taucht ein neues Marketing-Skript auf. Die automatischen Prüfungen laufen bei jeder Änderung weiter, und ein kurzer manueller Durchgang nach größeren Updates findet, was sie nicht sehen. QA ist weniger eine Projektphase als eine Gewohnheit der Codebasis.

Wenn Sie vor oder nach einem Launch einen zweiten Blick auf Ihre Website möchten, schreiben Sie mir. Ich sage Ihnen, was ich zuerst prüfen würde.