Aufgabe 11 - Teststrategie fürs Jahresprojekt

Aufgabe 11 - Teststrategie fürs Jahresprojekt

Worum geht es?

Eine zentrale Lehrplan-Kompetenz: eine Teststrategie für Ihre Anwendung entwickeln, dokumentieren und umsetzen, unter Berücksichtigung der eingesetzten Bibliotheken und Frameworks. Sie übersetzen Risiken in Testaufwand, automatisieren die kritischen Flows und verankern das Ganze in CI und Definition of Done (siehe Kapitel Teststrategien II).

Was Sie dafür brauchen

• Kapitel Teststrategien I und II (Pyramide, E2E, Flows, flaky Tests, Qualitätssicherung im Prozess).
• Ihr Jahresprojekt; Playwright (oder das im Unterricht festgelegte E2E-Werkzeug).

Welche Kompetenzen Sie erwerben und zeigen

• Sie leiten aus einer Risikoanalyse eine begründete Zuordnung von Ebene und Werkzeug ab.
• Sie automatisieren die kritischen Flows als E2E-Tests und beheben flaky Verhalten.
• Sie verankern Tests als Merge-Bedingung in der CI und in der Definition of Done.

Pädagogische Einordnung

• Reproduktion: die Testebenen und Werkzeuge des Kapitels zuordnen (Teil A).
• Reorganisation und Transfer: kritische Flows automatisieren und in die CI integrieren (Teil B).
• Reflexion, Problemlösung und Urteilsbildung: die Strategie verteidigen und ein Qualitätstor definieren (Teile C und D).

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt. Teil D ist der Expertenteil.

Teil A - Das Strategiedokument

Verfassen Sie im Team (maximal drei Seiten) die Teststrategie Ihres Projekts:

1. Risikoanalyse: die fünf wichtigsten Fehlerszenarien Ihres Produkts (Was wäre für Nutzer am schlimmsten?), je mit Eintrittswahrscheinlichkeit und Schadenshöhe (hoch/mittel/niedrig).
2. Ebenen-Zuordnung: Welches Risiko wird auf welcher Ebene mit welchem Werkzeug abgedeckt? Begründen Sie werkzeugspezifisch (etwa “Komponententests mit Testing Library, weil unsere UI-Logik in Client-Komponenten steckt”).
3. Bewusste Lücken: Was testen Sie nicht automatisiert, und warum ist das vertretbar?
4. Prozess: Wann laufen welche Tests (lokal/CI), was blockiert einen Merge, wie entstehen Tests bei Bugs (erst der Test, dann der Fix).

Teil B - E2E-Umsetzung

1. Identifizieren Sie die drei kritischsten Flows (aus der Risikoanalyse) und automatisieren Sie sie mit Playwright, inklusive eines Fehler-Flows (etwa: eine ungültige Eingabe zeigt die richtige Meldung).
2. Stabilität: Lassen Sie die Suite fünfmal laufen. Flaky? Ursache finden (fast immer Timing; auf Bedingungen warten statt fester Sleeps) und beheben. Protokollieren Sie die Diagnose.
3. Integrieren Sie die E2E-Suite in die CI.

Teil C - Verteidigung

Jedes Team stellt seine Strategie in fünf Minuten vor; die anderen Teams greifen mit je einer “Was-wäre-wenn”-Frage an (“Was fängt einen kaputten Datenbank-Index?”). Nicht abgedeckte Treffer werden als bewusste Lücke ergänzt oder als neuer Test eingeplant.

Teil D - Expertenteil: Akzeptanzkriterien und das Qualitätstor

1. Formulieren Sie Ihre drei kritischen Flows als Akzeptanztests im Given-When-Then-Schema und binden Sie sie an die Definition of Done: Eine Story, die einen dieser Flows berührt, gilt erst mit grünem Akzeptanztest als fertig.
2. Definieren Sie das Qualitätstor Ihrer CI präzise: Welche Prüfungen blockieren einen Merge auf main (Tests, Linter, ggf. eine Coverage-Untergrenze), und welche laufen nur als Hinweis? Begründen Sie, warum das Tor nicht zu streng (bremst) und nicht zu locker (schützt nicht) sein darf.
3. Beurteilen Sie in drei Sätzen die Balance zwischen Happy-Path- und Fehler-Flows: Warum prüft man nur wenige Fehler-Flows auf E2E-Ebene, wo fängt man den Rest günstiger ab, und welche Prüfung bleibt ehrlicherweise manuelle Sichtkontrolle?

Wissenscheck

1. Warum beginnt eine Teststrategie mit einer Risikoanalyse und nicht mit einer Werkzeugliste?
2. Was ist ein Flow, und warum organisiert man E2E-Tests pro Flow?
3. Was ist die häufigste Ursache flaky Tests, und wie behebt man sie?
4. Was gehört in ein Qualitätstor, das einen Merge blockiert?
5. Warum ist “erst der Test, dann der Fix” bei Bugs die richtige Reihenfolge?

Abgabe

Das Strategiedokument (versioniert unter /docs), die E2E-Suite in der CI (grüner Lauf verlinkt), das Flaky-Protokoll, die Akzeptanztests an der Definition of Done und die Beschreibung des Qualitätstors.