Einleitung: Selbst kochen, was man predigt
Es ist leicht, Teams zu Quality Engineering zu beraten und dann ein eigenes Projekt ohne Tests, ohne Pipeline und mit der stillen Annahme zu veröffentlichen, dass es auf meinem Rechner schon passt. Ich wollte, dass meine eigene Website den Standard erfüllt, den ich von anderen verlange.
Dies ist ein kurzer Bericht darüber, eine kleine Marketing-Website wie ein Produkt zu behandeln: wo Quality Engineering das Ergebnis wirklich verändert hat und welches Problem ohne sie verborgen geblieben wäre.
Wenn eine Praxis empfehlenswert ist, sollte man sie zuerst auf die eigene Arbeit anwenden.
1. Qualität ist ein System, keine Endkontrolle
Bei einer kleinen Website ist die Versuchung groß, einmal manuell zu testen und es dabei zu belassen. Aber Qualität ist eine Eigenschaft des gesamten Delivery-Systems, kein Moment am Ende. Dasselbe Prinzip gilt auch im Kleinen: Build, Lint, Test und Deployment sollten selbst bei einem persönlichen Projekt einen durchgehenden, automatisierten Kreislauf bilden.
Konkret bedeutete das eine Pipeline, die bei jedem Push läuft, und eine Produktionsseite, die immer nur das widerspiegelt, was diese Pipeline bestanden hat.
2. Internationalisierung ist ein Vertrag mit Suchmaschinen
Die Website ist zweisprachig, Englisch und Deutsch. Der naive Ansatz speichert die gewählte Sprache in einem Cookie und liefert beide Sprachen unter derselben URL aus. Für Menschen sieht das gut aus und für Suchmaschinen ist es unsichtbar: Google indexiert nur eine Version, ohne Hinweis darauf, dass eine übersetzte Entsprechung existiert.
Die Lösung war, die Sprache in den URL-Pfad zu verlagern, /en und /de, und hreflang-Alternativen sowie sprachspezifische Canonical-Tags auszugeben. Jede Sprache ist jetzt eigenständig crawlbar, und Suchmaschinen verstehen die Beziehung zwischen ihnen.
- Sprache im Pfad statt im Cookie, damit jede Sprache eine stabile, indexierbare URL hat
- hreflang-Alternativen (en, de, x-default) und ein sprachspezifisches Canonical auf jeder Seite
- Eine lokalisierte Sitemap und ein RSS-Feed je Sprache
Wenn sich zwei Sprachen eine URL teilen, existiert für die Suche nur eine davon.
3. Cross-Browser-Tests zahlen sich aus
Ich habe eine End-to-End-Suite hinzugefügt, die über Chromium, Firefox und WebKit läuft. Die WebKit-Abdeckung hat sich fast sofort gelohnt.
Nachdem ich eine Content-Security-Policy eingeführt hatte, funktionierten die interaktiven Funktionen in Chrome und Firefox weiterhin, aber ein WebKit-Test schlug fehl. Ursache war eine einzige CSP-Direktive, upgrade-insecure-requests, die WebKit sogar auf localhost anwendet, während Chromium und Firefox sie dort ausnehmen. Über den reinen HTTP-Testserver versuchte WebKit, die Seitenskripte über HTTPS zu laden, sie schlugen fehl, und nichts hydrierte.
In Produktion wird alles über HTTPS ausgeliefert, echte Safari-Nutzer waren also nie betroffen. Aber der Test machte einen echten Engine-Unterschied sichtbar, den ich sonst als stille Annahme mitgetragen hätte, und die Direktive war ohnehin redundant zu HSTS, ihr Entfernen kostete also nichts.
Ein Test, der nur in dem Browser besteht, den man zufällig nutzt, ist kein Test, dem man vertrauen kann.
4. Die Pipeline ist die Quelle der Wahrheit
Manuelle Prüfung übersteht keine arbeitsreiche Woche. Die Continuous-Integration-Pipeline führt bei jeder Änderung Lint, einen Produktions-Build und die vollständige End-to-End-Suite über drei Browser-Engines aus.
Performance, Barrierefreiheit und SEO werden separat als nicht blockierender Report geprüft, sodass ein Punkteabfall informiert, ohne ein Deployment zu stoppen. Die harten Gates bleiben deterministisch, die weicheren Signale bleiben sichtbar.
5. Kleine Details summieren sich
Der Großteil der Arbeit war unspektakulär und kumulativ. Keine einzelne Änderung ist dramatisch; zusammen sind sie der Unterschied zwischen einer Seite, die bloß rendert, und einer, die konstruiert ist.
- Security-Header: eine Content-Security-Policy, Schutz vor Framing und MIME-Sniffing sowie eine straffere Referrer-Policy
- Ein Profilbild, neu kodiert von 2,2 MB auf rund 20 KB ohne sichtbaren Qualitätsverlust
- Dynamische Open-Graph-Bilder, damit jeder geteilte Link mit eigenem Titel als Vorschau erscheint
- Strukturierte Daten und ein RSS-Feed, damit die Texte auffindbar sind, nicht nur vorhanden
Fazit: Das Medium ist die Botschaft
Für eine Quality-Engineering-Fachkraft ist das ehrlichste Portfolio eines, das so gebaut ist, wie man ein Team ein Produkt bauen lassen würde: getestet, gemessen, internationalisiert und beobachtbar.
Es ging nie um die Website. Es ging darum, dass die Disziplin auf jeder Größenordnung gilt und dass der günstigste Ort, einen Fehler zu finden, immer vor allen anderen liegt.
Die überzeugendste Case Study für Quality Engineering ist das, was man gebaut hat, um sie zu beschreiben.