Achtung: Diese Aufgabe wird benotet.
Sie zählt zur Note 2 (Projekt 4.0), Kriterium C. Welche Aufgaben in welche Note einfliessen, steht in Aufgabe 8 unter «Benotung im Modul».
Der Prototyp läuft und ist online. Jetzt prüfen Sie, ob er hält, was Sie sich vorgenommen haben. Sie formulieren Hypothesen, testen sie und halten die Ergebnisse fest, auch die, die nicht wie erhofft ausfallen. Die automatisierten Tests laufen in der Pipeline aus Aufgabe 12, damit eine spätere Änderung nichts kaputt macht, was schon funktioniert hat.
Zeitbedarf: 2 Lektionen à 45 Minuten, also 90 Minuten Unterricht
(Woche 14)
Hilfsmittel: Ihr Repository und Ihre Pipeline aus Aufgabe 12, Google
Lighthouse (in den Chrome DevTools)
Sozialform: Ihre Vierergruppe
Eine Hypothese ist eine Aussage, die sich prüfen lässt, zum Beispiel: «Wir glauben, dass Nutzer mit unserer App einen Termin in unter zwei Minuten finden.» Legen Sie vorher fest, wann sie als bestätigt gilt.
Schreiben Sie zwei bis vier Hypothesen und einen Testplan, der zu jeder Hypothese vier Fragen beantwortet: Was wird getestet? Wer testet? Wie wird gemessen? Wann ist der Test bestanden?
| Methode | Prüft | Beispiel |
|---|---|---|
| Funktionstest | Läuft die Kernfunktion? | Klickpfad durchspielen |
| Nutzertest | Ist es verständlich? | 5 Personen wie in Aufgabe 9 |
| Leistungsmessung | Wie schnell ist es? | Google Lighthouse |
| Unit-Test | Stimmt die Logik? | Vitest oder Jest, in der Pipeline |
| E2E-Test | Läuft der Ablauf im Browser? | Playwright, in der Pipeline |
Unit- und E2E-Tests sind Pflicht. Die übrigen Methoden wählen Sie passend zu Ihren Hypothesen.
Schreiben Sie Unit-Tests für die Logik der kritischen Punkte und
mindestens einen E2E-Test für den wichtigsten Ablauf. Beide laufen in
der Pipeline bei jedem Push auf main.
Die Tests müssen deterministisch sein, also bei jedem Lauf dasselbe Ergebnis liefern. Dafür brauchen Sie feste Testdaten statt Live-Daten und gemockte externe Dienste, und jeder Test muss unabhängig von den anderen laufen. Vermeiden Sie Zufall, Uhrzeit oder eine feste Reihenfolge im Test sowie feste Wartezeiten; warten Sie stattdessen auf das Element. Ein Test, der mal grün und mal rot ist, hilft niemandem.
Halten Sie jeden Test in einem Protokoll fest:
| Testfall | Erwartet | Ergebnis | Schluss |
|---|---|---|---|
| Beitrag anlegen | Erscheint in der Liste | bestanden | Risiko gesenkt |
| Seite laden | Unter 3 Sekunden | 4,2 Sekunden | Bild optimieren |
Sichern Sie Belege: Screenshots, Lighthouse-Berichte, Pipeline-Läufe. Halten Sie auch Fehlschläge fest.
Beantworten Sie für jede Hypothese: Wurde sie bestätigt? Welches Risiko aus Aufgabe 11 ist kleiner geworden? Was ändern Sie am Prototyp? Setzen Sie die wichtigsten Änderungen noch in dieser Woche um.
| Kriterium | 3 Punkte, wenn … |
|---|---|
| C: Prototyp validieren | Unit- und E2E-Tests decken die kritischen Abläufe ab und laufen
deterministisch; jeder Push auf main testet und deployt
automatisch; das Testprotokoll ist vollständig |