Als Testmanager erzähle ich seit Jahren, dass Qualität kein Zufall ist. Bei der eigenen Homepage wäre es also etwas peinlich, kurz draufzuschauen und auf Hochladen zu klicken. Der Schuster mit den schlechtesten Schuhen wollte ich nicht sein. Also bekam die Seite, was ich auch in Projekten empfehle. Automatische Tests prüfen alles, was sich maschinell prüfen lässt. Für den Rest gibt es einen strukturierten Blick aus Sicht der Lesenden.
Die automatisierten Tests
Wer mich kennt, weiß: Ein Testautomatisierer bin ich nicht. Die Tests hat deshalb Claude Code geschrieben. Inhaltlich kann ich aber jeden Test abnehmen. Dafür ist jeder Test mit Ziel und Zweck beschrieben.
Vor jedem Commit
Gestartet werden die Tests von einem Pre-Commit-Hook. Er checkt den Stand aus dem Index in einen eigenen Ordner aus und lässt dort die ganze Suite laufen. Das dauert auf meinem Rechner rund 20 Sekunden. Scheitert ein Test, bricht der Commit ab. Weil ich nur committete Stände hochlade, ist damit jede Veröffentlichung getestet. Externe Dienste wie LinkedIn sind dabei gemockt. Statt eines echten Abrufs bekommt der Code vorbereitete Antworten.
Eine Sache ist mir wichtig: Jede Warnung von PHP lässt einen Test scheitern, auch wenn das Ergebnis stimmt. Gedacht ist das vor allem für veraltete Aufrufe, die in einer späteren PHP-Version wegfallen. Der Webspace läuft mit PHP 8.5. Solche Stellen sollen sofort auffallen, nicht erst beim nächsten Update des Hosters.
Was getestet wird
Getestet werden alle Seitenvorlagen, von der Startseite über Engagement, TestLänd, Kurzprofil, Werdegang und Datenschutz bis zu den Detailseiten unter Veröffentlichungen, Auftritte und Blog. Abgedeckt sind auch die zentralen Daten der Seite und der Front Controller, der für saubere Adressen sorgt. Dazu kommen der Blog mit Übersicht und RSS-Feed und die LinkedIn-Karten auf der Startseite samt passwortgeschützter Pflegeseite. Auch die eigene Besucherstatistik mit Kontaktformular hat ihre Tests, ebenso robots.txt, llms.txt und sitemap.xml sowie CSS, JavaScript und die .htaccess.
Die Tests prüfen nicht nur Code, sondern auch Inhalte. Harte Zahlen wie Semester, Studierende oder After Works stehen an genau einer Stelle. Ein Test schlägt an, sobald irgendwo eine dieser Zahlen fest eingetippt ist. Ein anderer prüft, dass alle Seiten denselben Wert zeigen. Jeder Blogeintrag braucht ein Titelbild mit Alt-Text, passenden Maßen und allen Bildvarianten.
Einordnung im Matrix-Modell
Das Matrix-Modell der TestGilde ordnet Tests auf zwei Achsen ein: nach Teststufen und nach den Qualitätsmerkmalen der ISO 25010. Jedes Feld zeigt also, welches Merkmal auf welcher Stufe geprüft wird. Gemeinsam mit Laura de Michele habe ich das Modell in einem Artikel für die iX beschrieben. Er erscheint am 06.11.2026 im iX Special „Software-Testing“. Vorgestellt habe ich es unter anderem bei der German Testing Night in Leonberg. Einen Bericht dazu findest du hier im Blog. Schau auch gerne bei meinen anderen Auftritten vorbei.
Auf meiner Homepage ist jeder der 190 Tests genau einer Teststufe und einem Qualitätsmerkmal als Hauptziel zugeordnet. Für die Teststufe zählt, wie viel ein Test als Ganzes ausführt. Nur beim Abnahmetest entscheidet etwas anderes, nämlich woher die erwartete Antwort stammt.
Wische seitlich, um alle Spalten zu sehen.
| Teststufe | Funktionale Eignung | Leistungseffizienz | Kompatibilität | Interaktionsfähigkeit | Zuverlässigkeit | Informationssicherheit | Wartbarkeit | Flexibilität | Betriebssicherheit | Tests |
|---|---|---|---|---|---|---|---|---|---|---|
| Abnahmetest | 13 | 1 | 3 | 1 | 18 | |||||
| Systemintegrationstest | 7 | 2 | 1 | 10 | ||||||
| Systemtest | 17 | 7 | 1 | 4 | 4 | 4 | 1 | 38 | ||
| Komponentenintegrationstest | 14 | 1 | 8 | 4 | 3 | 30 | ||||
| Komponententest | 43 | 2 | 5 | 5 | 12 | 22 | 4 | 1 | 94 | |
| Tests je Merkmal | 94 | 2 | 14 | 17 | 22 | 30 | 9 | 2 | 0 | 190 |
| Tests der Homepage je Teststufe und Qualitätsmerkmal, Stand Oktober 2026. Jeder Test zählt einmal, bei seinem Hauptmerkmal. | ||||||||||
Teststufen
Mit knapp der Hälfte bilden die Komponententests die breite Basis, wie in einer Testpyramide. Die Stufen im Einzelnen, von unten nach oben:
Komponententests (94) prüfen eine einzelne Funktion oder Datei für sich.
Komponentenintegrationstests (30) prüfen, wie mehrere eigene Bausteine zusammenarbeiten. Ein Beispiel ist das Speichern eines LinkedIn-Beitrags mit Formular, Abruf, Bild und Speicher.
Systemtests (38) starten eine Seite über ihren Einstieg im eigenen PHP-Prozess, so wie Apache es tun würde. Dann prüfen sie das fertige HTML. Damit ist auch abgesichert, dass Inhalte ohne JavaScript ankommen. Im Browser läuft allerdings kein Test.
Systemintegrationstests (10) prüfen die Schnittstellen zu fremden Systemen: LinkedIn, den Kurzlinkdienst lnkd.in und Apache mit der .htaccess. Die Partner sind dabei gemockt, LinkedIn etwa durch eine gespeicherte Seite und vorbereitete Antworten. Ob LinkedIn sich morgen noch genauso verhält, zeigt erst der Betrieb.
Abnahmetests (18) haben als Testorakel keine technische Spezifikation. Die erwartete Antwort ist eine Entscheidung von mir oder eine rechtliche Vorgabe: wörtliche Zitate, Namen und Orte, Pflichtangaben im Datenschutz, Schreibregeln. So prüft ein Abnahmetest, dass auf der Startseite nur freigegebene Zitate stehen, wörtlich und in der festgelegten Reihenfolge. Diese Tests sorgen dafür, dass Entscheidungen nicht versehentlich zurückgedreht werden. Die eigentliche Abnahme bleibt trotzdem bei mir, in der lokalen Vorschau und auf der Live-Seite.
Qualitätsmerkmale
Ich verwende die deutschen Begriffe, die ich für die Qualitätsmerkmale der ISO 25010 empfehle. Die Zahl dahinter zählt wie in der Matrix die Tests mit diesem Merkmal als Hauptziel. 89 Tests prüfen nebenbei weitere Merkmale. Die zählt die Matrix nicht mit.
Funktionale Eignung (94): Der klare Schwerpunkt, und das passt: Der Wert dieser Website liegt in richtigen und vollständigen Inhalten. Zahlen stimmen auf allen Seiten überein, Blogtexte erscheinen in der richtigen Reihenfolge, Datumsangaben stimmen auch beim Wechsel auf die Winterzeit.
Informationssicherheit (30): Die Pflegeseite ruft nur LinkedIn per HTTPS ab, Adressen wie linkedin.com.evil.com fallen durch. Dateien lassen sich nicht über Pfade wie ../ löschen, Eingaben werden maskiert, die IP wird gekürzt gespeichert.
Zuverlässigkeit (22): Ein Fehler der Statistik darf nie eine Seite stören. Die robots.txt kommt auch dann, wenn das Mitschreiben scheitert. Kaputte Dateien führen zu leeren Listen statt zu Abstürzen und werden nie überschrieben.
Interaktionsfähigkeit (17): Jede Detailseite hat genau eine H1, jedes Bild einen Alt-Text, die Pflegeseite zeigt verständliche Meldungen statt Fehlercodes. Geprüft wird nur am HTML. Wie die Seite auf dem Telefon oder mit einem Screenreader wirkt, schaue ich mir von Hand an.
Kompatibilität (14): Strukturierte Daten, Open Graph und RSS sind gültig und zeigen auf die richtige Adresse. Geprüft wird gegen meine eigenen Erwartungen. Ob Google die Daten wirklich annimmt, zeigt erst ein externes Werkzeug wie der Rich-Results-Test. Den starte ich von Hand.
Wartbarkeit (9): Zahlen stehen zentral und sind nirgends fest eingetippt. Alle Seiten laden CSS und JavaScript in derselben Version. Zu jedem Blogeintrag gibt es genau eine Seite, und keine Seite bleibt verwaist.
Flexibilität (2): Die Seite passt sich ihrer Umgebung an. Sie läuft beim Hoster und auf meinem Rechner, ohne dass ich etwas umstellen muss. Was es nur beim Hoster gibt, etwa die Besucherstatistik, schaltet sich anderswo von selbst ab.
Leistungseffizienz (2): Nur statisch abgesichert über Bildgrößen, WebP-Varianten, Lazy Loading und Antworten mit 304. Ladezeiten misst kein Test.
Betriebssicherheit (0): Kein Test, und das ist richtig so. Eine Homepage gefährdet zum Glück weder Leib noch Leben. Eine kaputte Datei sperrt zwar das Speichern. Das sieht nach einem sicheren Zustand aus, schützt aber nur Daten und gehört deshalb zur Zuverlässigkeit.
Was die Matrix sichtbar macht
Genau dafür ist das Modell gedacht: Lücken in der Testabdeckung zu erkennen. Bei mir sind es drei. Die Pflegeseite läuft in keinem Systemtest als Ganzes, nur ihre Bausteine sind gut abgedeckt. Interaktionsfähigkeit im Browser und Ladezeiten prüfe ich nur von Hand. Und die Partner der Systemintegrationstests sind gemockt, nicht echt.
Das Audit
Personas als Basis
Tests prüfen, ob etwas stimmt. Das Audit fragt, ob die Seite überzeugt. Es ist ein Prompt für Claude Code, den ich regelmäßig laufen lasse. Er arbeitet rein prüfend und ändert keine Datei.
Grundlage sind vier definierte Personas. Die erste ist eine erfahrene Fachperson aus der Testing-Community. Die zweite würde mich weiterempfehlen, die dritte schlägt mich nach einem Vortrag nach. Die vierte ist ein Sprachmodell, das die Seite für eine KI-Antwort auswertet. Das Audit liest die Seite aus allen vier Blickwinkeln gleichzeitig.
Kategorien und Bericht
Bewertet wird in Kategorien wie Social Proof, Inhaltsqualität, „professionell und nahbar“, SEO, Auffindbarkeit in KI-Suchen sowie Alt-Texte und Barrierearmut. Jede Kategorie bekommt eine Bewertung auf einer Skala von 1 bis 10 mit festen Ankerpunkten, damit sie nicht zu milde ausfällt. Daraus ergibt sich ein gewichteter Gesamtwert. Beim ersten Lauf lag er bei 5,2, inzwischen seit drei Läufen bei 9,0 oder 9,1.
Ergebnis ist ein datierter Bericht mit einem Maßnahmenkatalog. Jede Maßnahme hat eine Nummer, einen Vorschlag zur Umsetzung, Aufwand und Wirkung. Geprüft wird gegen den lokalen Entwicklungsserver. Für Punkte, die nur live prüfbar sind, gibt es eine eigene Checkliste. Dazu gehören HTTPS und Weiterleitungen.
Vom Audit zum Test
Manche Maßnahme aus dem Audit landet anschließend in der Testsuite. Maßnahme M66 verlangte: Fällt das JavaScript aus, bleiben Inhalte und mein Name in der Kopfzeile trotzdem sichtbar. Heute sichern das 3 Tests ab.
Ein zweites Beispiel kam aus der Live-Prüfung: Adressen wie /img/ liefen in eine Weiterleitungsschleife. Seit der Korrektur passen 2 Tests auf, dass sie nicht wiederkommt. So wird aus einem Befund eine Regel, die nicht wieder kaputtgeht.
Fazit
Die automatischen Tests sichern ab, was schon funktioniert. Das Audit zeigt, wo die Seite noch besser werden kann. Erst beides zusammen ergibt für mich ein vollständiges Bild, genau wie im Projekt.
Und ja: Auch dieser Beitrag musste durch die Tests, bevor er online gehen durfte.
