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
• ESLint für JavaScript, TypeScript, React Hooks und Accessibility
• Prettier-Formatprüfung
• TypeScript-Prüfung für Server-, Admin- und E2E-Testcode
• Jest-Unit-Tests für Serverlogik und ausführbare Scripts
• React-Komponententests mit jsdom und Testing Library
• Strapi-Integrationstests mit temporärem SQLite und Supertest
• Python-Unit-Tests für die Qwen-Scriptlogik ohne Modellinitialisierung
• Playwright-E2E-Tests gegen einen isoliert gestarteten Strapi-Prozess
• V8-Coverage mit Text-, HTML- und Cobertura-Bericht
• Strapi-Produktionsbuild

Der Test-Stack bildet zunächst ein ausführbares Fundament mit Smoke-Tests für alle Teststufen. Die fachliche Abdeckung wird schrittweise um die vollständigen Redaktions-, Preview-, TTS-, Import- und Release-Pfade erweitert. Bis der jeweilige Pfad automatisiert abgedeckt ist, bleibt die zugehörige manuelle Prüfung verpflichtend. ESLint prüft Server-, Admin- und Testcode lokal und in der Pipeline. Prettier formatiert unterstützte Dateien einheitlich und wird in der Pipeline auf Abweichungen geprüft.

Jest 29 ist auf Strapi 5 abgestimmt und verarbeitet TypeScript und TSX über SWC. Admin-Komponenten werden direkt mit React Testing Library und einem kleinen lokalen Design-System-Wrapper getestet. Strapis interner Admin-Testhelper wird nicht verwendet, weil dessen nicht veröffentlichte Monorepo-Abhängigkeit außerhalb von Strapi nicht reproduzierbar installierbar ist.

Integration und E2E verwenden ausschließlich Test-Secrets, lokale temporäre SQLite-Datenbanken und lokale Uploadkonfiguration. Sie greifen nicht auf produktive Datenbanken, Buckets oder TTS-Provider zu. Externe Dienste werden in fachlichen Tests durch kontrollierte Test-Doubles ersetzt; echte Provider-Smoke-Tests bleiben separat und explizit.

Der Coverage-Lauf erfasst den gesamten projektspezifischen TypeScript- und JavaScript-Code, einschließlich noch nicht getesteter Dateien. Das Fundament erzwingt bereits vollständige Branch-, Function-, Line- und Statement-Abdeckung für die Draft-Zugriffspolicy. Weitere globale und dateispezifische Grenzen werden mit den fachlichen Tests angehoben; die Gesamtdeckung des Fundaments ist noch nicht die vollständige CMS-Abdeckung.

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
• TTS-Routen ohne Session (401), ohne Berechtigung (403) und mit berechtigter Admin-Session prüfen
• 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.