Teststrategie

Die Teststrategie kombiniert schnelle automatische Prüfungen mit manuellen Tests für Risiken, die sich nicht zuverlässig automatisieren lassen. Umfang und Tiefe richten sich nach der Änderung.

Webapp

Automatisiert

• ESLint
• Jest mit jsdom und Testing Library
• Next.js-Produktionsbuild
• Playwright-Smoke- und Journey-Tests
• axe-Prüfungen gegen ausgewählte Zustände nach WCAG 2.2 A und AA

In Merge Requests und auf main baut der E2E-Job die App lokal und verwendet ein veröffentlichtes Staging-CMS als Datenquelle. Funktionale E2E- und Accessibility-Tests laufen dort mit Chromium. Lokale Playwright-Läufe können zusätzlich Firefox und WebKit verwenden.

Schwerpunkte sind Kategorienavigation, Stories und Slides, Breadcrumb, Sprachwahl, Locale-Präferenz, Fokusführung, responsive Zustände, Content Preview, CMS-Proxy und TTS-nahe Logik.

Manuell

• Screenreader mit mindestens einem realistischen Kernflow
• vollständige Tastaturbedienung
• Zoom bis 200 und 400 Prozent sowie Reflow
• Smartphone- und Desktopdarstellung
• Reduced Motion
• Verständlichkeit der deutschen und englischen UI-Texte
• Audiowiedergabe, Aussprache und Wortmarkierung

Automatische axe-Prüfungen ersetzen diese Tests nicht.

CMS

Derzeit automatisiert

• reproduzierbare Installation mit npm ci
• Abhängigkeitskonsistenz mit npm ls --omit=dev
• Strapi-Produktionsbuild

Das CMS besitzt derzeit keine automatisierten Tests und keine lokale Lint- oder Formatkonfiguration. Diese Lücke wird offen benannt und durch manuelle Prüfungen abgesichert, bis kritische CMS-Pfade automatisiert getestet werden.

Manuelle Pflichtpfade bei betroffenen Änderungen

• Kategorie und Story anlegen, speichern, bearbeiten und veröffentlichen
• deutsche und englische Lokalisierung samt Beziehungen
• Entwurfsvorschau und Verlassen der Vorschau
• öffentliche API liefert keine Entwürfe
• Medienupload lokal beziehungsweise über S3
• TTS einzeln und gesammelt starten
• Status, Fehler, Abbruch und Wiederherstellung prüfen
• erzeugtes Audio und Wort-Zeitmarken in der App kontrollieren

Schema-, Datenbank-, Upload-, Preview- oder TTS-Änderungen benötigen passende Testdaten und eine Rückfallstrategie.

Dokumentation

Automatisiert

• TypeScript-Prüfung
• Prüfung interner Links und lokaler Assets
• Next.js-Produktionsbuild
• Pagefind-Indexierung
• GitLab SAST und Secret Detection

Manuell

• Navigation und alte Weiterleitungen
• Suche und direkte Seitenaufrufe
• Desktop- und Smartphone-Ansicht
• Tastaturbedienung und sichtbarer Fokus
• Überschriftenhierarchie und verständliche Linktexte
• Staging-Banner und noindex
• Stichprobe der Anleitungen gegen App und CMS

Teststufen

1. Während der Umsetzung: betroffene schnelle Tests und Selbstprüfung.
2. Vor dem Merge: vollständige relevante Repository-CI.
3. Auf Staging: integrierte Kernflows über CMS, App und Docs.
4. Vor Beta oder Release: manuelle Accessibility-, Redaktions- und Betriebsprüfungen.
5. Nach Deployment: kurzer Produktions-Smoke-Test ohne Veränderung produktiver Daten.

Regressionstests

Ein behobener Fehler erhält einen automatisierten Regressionstest, wenn der Pfad stabil automatisierbar und das Risiko relevant ist. Andernfalls wird der manuelle Prüfpunkt in einer Checkliste ergänzt. Tests müssen den beobachtbaren Vertrag prüfen und dürfen nicht unnötig an Implementierungsdetails gekoppelt sein.

Testdaten und Umgebungen

• Unit-Tests verwenden kontrollierte Fixtures und Mocks.
• App-E2E verwendet veröffentlichte, nicht vertrauliche Staging-Inhalte.
• CMS-Importe und destruktive Tests laufen nur gegen neue oder bewusst dafür vorbereitete Instanzen.
• Produktive Daten und Secrets werden nicht in Tests, Artefakte oder Logs kopiert.

Freigabekriterium

Ein Merge oder Release ist nur freigabefähig, wenn die relevanten Prüfungen grün sind oder eine begründete, dokumentierte Risikofreigabe vorliegt. Flaky Tests werden nicht kommentarlos wiederholt oder dauerhaft ignoriert, sondern als eigenes Problem erfasst.