Applikationen testen

Testen ist mehr als 'kurz durchklicken'. Du lernst, für eine Applikation festzulegen, was auf welcher Ebene getestet wird, und leitest Testfälle systematisch aus Anforderungen ab. Du schreibst automatisierte Unit-, Integrations- und End-to-End-Tests, isolierst Abhängigkeiten mit Mocks und lässt alles bei jedem Push in einer CI-Pipeline laufen. Gefundene Fehler dokumentierst du so, dass sie andere nachvollziehen und beheben können.

Das sind die Fähigkeiten, die am Ende des Moduls sitzen sollten. Jedes Ziel mit einem Beispiel aus dem Lehrbetrieb.

1. 1

   Ein Testkonzept mit passenden Teststufen festlegen

   Kompetenz A

   Du entscheidest für eine Applikation, was mit Unit-, Integrations-, System- und Abnahmetests geprüft wird, wer testet, mit welchen Daten und wann ein Test als bestanden gilt. Dabei richtest du dich nach dem Risiko, nicht nach dem Bauchgefühl.

   Situation

   Eine Krankenkasse in Luzern ersetzt ihre Prämienrechner-Webseite. Der Rechner beeinflusst direkt Offerten, das Design ist zweitrangig.

   Deine Aufgabe

   Erstelle ein schlankes Testkonzept für das Projekt.

   Gutes Ergebnis

   Zwei Seiten: Risiken (Prämienberechnung, Franchise-Rabatte, Altersgrenzen), Testpyramide mit vielen Unit-Tests für die Berechnung, Integrationstests für Tarif-Import, fünf End-to-End-Tests für die wichtigsten Abläufe. Abbruchkriterium: keine offenen Fehler der Schwere 'kritisch'.

   TestkonzeptTeststufenTestpyramiderisikobasiertes TestenAbnahmekriterium
2. 2

   Testfälle systematisch aus Anforderungen ableiten

   Kompetenz B

   Statt zufällig Werte auszuprobieren, teilst du Eingaben in Äquivalenzklassen ein, testest gezielt die Grenzen und hältst Regelkombinationen in Entscheidungstabellen fest. So deckst du mit wenigen Tests viele Fälle ab.

   Situation

   Ein Kino in Basel gewährt Ermässigung: Kinder unter 12 zahlen CHF 12, Jugendliche 12 bis 17 und Studierende CHF 15, Erwachsene CHF 19, am Montag alle CHF 14.

   Deine Aufgabe

   Leite die nötigen Testfälle ab.

   Gutes Ergebnis

   Äquivalenzklassen für Alter und Status, Grenzwerte 11, 12, 17, 18 Jahre, Entscheidungstabelle für Montag kombiniert mit Kinderpreis. 14 Testfälle statt geschätzter 100 zufälliger Klicks, inklusive ungültigem Alter -1.

   ÄquivalenzklassenGrenzwertanalyseEntscheidungstabelleBlack-Box-Testnegativer Test
3. 3

   Unit-Tests mit isolierten Abhängigkeiten schreiben

   Kompetenz C

   Du testest eine Klasse ohne echte Datenbank, Mailserver oder Zeit. Abhängigkeiten ersetzt du durch Mocks oder Stubs, damit Tests schnell, wiederholbar und unabhängig voneinander laufen.

   Situation

   Ein Mahnwesen-Service eines Energieversorgers verschickt Mahnungen 30 Tage nach Fälligkeit. Die Tests hängen vom heutigen Datum ab und schlagen jeden Monat anders fehl.

   Deine Aufgabe

   Mach die Tests unabhängig vom echten Datum und vom Mailversand.

   Gutes Ergebnis

   Eine Clock wird injiziert und im Test auf den 15.03.2026 fixiert. Der Mailversand wird mit Mockito gemockt, und der Test prüft, dass 'senden' genau einmal mit der richtigen Kundennummer aufgerufen wird.

   MockStubDependency Injectiondeterministischer TestVerifikation
4. 4

   Zusammenspiel mit Integrations- und End-to-End-Tests prüfen

   Kompetenz D

   Du prüfst, ob Komponenten wirklich zusammenarbeiten: Service mit echter Datenbank, API mit realen Anfragen, Benutzeroberfläche im Browser. Du hältst diese Tests stabil und begrenzt sie auf die wichtigsten Abläufe.

   Situation

   Im Webshop eines Velohändlers in Bern funktionieren alle Unit-Tests, trotzdem schlägt der Checkout nach einem Update fehl, weil sich ein Feldname in der API geändert hat.

   Deine Aufgabe

   Sichere den Checkout gegen solche Fehler ab.

   Gutes Ergebnis

   Ein API-Integrationstest mit Testcontainers prüft Bestellung und Lagerabbuchung. Ein Playwright-Test führt den Checkout im Browser mit Testkreditkarte aus. Beide laufen in der Pipeline und hätten den Fehler vor dem Merge gemeldet.

   IntegrationstestEnd-to-End-TestTestcontainersPlaywrightflaky Test
5. 5

   Tests automatisiert in einer CI-Pipeline ausführen

   Kompetenz E

   Deine Tests laufen bei jedem Push automatisch. Die Pipeline bricht ab, wenn ein Test fehlschlägt, und zeigt Testergebnisse und Abdeckung an. So erfährt das Team innert Minuten, ob eine Änderung etwas kaputt gemacht hat.

   Situation

   Ein Team einer Logistikfirma in Oftringen testet nur vor Releases manuell. Regelmässig tauchen alte Fehler wieder auf.

   Deine Aufgabe

   Richte eine Pipeline ein, die bei jedem Pull Request alle Tests ausführt.

   Gutes Ergebnis

   GitHub-Actions-Workflow mit Build, Unit- und Integrationstests, Abdeckungsbericht mit JaCoCo und einem Branch-Schutz, der Merges nur bei grüner Pipeline erlaubt. Laufzeit 6 Minuten.

   Continuous IntegrationPipelineBranch ProtectionTestabdeckungRegressionstest
6. 6

   Fehler reproduzierbar melden und Testergebnisse berichten

   Kompetenz E

   Du beschreibst einen gefundenen Fehler so, dass jemand anderes ihn ohne Rückfrage nachstellen kann: Schritte, erwartetes und tatsächliches Ergebnis, Umgebung, Schweregrad. Am Ende fasst du Testergebnisse in einem kurzen Testbericht zusammen.

   Situation

   In der Rapport-App eines Sanitärbetriebs meldet ein Monteur: 'Speichern geht nicht.' Die Entwickler können den Fehler nicht nachstellen.

   Deine Aufgabe

   Untersuche den Fehler und erfasse ein brauchbares Ticket.

   Gutes Ergebnis

   Ticket mit Titel 'Rapport mit Umlaut im Kundennamen wird nicht gespeichert (HTTP 500)', fünf Schritten zum Nachstellen, App-Version 2.3.1, Android 14, Log-Auszug und Schweregrad 'hoch'. Der Fehler ist am selben Tag behoben.

   FehlerberichtReproduzierbarkeitSchweregrad / PrioritätTestprotokollTestbericht

Die Kompetenzmatrix zerlegt das Modul in Themenstränge und drei Stufen. Für den Kompetenznachweis solltest du überall mindestens Stufe 2 erreichen. Dein Stand bleibt in diesem Browser gespeichert und färbt Lernweg und Übungen ein.

Nora ist im 3. Lehrjahr als Informatikerin Applikationsentwicklung bei der Eventa Ticketing AG in Winterthur, die mit 70 Mitarbeitenden Online-Tickets für Konzerte und Festivals verkauft. Nach dem letzten Release wurden Gruppenrabatte falsch berechnet, und die Kundschaft hat sich lautstark beschwert. Für das nächste Release mit Sitzplatzwahl soll Nora das Testen neu aufziehen.

1. Kapitel 1

   Was darf auf keinen Fall schiefgehen?

   Nora sammelt mit dem Product Owner die Risiken und gewichtet sie nach Schaden und Wahrscheinlichkeit. Ganz oben stehen doppelt verkaufte Plätze, falsche Preise und bezahlte Bestellungen ohne Ticket. Sie skizziert eine Testpyramide mit vielen Unit-Tests, Integrationstests für Reservation und Datenbank sowie drei End-to-End-Tests für die Kernabläufe. Ihr zweiseitiges Testkonzept legt als Endekriterium fest, dass kein Fehler der Schwere "hoch" offen sein darf.

   Ziel 1

2. Kapitel 2

   Ab 10 Personen 15 Prozent

   Gruppen ab 10 Personen erhalten 15 Prozent, Studierende 20 Prozent, Rabatte sind nicht kumulierbar, und Kinder unter 6 Jahren sind gratis. Nora stellt eine Entscheidungstabelle mit acht Kombinationen auf und merkt, dass die Anforderung nicht festlegt, was für eine Studierendengruppe gilt. Nach Rücksprache ist klar, dass der grössere Rabatt zählt. Für die Gruppengrösse plant sie Testfälle mit 9, 10 und 11 Personen.

   Ziel 2

3. Kapitel 3

   Testen ohne echte Zahlung

   Nora testet den Preisrechner mit einem parametrisierten JUnit-5-Test, der alle 14 Fälle aus der Tabelle abdeckt. Zahlungsanbieter und Mailversand ersetzt sie mit Mockito und prüft, dass bei einer abgelehnten Zahlung kein Ticket verschickt wird. Ein Mutationstest mit PIT zeigt, dass eine Änderung von >= zu > unbemerkt bleiben würde. Sie ergänzt den fehlenden Grenzwerttest, und die Mutation wird nun erkannt.

   Ziel 3

4. Kapitel 4

   Zwei Fans, ein Sitzplatz

   Mit Testcontainers und PostgreSQL schreibt Nora einen Integrationstest, der zwei Reservationen für Platz F12 gleichzeitig abschickt. Beide sind erfolgreich, ein echter Fehler, den kein Unit-Test gefunden hätte. Für den Kaufablauf vom Saalplan bis zur Bestätigung baut sie einen Playwright-Test. Weil dieser wegen einer Animation jedes fünfte Mal scheitert, ersetzt sie das fixe Warten durch Warten auf das sichtbare Bestätigungselement.

   Ziel 4

5. Kapitel 5

   Grün vor dem Release

   Nora richtet einen GitHub-Actions-Workflow ein, der Unit-, Integrations- und End-to-End-Tests ausführt und mit JaCoCo eine Abdeckung von 78 Prozent ausweist. Den Doppelbuchungsfehler erfasst sie in Jira mit Reproduktionsschritten, Log-Auszug und Schwere "hoch", und der Entwickler kann ihn in fünf Minuten nachstellen. Nach der Korrektur fasst sie 212 Tests und zwei offene Fehler mittlerer Schwere in einem Testbericht zusammen. Ihre Empfehlung lautet: Freigabe mit zwei dokumentierten Einschränkungen.

   Ziel 5Ziel 6

1. 1

   Warum und was testen?

   ca. 4 Std.

   Du lernst Teststufen, Testarten und die Testpyramide kennen und planst Tests nach Risiko.

   • Für eine bekannte App (z.B. SBB Mobile) die fünf grössten Risiken auflisten
   • Eine Testpyramide für ein Projekt aus dem Unterricht skizzieren
   • Ein zweiseitiges Testkonzept nach eigener Vorlage erstellen

   Trainiert Kompetenz A1A2

   Lernziel1

2. 2

   Testfälle konstruieren

   ca. 4 Std.

   Du übst Black-Box-Techniken, bis du für jede Regel sicher die richtigen Testfälle findest.

   • Für drei Tarifregeln Äquivalenzklassen und Grenzwerte bestimmen
   • Eine Entscheidungstabelle für eine Versandkostenregel mit vier Bedingungen aufstellen
   • Testfälle in einer Testfallliste mit ID, Vorbedingung, Schritten und Erwartung festhalten

   Trainiert Kompetenz B1B2

   Lernziel2

3. 3

   Unit-Tests und Mocks

   ca. 5 Std.

   Du setzt die Testfälle als schnelle, isolierte Unit-Tests um.

   • Parametrisierte Tests für die Grenzwerte schreiben
   • Datenbank- und Mail-Abhängigkeiten mit Mockito, Moq oder Jest-Mocks ersetzen
   • Mit Mutationstests oder absichtlichen Fehlern prüfen, ob deine Tests etwas taugen

   Trainiert Kompetenz C1C2C3

   Lernziel32

4. 4

   Zusammenspiel prüfen

   ca. 5 Std.

   Du testest Komponenten gemeinsam: API mit Datenbank und Oberfläche im Browser.

   • Einen Integrationstest mit Testcontainers und PostgreSQL schreiben
   • Eine Postman-Collection mit Assertions erstellen und mit Newman ausführen
   • Einen Playwright-Test für einen Login- und Bestellablauf aufnehmen und stabil machen

   Trainiert Kompetenz D1D2

   Lernziel4

5. 5

   Automatisieren und berichten

   ca. 4 Std.

   Du lässt alle Tests in einer Pipeline laufen und dokumentierst Fehler und Ergebnisse professionell.

   • Einen CI-Workflow mit Tests und Abdeckungsbericht einrichten
   • Drei Fehler aus einer Übungsapp als Tickets erfassen und von einer Kollegin nachstellen lassen
   • Einen einseitigen Testbericht mit Ergebnis, offenen Fehlern und Empfehlung schreiben

   Trainiert Kompetenz E1E2E3

   Lernziel56

6. 6

   Testprojekt von A bis Z

   ca. 5 Std.

   Du testest eine bestehende Applikation komplett: Konzept, Testfälle, Automatisierung, Bericht.

   • Ein Testkonzept für eine Übungsapplikation mit eingebauten Fehlern erstellen
   • Tests auf allen Stufen umsetzen und in der Pipeline laufen lassen
   • Gefundene Fehler als Tickets erfassen und den Testbericht abgeben

   Trainiert Kompetenz A3B3D3E3

   Lernziel1246

Testkonzept

Dokument, das festlegt, was, wie, womit und von wem getestet wird und wann Tests als bestanden gelten.

Teststufe

Ebene, auf der getestet wird: Unit, Integration, System oder Abnahme.

Äquivalenzklasse

Menge von Eingaben, die vom Programm gleich behandelt werden sollten.

Grenzwertanalyse

Testtechnik, die gezielt Werte an und neben Bereichsgrenzen prüft.

Mock

Ersatzobjekt im Test, das Aufrufe aufzeichnet und überprüfbar macht.

End-to-End-Test

Test eines vollständigen Ablaufs aus Sicht der Benutzenden über alle Schichten.

Continuous Integration

Praxis, Änderungen häufig zusammenzuführen und dabei automatisch zu bauen und zu testen.

Testabdeckung

Anteil des Codes, der von Tests ausgeführt wird, z.B. Zeilen oder Verzweigungen.

Passende Module